[Bf-committers] Proposal for unifying nodes

[Robin Allen]

2009/6/17 Nathan Vegdahl <cessen at cessen.com>:
>> 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
>
>    Good point.  A data-oriented system can't do things like blurring
> procedural textures.  And if we were only developing a texture
> generating system, I might be all for this.
>    But I'm not sure how this concept can fit nicely into things like
> shader nodes, constraint nodes, modifier nodes, etc.  Where are the
> "functions" in those, other than in the nodes themselves?

Hey, no-one's saying that everything has to be functions. It may well
turn out that functions aren't the best way to implement constraint
and modifier nodes. The important thing is that we don't rely on magic
contextual data.

>    I am also now wondering how *either* of our proposed systems could
> work for something like a particle node-system, which I imagine would
> be more logic and state-based, rather than data or function-object
> based.

Yeah, this definitely needs some thought. Maybe the nodes would define
a program to be executed. You'd have a node that executed its inputs
in sequence, one that executed them in parallel, one that did a loop.
XSI has particle nodes, might be an idea to have a look at those.

-Rob

>
>   Hrm...
>
> --Nathan V
>
>
> On Tue, Jun 16, 2009 at 5:05 PM, Robin Allen<roblovski at gmail.com> wrote:
>> 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
>> _______________________________________________
>> 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
>