[Bf-committers] Proposal for unifying nodes

[joe]

Anyone know *why* texture nodes work this way?

Joe

On Mon, Jun 15, 2009 at 7:18 PM, Nathan Vegdahl<cessen at cessen.com> wrote:
>> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>