[Bf-committers] Node Unification.. it's a bit winded

[Tyler Tricker]

Possibly.. and probably the idea is progression using the current system as
a guide. Right now the node systems are unified in the sense; they fall into
the same rendering pipeline. eg, the texture nodes eventually get plugged
into a material( in most cases) but this isn't represented in a graph. It's
done in the Map input panel for the material. Even if the texture node
chains where mutually exclusive (which they are now), just the visual
representation would give a better sense of what is going on. I would even
settle for just having the oops viewer being able to visually map the links
and nodes (maybe vars too) without the user having ability to edit them.

...wait how did I get sucked into this debate? lol

On Wed, Jun 17, 2009 at 12:57 PM, joe <joeedh at gmail.com> wrote:

> Honestly, I don't think we're ever going to have a unified node tree
> system,
> at least from  the UI perspective of things.  It's just too potentially
> unstable.
>
> Joe
>
> On Wed, Jun 17, 2009 at 4:17 AM, Tyler Tricker <tntricker at gmail.com>
> wrote:
>
> > It's 3:00am and apparently I feel like kicking a dead horse so.
> >
> >
> > Node Unification –the main idea behind unifying the nodes is mostly
> > combining the branched editors for one, and expanding upon the idea. Not
> > only can this be used with only the current node trees but can be used to
> > extend and replace the entire material/composting/audio/game engine/and
> > rendering system front end.
> >
> >
> >
> > The node food chain
> >
> >
> >
> Constant<Signal/Expression<Map<Texture<Filters<Material<Geometry<Object<Group<Modifiers
> > <world<Scene<Game Engine & Render & Animation<Blender (*note this is just
> > an
> > outline, for conceptual purposes only; things still have to be hashed
> out.
> > Like filters would mix with every lower node or each filter would be
> > duplicated for each level. Also the hierarchy is kind of long I’m sure
> > there
> > is a way to simplify the lower levels)
> >
> > Scene-to-color link wouldn’t make sense in the context of a node editor;
> > neither would a color-to-scene. There is a natural hierarchy.
> >
> > http://ww.nodejoe.net/forum/userpix/3_DropMaterialNodeJoe_1.jpg
> >
> > http://www.darksim.com/assets/images/ssDarkTreeEditor.jpg
> >
> > These are examples from  competing applications sporting a comprehensive
> > node editor. There is a natural order. Looks like a DAG scene graph would
> > be
> > a good starting solution. There is already a big step already completed
> in
> > having a comprehensive node system in blender. It’s staring most people
> in
> > the face and they don’t even realize it. The “outliner OOPS” window
> already
> > shows how data blocks are linked and the hierarchy of… well
> > everything(except nodes). What also makes this solution even more
> > noteworthy
> > is that much of the current code wouldn’t have to change. Only a new
> editor
> > would need to be written filling in what the outliner doesn’t show and
> > being
> > able to directly change and manipulate links and fields. There is no
> > rewriting the kernel, changing file formats, passing function pointers,
> or
> > even modifying the current node system. All it does is take the old
> > separate
> > systems and push many of them into a single DAG editor.
> >
> >
> >
> > Transversals and precomputation
> >
> > This proposes a new method for precomputation during user time(well maybe
> > not new.. but revised). The main idea behind an advanced node system with
> > precomputation can be thought of as a push-pull strategy. Static data
> > (images, mesh, audio) can be calculated into a buffer and pushed up the
> > tree
> > but dynamic data (say explicit surfaces, scripted functions, textures,
> > filters, modifiers) must be pulled up from the bottom upon the tree for
> > accuracy(which follows the raytracing paradigm pretty well). I know that
> > data sampled above the nyquist frequency (which was proposed by robin on
> > the
> > mailing list) will prevent aliasing but the problem in sampling analog
> > functions is the bottom nodes don’t know what the nyquist values are, and
> > in
> > long filter chains the numbers can grow extremely large and lead to a
> > memory
> > wall. So data must be pulled up through the chain through the dynamic
> nodes
> > (as the system currently does); but this doesn’t mean the system can’t be
> > made more efficient. Culling in sampling chains, similar to what is
> already
> > found in geometric scene graphs can be used and samples previously called
> > from other branches can be cached as long as no ‘critical’ changes were
> > made
> > in the lower or higher levels.
> >
> > *Special case Flattening nodes (eg. to tex>image) nodes can be used to
> make
> > long dynamic chains static. This would make the scenario of 1000 chained
> > filters just a single processed image and greatly hasten processing and
> > rendering (without the need for baking). Modifiers, surfaces and object
> > casting can follow the same sort of optimization flattening
> optimizations.
> >
> > Progressive GLSL/CPU background raytracing could be a very useful step
> for
> > pulling data through a dynamic chain. Rendering previews and the current
> > scene frame could take place at a low throttle in the back ground while
> the
> > user is working. If the user does click to render the scene blender
> should
> > put the job into high priority to finish it. This should be possible with
> > the use of job queuing (for internal renderer only).
> >
> >
> >
> > Standard Idle job order (automatically jumps to this mode after editing)
> >
> > <-static data calc (if needs updating)
> >
> > <-node previews
> >
> > <-Frame Render
> >
> > <-Animation Render
> >
> > <-spin till scene changes
> >
> >
> >
> > Modified to active job (render frame)
> >
> > <-static data calc (if needs updating)
> >
> > <-Frame Render
> >
> > <-node previews
> >
> > <-Animation Render
> >
> > <-spin till scene changes
> >
> >
> >
> > Modified to active job (render animation)
> >
> > <-static data calc
> >
> > <-Animation Render <- elevated
> >
> > <-node previews
> >
> > <-Frame Render (if needed)
> >
> > <-spin till scene changes
> >
> >
> >
> > Modified to active job(game engine)
> >
> > <-static data calc(if needed)
> >
> > <-spin until game mode exits
> >
> >
> >
> > In any solution, it is up to the users to use to the system effectively.
> > While a chain of 1000 filters will be slow, the system should still be
> > stable and responsive. Progress bars on the working node (or processing
> > node) could be shown to give the user an idea on how efficient their
> method
> > is.
> >
> >
> >
> > Nodes as a Future Feature
> >
> > Looking forward node graph scripting can become a very popular for
> > implementing procedural textures, objects, sounds, etc. and will pave way
> > for tighter script integration with the user interface without the threat
> > of
> > interface bloat.
> >
> > Rendering can be made faster than any current graphics system by a fusion
> > of
> > precomp, hardware acceleration, and network framework management. Samples
> > can later on be computing using massive parallel job threading with
> OpenCL
> > with CPU management.
> >
> > A strong modular design could also help bring the game engine and
> animation
> > systems closer together by the game engine being able to manipulate node
> > mechanics on other systems, like particle.
> >
> > Baked textures can be stored in a flattening node chain and later be
> > revised
> > and modified without burdening the system or requiring file swaps.
> >
> > Can open a door for other powerful features previously related to as
> > complicated (or unimportant) within blender: parametric objects via
> object
> > node scripting, complicated procedural textures, brep objects, nurbs via
> > scripts, etc.
> >
> >
> >
> > Other thoughts
> >
> > Script package management tools (archive bundling, direct from archive
> > loading, script archive .blend packing) would be extremely useful in
> > extending the node system
> >
> >
> > why this should not be implemented... because it's a massive revision of
> > the
> > UI... and possibly insane. honestly I don't even know if I am making any
> > sense anymore.. or was to begin with.
> > _______________________________________________
> > 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
>