[Bf-committers] Proposal for unifying nodes

Nathan Vegdahl cessen at cessen.com
Wed Jun 17 01:32:11 CEST 2009

    Another thought: I do wonder how texture nodes are supposed to be
used in other tree types if their coordinates are implicit, rather
than having explicit coordinate inputs.
    In, say, constraint nodes there would be no context for the
implicit coordinates to come from.

--Nathan V

On Tue, Jun 16, 2009 at 3:20 PM, Nathan Vegdahl<cessen at cessen.com> wrote:
>>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