[Bf-committers] Proposal for unifying nodes

[Robin Allen]

Hi Aurel, thanks for your comments.

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

> I would rather stick to a data stream model, functions as data type
> doesn't seem to be a good idea.

The reason I'm thinking functions, at least for textures and shaders,
is that both of these -- well, they pretty much *are* functions. In a
texture, you pass in the same coordinates, you get out the same color,
and you can pass in whatever coordinates you want. That fits the
mathematical definition of a function perfectly. Similarly, for
shaders, you pass in the same ShaderInfo, you get out the same color.
There is a phrase in multithreaded programming that a problem is
'embarassingly parallel', i.e. it fits the description of a
multithreaded task so well that you'd be a fool not to use threads. It
seems to me that manipulating textures and shaders is embarassingly
functional.

Now, note that I'm not suggesting that the new node system dictate
that all data types be functions, just that that would be the best
representation of textures and shaders (and probably compositors). If
a problem arises which is better solved by streams (audio nodes? Who
knows) then a stream data type can be used for that. The unified
system wouldn't care whether the data represented functions or
streams, it would just return an instance of it and then you can
evaluate it until the cows come home. The important thing is that all
data types can coexist within any tree.

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

That's actually not how texture nodes work at the moment -- the
current texture nodes use a struct called tex_delegate and are really
represented more as functions. The problem you describe about making
the entire texture available was the reason I changed to the current
system, because otherwise rotation and scale nodes (and, as you said,
convolution) simply aren't possible. So, if I understand you
correctly, that particular problem is already solved.

-Rob

2009/6/14 Aurel W. <aurel.w at gmail.com>:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>