[Bf-committers] Proposal for unifying nodes

[Robin Allen]

2009/6/16 Nathan Vegdahl <cessen at cessen.com>

>   Only if you think of them as being applied after the texture.  All
> of this is still possible and even trivial by using input coordinates.
>

I think of them as being applied *to* the texture. Anyway, my main
point is that the proposed system can do everything that your system
could do, but there are things that you can't do in yours.

You answered my question about rotate nodes by saying "don't use
a node, just transform the coordinates themselves" -- that works for
the case of rotate but not in the general case. In your system, you
can't "X" a texture, whatever "X" may be.

For example:

http://img5.imageshack.us/img5/7158/spinn.png

I can define a node which "spin blurs" a texture, and use it wherever
I like. This and countless other filters are only possible if texture nodes
are used as "operations on textures".

I'll answer your other points, but I'm pretty sure users won't much care
for a node system that can't do the above.


> > 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.
>
>    I would hardly consider it a mess.  It also provides the chance to
> use different coordinate inputs for different textures in the system
> (orco, cube mapping, a UV set, etc.).
>
>    And even just being able to organize the inputs of the tree
> nicely.  For example, if you intend to use the tree as a node in
> another system, you can use one input node to feed coordinates to one
> set of textures, and another input node for another set of textures.
> When the tree is used as a node, those two sets of inputs are then
> exposed.
>
>    In your system, where the input coordinates are implicit, we only
> have two options:
>    1. Expose all of the node's inputs individually, which would be a
> *real* mess, or
>    2. Only expose one set of input coordinates and apply it to all of
> the nodes, which severely limits flexibility (how would a user mix
> textures via nodes when they want different mappings for the
> textures?).


This would be possible using At nodes.


  Also, for semi-technical users like myself, I really worry how much
> your system would complicate writing pynodes, which IMO is another
> extremely valuable and important feature for the node system to have.
> It's very easy to write a pynode if it's just data-processing.  I'm
> not sure that same simplicity can be maintained if pynodes need to
> modify function-objects instead.


You'll still be writing a pynode for data processing. You'll write a
function,
in Python, that takes in coordinates and outputs a color, then you'll make
your pynode return it.

-Rob