[Bf-committers] Proposal for unifying nodes

Aurel W. aurel.w at gmail.com
Sun Jun 14 23:14:53 CEST 2009


Hi,

I also think that Nodes would need some redesign, unification, also to
share functionality and to be able to bring more stuff to Nodes (I am
especially looking here on animation and logic). A new branch would be
great imho.

>> Main points
Pretty much detailed ones already, but I would rather start with more
basic design. (It would make sense to think of designing a stream
oriented programming language from the ground up)

You mentioned,...
>> * Expand nodes' data types from (float, vector, color) to include
>> functions and other types
>> * Define a shader to be a function of a ShaderCallData
>> * Define a texture to be a function of a TexCallData
I would rather stick to a data stream model, functions as data type
doesn't seem to be a good idea. Correct me, if I am wrong, because I
don't know for sure how current Texture Nodes do evaluation, but isn't
there a problem already?
Nodes there define a single function R,R->R which can evaluate the
texture node on a certain pixel. The entire output/final Texture is
then evaluated Pixel, by Pixel. This can also be described as, Texture
Nodes pass Pixels from node to node, while Composite Nodes pass whole
Images. But it won't be enough to just process single Pixels in the
pipeline, you would need to make the entire Image/Evaluated-texture
available for each node, before it can determine any of it's output
Pixels. Otherwise stuff like convolution, etc. isn't possible.

I got some ideas on nodes too, to share, but it's late here, so I will
get back to it later ;)

Aurel


2009/6/14 Thomas Dinges <dingto at gmx.de>:
> +1
> That is definetely a step into the right direction!
>
> Robin Allen schrieb:
>> Hi all, I hope this is the right list.
>>
>> After hearing Ton say that nodes might see a recode, and knowing that
>> users are sometimes frustrated by Blender's strict separation of tree
>> types, I thought about ways to change how nodes are evaluated to let
>> users use any nodes in any tree. I've put my ideas up at
>> http://wiki.blender.org/index.php/User:Frr/NodeThoughts . I'd be
>> willing to take this project on if people feel the design is up to
>> scratch, perhaps developing in a branch akin to bmesh.
>>
>> Main points:
>>
>> * Expand nodes' data types from (float, vector, color) to include
>> functions and other types
>> * Define a shader to be a function of a ShaderCallData
>> * Define a texture to be a function of a TexCallData
>> * Allow the user to specify any nodetree outputting a shader to be
>> used as a material tree; any tree outputting a texture to be used as a
>> texture tree; etc.
>> * Define implicit conversions allowing nodes (e.g. Invert) to be
>> defined once to work on colors, and then be automatically converted to
>> work on textures and shaders (since both are defined as functions
>> returning colors).
>> * Results in an extensible node system: instead of defining a new tree
>> type, just define a new data type and some nodes that work on it.
>> * No more duplication of code with tiny changes (math, image...)
>>
>> I'd like to hear any comments or criticisms you might have.
>>
>> -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
>


More information about the Bf-committers mailing list