[Bf-committers] Proposal for unifying nodes

Nathan Vegdahl cessen at cessen.com
Wed Jun 17 00:20:40 CEST 2009


>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.

   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.

> 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?).

    For these reasons alone, even if we *do* go with the
function-object system, I would still argue strongly for coordinate
inputs for textures.
    But I suspect, based on my understanding so far, that including
input coordinates that way would actually break the function-object
system, because those inputs need to be kept "free" and not defined
explicitly.

> 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.

   You have a really good point there.  But any user that can grasp
the node system in general I think will pick it up with little
difficulty, requiring only a short explanation.

   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.

--Nathan V


More information about the Bf-committers mailing list