[Bf-committers] Node Unification.. it's a bit winded
tntricker at gmail.com
Thu Jun 18 04:54:33 CEST 2009
... I swear that's what I ment by keeping the chains exclusive, but yes the
idea would be to not to rewrite the backend but to put the editors in view
of each other, little more then a difference in ui..(at least to start with
anyway). Separate classes of chained nodes could only be joined at certain
nodes (which I guess you could call bridge/adapter nodes). It would follow
the same internal structures that the older material syste, has but be
manipulated through links instead of fields. and on that note...
> Some functions need no more than to get a value (no need for context
> information, no need to get the value of another coordinate), make some
> calculations with it and deliver the result value. I think it might be
> to implement a node type for this case and implement appropriate adaptors
> just C macros to speed it up) in all node systems so nodes of this type
> plugged into all node systems. Nodes that can be reduced to this logic
> already there in more than one node system, and have duplicated code, and
> actually had bugs because of the code duplication for which I provided a
> that got committed to svn ages ago which makes me proud) would be:
This is like the push-pull Dag strategy I was saying earlier. A pass on
'Static data' or finite elements would be made first and pushed up to a
buffer/cache.. well I'm sure you get the idea. I don't know why I even
responded to this idea.. probably because having my mailbox filled with
arguments about semantics was driving me nuts. I do like the idea of using
depreciating nodes to convert long complicated graphs into static images.
It's like baking.. but for nodes.
> PS: Now its 3am here too (Austria), so I hope I haven't written a lot of
> nonsense. I'll go to bed now, good night.
Time zones suck don't they :)
On Wed, Jun 17, 2009 at 7:20 PM, joe <joeedh at gmail.com> wrote:
> Good idea, sharing nodes between trees where it makes sense is sensible.
> On Wed, Jun 17, 2009 at 7:17 PM, Mathias
> Panzenböck<grosser.meister.morti at gmx.net> wrote:
> > I'm an outsider (not a blender developer) but observed a lot of this
> > Maybe a compromise would be feasible:
> > While there are certain things that can't be unified because of how the
> > different node systems work (e.g. operates on image buffers where you can
> > all pixels Vs. the call of a function per pixel that calls another
> function on
> > maybe another pixel) some nodes similar in all systems could be unified.
> > Some functions need no more than to get a value (no need for context
> > information, no need to get the value of another coordinate), make some
> > calculations with it and deliver the result value. I think it might be
> > to implement a node type for this case and implement appropriate adaptors
> > just C macros to speed it up) in all node systems so nodes of this type
> can be
> > plugged into all node systems. Nodes that can be reduced to this logic
> (and are
> > already there in more than one node system, and have duplicated code, and
> > actually had bugs because of the code duplication for which I provided a
> > that got committed to svn ages ago which makes me proud) would be:
> > * All kinds of color operations like separate/combine RGBA/HSVA/YUVA,
> > curves etc.
> > * Math
> > * ...
> > Things that would not be possible with this generalized nodes and for
> > therefore specialized nodes in each node system have to be written would
> > * Blur
> > * Rotate/Translate/Scale
> > * ...
> > So rather than completely unifying the node systems to a single one just
> > providing support for such *simple* nodes in each system in order to
> reduce code
> > duplication would seem reasonable to me. Basically you would have the
> > types: SHD, TEX, MAT and SPL (for simple nodes). Nodes written for the
> > type would immediately be available in each system.
> > -panzi
> > PS: Now its 3am here too (Austria), so I hope I haven't written a lot of
> > nonsense. I'll go to bed now, good night.
> > joe wrote:
> >> Honestly, I don't think we're ever going to have a unified node tree
> >> at least from the UI perspective of things. It's just too potentially
> >> unstable.
> >> Joe
> > _______________________________________________
> > 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
More information about the Bf-committers