benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

(cont) output handling considerations

Browse source
This commit is contained in:
Fischlurch 2010-07-09 03:58:19 +02:00
parent fb43061159
commit 87669dca58
1 changed files with 18 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
wiki/renderengine.html
View file

@ -2593,7 +2593,7 @@ The operation point is provided by the current BuilderMould and used by the [[pr
This is possible because the operation point has been provided (by the mould) with informations about the media stream type to be wired, which, together with information accessible at the the [[render node interface|ProcNode]] and from the [[referred processing assets|ProcAsset]], with the help of the [[connection manager|ConManager]] allows to figure out what's possible and how to do the desired connections. Additionally, in the course of deciding about possible connections, the PathManager is consulted to guide strategic decisions regarding the [[render node configuration|NodeConfiguration]], possible type conversions and the rendering technology to employ.
</pre>
</div>
<div title="OutputDesignation" modifier="Ichthyostega" modified="201006270423" created="201006220126" tags="Model draft design discuss" changecount="21">
<div title="OutputDesignation" modifier="Ichthyostega" modified="201007090132" created="201006220126" tags="Model draft design discuss" changecount="22">
<pre>__6/2010__: an ever recurring (and yet unsolved) problem in the design of Luimiera's ~Proc-Layer is how to refer to output destinations, and how to organise them.
To get ahead with this problem, I'll start collecting observations, relations and drafts on this tiddler.
@ -2620,7 +2620,7 @@ To get ahead with this problem, I'll start collecting observations, relations an
** within the body of the model, mostly we address output destinations relatively
** at some point, we'll address a //subgroup// within the global pipes, which acts like a summation sink
** there might be //master pipes//
** finally, there is the hardware output or the distinct channel within the rendered result &amp;mdash; but this is never referred explicitly
** finally, there is the hardware output or the distinct channel within the rendered result &amp;mdash; never to be referred explicitly
!!!relation to Pipes
in almost every case mentioned above, the output designation is identical with the starting point of a [[Pipe]]. This might be a global pipe or a ClipSourcePort. Thus it sounds reasonable to use pipe-~IDs directly as output designation. Pipes, as an accountable entity (=asset) just //leap into existence by being referred.// On the other hand, the //actual// pipe is a semantic concept, a specific structural arrangement of objects. Basically it means that some object acts as attachment point and thereby //claims//&amp;nbsp; to be the entrance side of a pipe, while other processor objects chain up in sequence.
!!!system outputs
@ -2628,6 +2628,22 @@ System level output connections are the exception to the above rule. There is no
!!!consequences of mentioning an output designation
The immediate consequence is that an connection to this designation is wired, using an appropriate [[processing pattern|ProcPatt]]. A further consequence is for the mentioned output designation to appear as exit node of the built render nodes network.
</pre>
</div>
<div title="OutputManagement" modifier="Ichthyostega" modified="201007090157" created="201007090155" tags="Model Rendering Player spec draft" changecount="3">
<pre>''writing down some thoughts''
* ruled out the system outputs as OutputDesignation.
* thus, any designation is a [[Pipe]]-ID.
* consequently, it is not obviously clear if such an designation is the final exit point
* please note the [[Engine interface proposal|http://lumiera.org/Lumiera/DesignProcess/EngineInterfaceOverview.html]]
* this introduces the notion of a ModelPort: //a point in the (high level) model where output can be produced//
Do we get a single [[Fixture]] &amp;mdash; guess yes
From the implementation side, the only interesting exit nodes are the ones to be //actually pulled,// i.e. those immeditately corresponding to the final output.
* __rendering__ happens immediately at the output of a GlobalPipe (i.e. at a [[Timeline]], which is top-level)
* __playback__ always happens at a viewer element
</pre>
</div>
<div title="Overview" modifier="Ichthyostega" modified="200906071810" created="200706190300" tags="overview img" changecount="13">