[Bf-committers] Proposal for unifying nodes

[Robin Allen]

2009/6/16 Nathan Vegdahl <cessen at cessen.com>:
>> I think perhaps you're confusing textures with the nodes that work on them.
>
>   I confused them when I started working with texture nodes because
> it's inconsistent with how the other two node systems work.
>   What I'm saying is that I don't think it should work that way in
> 2.5.  The "nodes as functions" paradigm makes a lot more sense to me,
> and seems a lot simpler to me, than the "nodes as function-object
> processors".
>
>> Using entire trees as nodes in other trees (not of differing types because
>> there should be no types) would be immensely powerful and is one of the
>> goals of the design.
>
>    Right.  But what I was trying to communicate was that the
> "functions-as-data" paradigm (or "function-objects as data" if you
> prefer) isn't necessary to achieve that functionality.
>
>   It seems a lot simpler to me, for example, to just treat a texture
> tree as *being* the texture function rather than as something that
> *generates* a texture function.  The former is how a purely
> data-oriented system would treat it, and as I understand it the latter
> is how your system would treat it.
>   Your proposal feels like a kind of meta-programming to me: writing
> a program to write a program, rather than just writing the program.
>
>   I'd much rather construct the function directly with nodes, rather
> than construct a system of nodes that generates the function.
>   And the result is ultimately the same: a function (or
> function-object if you prefer) that takes input and produces output,
> and which can be used anywhere.
>
>   I hope that makes sense.

Yes, it does. I see your argument now.

The problem with doing it your way is that if the nodes 'are' the
textures, they can't apply distortions to the other textures.
Translate, rotate and scale nodes are all trivial to implement in the
proposed system, and impossible in yours.

Also, if all texture nodes were required to have a coordinate input,
just think of all those connections in a complex tree, all going from
the master coordinate input to the inputs of every single node in the
tree. What a mess.

You seem to be seeing the proposed design as unnecessary abstraction,
but you have to understand that's not the way the user will see it. A
user working with textures and nodes manipulating textures won't think
"Functions returning functions! Hi-tech sorcery!"; the textures will
flow through the nodes as naturally as bitmaps now flow through the
compositor.

If the user wants to rotate a texture, what do you think they will
find more complicated: running that texture through a rotate node, or
rotating the incoming coordinate vector to the node in the direction
opposite to the direction they want to rotate the texture in?

Compositor: bitmap -> rotate -> rotated bitmap.
Texture nodes: texture -> rotate -> rotated texture.
Your texture nodes: Coord -> rotate inverse -> texture.

-Rob