[Bf-committers] Proposal for unifying nodes

[Brecht Van Lommel]

Hi Robin,

On Mon, 2009-06-15 at 16:22 +0100, Robin Allen wrote: 
> 2009/6/15 Brecht Van Lommel <brecht at blender.org>:
> > I mean the system of passing functions rather than vectors or color
> > values. What kind of node does this make possible, which is not possible
> > without passing functions?
> >
> > My point is, that I can't really think of one with practical use.
> > Simpler things like blurring or sharpening can be done with texture
> > derivatives, more advanced things seem to be inefficient or difficult to
> > the point of not being useful in practice.
> 
> Oh, okay. To name a few: Rotation, translation, scale.

This is also possible, if you apply these operations to texture
coordinates and input them into image or procedural textures.

A texture node tree could have a special node that gives you the default
texture coordinate. Furthermore, the inputs of image or procedural
textures coordinate input would use the default texture coordinate if it
is not linked to anything.

> But that's only part of the reason why functions are the right choice.
> Let's imagine we're passing color values directly instead. Obviously
> if the ultimate output from your tree is going to be a color value,
> this requires the tree to be evaluated in the context of a given set
> of coordinates. The tree itself then 'is' the texture; you call, for
> example, evaluate_texture_tree(mytree, mycoords). And once you're
> doing that, you're back to separate tree types!

> To put it another way, passing color values requires the evaluation of
> the tree to be 'tied' to some particular interpretation of the tree,
> which is what we should be trying to get away from. If your texture
> node only passes out a color value, what good will it be in a shader
> or compositor tree?

For compositing nodes, I can see the advantage of passing along
functions, then they naturally fit in a single node tree. For shader
nodes I don't see a problem.

But, even though it unifies one thing, the effect is also that it is
inconsistent in another way. Now you need two nodes for e.g. rotation,
one working on texture functions, and another on vectors (modifier
nodes). And further, these nodes need to placed in the tree in a
different order, one after, and another before the thing you want to
rotate.

Also, function pointers are not available in GLSL (or OpenCL), because
hardware does not support it. If they are only used in a restricted
manner some workaround may be possible, but this is something to keep in
mind I think.

Brecht.