[Bf-committers] Proposal for unifying nodes

[Nathan Vegdahl]

> Oh, okay. To name a few: Rotation, translation, scale.

   Yeah... this actually confused the hell out of me when I first
started playing with the texture nodes, actually.  If I had a "cloud
texture" node, for example, I expected the node to have inputs for its
texture coordinates.  And frankly, when there weren't inputs for
texture coordinates, my first reaction was, "Wow... no way to do
transforms or distortions on the textures..."
   Granted, this is coming from someone who has written shaders and
procedurals before, so my perspective is a bit different than the
"typical" user.

   But in Blender I think of nodes as being data processing
black-boxes.  They take input data, and produce output data, and
that's it.  The way texture nodes work right now, it feels like
sometimes they "reach backwards" to grab data from up-stream nodes,
which totally breaks my mental model of how Blender nodes work.

   Whatever benefits your system may have, it also seems to me (at
least so far) that is complicates the mental model the user has to
maintain of how nodes work.  Nodes as black-box data-processors is
really simple to understand, and is also still extremely versatile.

--Nathan V

On Mon, Jun 15, 2009 at 8:22 AM, Robin Allen<roblovski at gmail.com> 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.
>
> 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?
>
> Having the node output the texture itself as a functional type solves
> all these issues.
>
> -Rob
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>