[grid="all"]
`------------`-----------------------
*State*         _Parked_
*Date*          _2008-03-06_
*Proposed by*   link:Ichthyostega[]
-------------------------------------


Design the Render Nodes interface
---------------------------------
In the current design, the low-level model is comprised of "Render Nodes";
Stean-Layer and Vault carry out some colaboration based on this node network.
 +
Three different interfaces can be identified
 * the node wiring interface
 * the node invocation interface
 * the processing function interface


Description
~~~~~~~~~~~
Render Nodes are created and wired by the Builder in the Steam-Layer. On the
other hand, the rendering process is controlled by the vault layer, which also
provides the implementation for the individual data processing tasks. To create
a result, output nodes are ''pulled'' via the invocation interface, resulting
in the affected nodes to recursively pull their predecessor(s). In the course
of this call sequence, the nodes activate their processing function to work on
a given set of buffers. Moreover, we plan to use the render network also for
gathering statistics.

'''Note''': Render Node is an internal interface used by Steam-Layer and
   activated by the Vault. Plugins are planned to be added via Adapter nodes.
   Thus the Render Node interface needs ''not'' to be exported.


the wiring interface
^^^^^^^^^^^^^^^^^^^^
This part of the design defines how nodes can be combined and wired up by the
builder to form a network usable for rendering. For this purpose, the
link:ProcNode[] is used as a shell / container, which is then configured by a
Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is
preselected to use a combination of specific working modes:

 * participate in caching
 * calculate in-place
 * source reading
 * (planned) use hardware acceleration
 * (planned) remote dispatched calculation

Most nodes will just have a single predecessor, but we can't limit nodes to a
single input, because there are some calculation algorithms which natively need
to work on several data streams simultaneously. This means, a single node can
be involved into the calculations for multiple streams (several pull calls on
the same frame number but for different channel, and in each case maybe a
different output node). I decided to rely solely on the cache for avoiding
duplicate calculations caused by this complication, because I deem it to be an
corner case.


the invocation interface
^^^^^^^^^^^^^^^^^^^^^^^^
this is intended to be a rather simple "call-style" interface, without much
possibilites to influence the way things are happening. You pull a node and
will find the results in a provided buffer or the cache, but you can't even
change the frame data type type of the result. Besides the node invocation,
functions for collecting statistics will be accessible here too (Probably these
functions will be ''implemented'' in a classic-OO fashion by virtual functions,
but that's another story)


the processing interface
^^^^^^^^^^^^^^^^^^^^^^^^
the individual nodes are configured to call a plain-C {{{process()}}} function
and provide an array of buffer pointers to be used within this function. For
the purpose of invoking actual data processing, it is irrelevant if this
function is implemented somewhere in the vault layer or provided by a plugin.
At this point, no type- and other meta-information is passed, rather the
processing function is supposed to do The Right Thing ^TM^



Tasks
^^^^^
 * What services do we expect from Render Nodes. What do we plan to do with a
   render node?
 * What different kinds (if any) of Render Nodes can be foreseen?
 * order the required functionality by Steam / Vault. Find out specific
   implementation constraints.
 * work out a design based on this informations









Rationale
~~~~~~~~~
The purpose of this Design Entry is to give a summary; the questions and the
details of carrying out the operations are much more involved.
 +
Please see the
http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)]
and the
http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code]
for details
(and/or contact Ichthyo for in-depth discussion of those technical details)






Comments
--------


Parked
~~~~~~
We park this until we have time to revisit the details. It is accepted that we
need to design this interfaces.

    Do 14 Apr 2011 03:06:42 CEST Christian Thaeter

Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
