Invocation: documentation for the ''Param Agent'' scheme
This commit is contained in:
parent
16a6a0d630
commit
32c21b6a8f
4 changed files with 179 additions and 43 deletions
|
|
@ -95,8 +95,14 @@
|
|||
** accepts a parameter argument, optionally a such parameter-functor can be installed; this functor
|
||||
** is supplied with the \ref TurnoutSystem of the actual invocation, which acts as front-end to
|
||||
** access contextual parameters.
|
||||
** \par synthesised additional parameters
|
||||
** As an extension for (rare and elaborate) special cases, a special evaluation scheme is provided,
|
||||
** which relies on a »Param Agent Node« as entry point, to invoke additional functors and compute
|
||||
** additional parameter values, which can then be used in a nested _delegate Node tree._
|
||||
** This special scheme can be configured from the [nested Port builder](\ref PortBuilderRoot::computeParam()).
|
||||
** See the detailed description in param-weaving-pattern.hpp
|
||||
**
|
||||
** @todo WIP-WIP-WIP 10/2024 Node-Invocation is reworked from ground up -- some parts can not be
|
||||
** @todo WIP-WIP 1/2025 Node-Invocation is reworked from ground up -- some parts can not be
|
||||
** spelled out completely yet, since we have to build this tightly interlocked system of
|
||||
** code moving bottom up, and then filling in further details later working top-down.
|
||||
**
|
||||
|
|
@ -163,10 +169,19 @@ namespace engine {
|
|||
|
||||
template<class POL, class DAT>
|
||||
class PortBuilderRoot;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Top-level builder to create a single [Render Node](\ref ProcNode)
|
||||
* @note
|
||||
* - Entry-point for the Builder-DSL is \ref prepareNode()
|
||||
* - A sequence of Ports is defined by `.preparePort()` ... `.completePort()`
|
||||
* - the Build is completed with the NodeBuilder::build() terminal,
|
||||
* which generates a \ref Connectivity object, that can be directly
|
||||
* dropped into the constructor of ProcNode.
|
||||
*/
|
||||
template<class POL, class DAT = PatternDataAnchor>
|
||||
class NodeBuilder
|
||||
: util::MoveOnly
|
||||
|
|
@ -222,7 +237,7 @@ namespace engine {
|
|||
* - `withAllocator<ALO> (ALO<X> allo)` uses a C++ standard allocator
|
||||
* instance `allo`, dedicated to produce objects of type `X`
|
||||
* - `withAllocator (AllocationCluster&)` attaches to a specific
|
||||
* AllocationCluster; this is the most relevant usage pattern
|
||||
* AllocationCluster; this is the most relevant usage pattern.
|
||||
*/
|
||||
template<template<typename> class ALO =std::void_t, typename...INIT>
|
||||
auto
|
||||
|
|
@ -254,6 +269,10 @@ namespace engine {
|
|||
|
||||
|
||||
|
||||
/**
|
||||
* Nested DSL builder scope to define a single Port for the enclosing Node.
|
||||
* @note inherits from NodeBuilder and _slices away_ the subclass when done.
|
||||
*/
|
||||
template<class POL, class DAT>
|
||||
class PortBuilderRoot
|
||||
: protected NodeBuilder<POL,DAT>
|
||||
|
|
@ -301,6 +320,11 @@ namespace engine {
|
|||
|
||||
|
||||
|
||||
/**
|
||||
* Nested DSL-Builder context to define a regular media processing Port
|
||||
* @remark relies on [delegate sub-builder](\ref WeavingBuilder) for
|
||||
* technical details of data feed and parameter wiring.
|
||||
*/
|
||||
template<class POL, class DAT, class WAB>
|
||||
class PortBuilder
|
||||
: public PortBuilderRoot<POL,DAT>
|
||||
|
|
@ -312,6 +336,10 @@ namespace engine {
|
|||
|
||||
public:
|
||||
|
||||
/** @remark this would allow to pass constructor arguments
|
||||
* to »buffer inlay objects« automatically placed into media buffers.
|
||||
* There is a corresponding hook in BufferProvider::getDescriptor(args...)
|
||||
*/
|
||||
template<class ILA, typename...ARGS>
|
||||
PortBuilder&&
|
||||
createBuffers (ARGS&& ...args)
|
||||
|
|
@ -320,7 +348,8 @@ namespace engine {
|
|||
return move(*this);
|
||||
}
|
||||
|
||||
/** define the output slot to use as result
|
||||
|
||||
/** define the output slot number to use as result
|
||||
* @remark default is to use the first one */
|
||||
PortBuilder&&
|
||||
asResultSlot (uint r)
|
||||
|
|
|
|||
|
|
@ -26,9 +26,72 @@
|
|||
** recursive Node evaluations. Notably, parameter-functors within the scope of this evaluation tree
|
||||
** can then access these additional parameters through the TurnoutSystem of the overall invocation.
|
||||
**
|
||||
** ## Configuration
|
||||
** In order to setup such an evaluation scheme involving a Parameter Agent as top entrance point,
|
||||
** and a delegate Node tree below, in a first step, the evaluations for the additional parameter
|
||||
** values must be established. This is achieved by defining a _Parameter Build Spec,_ which is
|
||||
** a descriptor record with a builder-DSL notation to be assembled step by step. Internally,
|
||||
** this ParamBuildSpec embeds a tuple of parameter-functors, one for each new parameter value.
|
||||
** Furthermore, since the intended usage scheme calls for a lib::HeteroData »chain block« as
|
||||
** storage for the extended parameter values, an _anchor type_ is embedded into the type signature
|
||||
** of ParamBuildSpec; this _anchor_ is assumed to be the HeteroData-prefix-chain, where the new
|
||||
** data block is assumed to be attached at the end. In the common use case, this prefix will be
|
||||
** the default layout of a TurnoutSystem, which internally embeds a lib::HeteroData record,
|
||||
** configured to hold some basic parameters, which are present in every render invocation:
|
||||
** - the _absolute nominal Time_ in the timeline
|
||||
** - a _process Key_
|
||||
**
|
||||
** Since this is a well-known, fixed layout, the definition of a ParamBuildSpec can be started
|
||||
** from a static convenience function, steam::engine::buildParamSpec(), which yields an (initially
|
||||
** empty) ParamBuildSpec, anchored at the default layout of the TurnoutSystem. On this builder term,
|
||||
** several «parameter slots» can be added successively, either
|
||||
** - by embedding a fixed (constant) parameter value
|
||||
** - or with a parameter-functor, which works on the basic default TurnoutSystem
|
||||
**
|
||||
** Once a ParamBuildSpec is outfitted with all desired functors, it can be used to generate
|
||||
** _accessor functors_ — which are the crucial ingredient for actually accessing the extended
|
||||
** parameter values from the nested node tree. Please recall that also a regular Render Node Port
|
||||
** can embed a parameter-functor, which works on the TurnoutSystem. Usually this param-functor
|
||||
** will retrieve the _absolute nominal time_ from there, but in our case here, the purpose of
|
||||
** the whole elaborate scheme is that such an parameter-functor embedded into some processing
|
||||
** node down in the nested tree can access the extended parameters, which were generated
|
||||
** initially by the Param Agent Node at top-level and reside in a storage block somewhere up
|
||||
** the call stack, from where they are linked-in temporarily into the TurnoutSystem. Thus,
|
||||
** after building the ParamBuildSpec, next some actual Render Nodes have to be built, which
|
||||
** include the _accessor functors_ retrieved from the ParamBuildSpec. These are actually
|
||||
** static type markers, as they do not actually refer to the ParamBuildSpec, but rather to
|
||||
** the «slot number» in the structure (which is encoded into the type signature). Such an
|
||||
** accessor functor can be applied to the extended TurnoutSystem, and will retrieve the
|
||||
** corresponding extended parameter value from the chain-block linked temporarily into
|
||||
** the TurnoutSystem.
|
||||
**
|
||||
** Finally, when the nested delegate Node tree is complete, the actual Param Agent Node
|
||||
** can be built through a special hook in the NodeBuilder: After opening the nested definition
|
||||
** of a port, invoke steam::engine::PortBuilderRoot::computeParam(spec), passing the ParamBuildSpec
|
||||
** record (with the actual functor instances embedded!). Furthermore, the link to the delegate
|
||||
** Node tree must be added, followed by `.completePort()`. Optionally, a post-processing functor
|
||||
** can be added, which will be invoked after all parameters are generated, but before delegating
|
||||
** to the nested Node tree.
|
||||
**
|
||||
** As should be clear from context, the so called »Param Agent Node« is actually a special port.
|
||||
** Yet in practice, you'd typically set up a top-level node, where each port is configured with
|
||||
** a suitable Param Agent setup, and then delegates to the processing chain to produce the
|
||||
** content to produce for this port. Internally, this Param Agent setup is a Turnout (thus
|
||||
** implementing the Port interface) with a special \ref ParamWeavingPattern. The latter
|
||||
** incorporates all the steps necessary to establish this special extended parameter setup
|
||||
** - it first invokes all the parameter-functors in the tuple
|
||||
** - it forms a parameter tuple from the result values
|
||||
** - this parameter-tuple is dropped off into a storage within the current stack frame
|
||||
** - then this storage block (which is a valid HeteroData chain-block), will be linked
|
||||
** temporarily with the current TurnoutSystem of the invocation
|
||||
** - next an optional postprocessing-functor will be invoked
|
||||
** - followed by a regular recursive invocation of the delegate tree
|
||||
** - as a last step, the temporary storage block is disconnected from the TurnoutSystem
|
||||
** - and the result buffer of the recursive delegate tree is returned as result.
|
||||
**
|
||||
** @see node-builder.hpp
|
||||
** @see weaving-pattern-builder.hpp
|
||||
** @see NodeFeed_test::feedParamNode()
|
||||
** @see \ref NodeFeed_test::feedParamNode() "elaborate demonstration example"
|
||||
** @see \ref proc-node.hpp "Overview of Render Node structures"
|
||||
**
|
||||
** @warning WIP as of 12/2024 first complete integration round of the Render engine ////////////////////////////TICKET #1367
|
||||
|
|
@ -46,12 +109,7 @@
|
|||
#include "lib/meta/variadic-helper.hpp"
|
||||
#include "lib/meta/tuple-helper.hpp"
|
||||
#include "lib/meta/function.hpp"
|
||||
#include "lib/several.hpp"
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
//#include "lib/time/timevalue.hpp"
|
||||
//#include "lib/util.hpp" ////////OOO wegen manifoldSiz<FUN>()
|
||||
|
||||
//#include <stack>
|
||||
#include <tuple>
|
||||
#include <utility>
|
||||
|
||||
|
|
@ -68,6 +126,16 @@ namespace engine {
|
|||
using lib::meta::ElmTypes;
|
||||
|
||||
|
||||
/**
|
||||
* Specification record for the setup of a »Param Agent Node«.
|
||||
* @tparam ANCH the lib::HeteroData prefix-chain to use as anchor point
|
||||
* @tparam FUNZ a set of parameter-functors used to generate additional parameter values.
|
||||
* @note This template provides a builder-DSL notation, starting with the free function
|
||||
* \ref buildParamSpec(). Further parameter «slots» can be added step by step.
|
||||
* @remark use the nested Accessor records to retrieve the generated parameter values
|
||||
* and use the nested BlockBuilder as a »Prototype« in the ParamWeavingPattern,
|
||||
* which actually can be configured through the NodeBuilder...
|
||||
*/
|
||||
template<class ANCH, typename...FUNZ>
|
||||
struct ParamBuildSpec
|
||||
{
|
||||
|
|
@ -112,10 +180,10 @@ namespace engine {
|
|||
}
|
||||
|
||||
/** @internal the _chain constructor type_ is a type rebinding meta function (nested struct),
|
||||
* which extends the HeteroData chain given by \a ANK with the sequence of types derived from
|
||||
* which extends the HeteroData chain given by \a ANCH with the sequence of types derived from
|
||||
* the result-values of all functors stored in the ParamBuildSpec, i.e. the resulting param tuple.
|
||||
* @remark HeteroData defines a nested struct `Chain`, and with the help of `RebindVariadic`,
|
||||
* the type sequence from the ParamTup can be used to instantiate this Chain context.
|
||||
* the type sequence from the ParamTup can be used to instantiate this chain constructor.
|
||||
*/
|
||||
using ChainCons = typename lib::meta::RebindVariadic<ANCH::template Chain, ParamTup>::Type;
|
||||
|
||||
|
|
@ -140,6 +208,12 @@ namespace engine {
|
|||
return Accessor<idx>{};
|
||||
}
|
||||
|
||||
/**
|
||||
* @internal Helper: after the ParamBuildSpec is complete,
|
||||
* it will be packaged into a BlockBuilder, which is then embedded
|
||||
* as a kind of »Prototype« into the `Turnout<ParamWeavingPattern>`
|
||||
* @remark #emplateParamDataBlock is invoked on each Node activation.
|
||||
*/
|
||||
class BlockBuilder
|
||||
: util::MoveOnly
|
||||
{
|
||||
|
|
@ -179,7 +253,7 @@ namespace engine {
|
|||
/**
|
||||
* Terminal Builder: (destructively) transform this ParamBuildSpec
|
||||
* into a BlockBuilder, which can then be used to create a Parameter data block,
|
||||
* thereby invoking the embedded functors and drop-off the results into storage.
|
||||
* thereby invoking the embedded functors to drop-off the results into storage.
|
||||
*/
|
||||
BlockBuilder
|
||||
makeBlockBuilder()
|
||||
|
|
@ -195,8 +269,16 @@ namespace engine {
|
|||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Implementation for a _Weaving Pattern_ to conduct extended parameter evaluation.
|
||||
* A tuple of parameter-functors is embedded and will be invoked on each activation,
|
||||
* to generate a tuple of parameter-values, which are placed into the local stack
|
||||
* frame and then made accessible through the TurnoutSystem. Then the delegatePort_
|
||||
* is invoked recursively; the additional parameter values are thus usable from
|
||||
* within all nodes contained therein, during this recursive evaluation.
|
||||
*/
|
||||
template<class SPEC>
|
||||
struct ParamWeavingPattern
|
||||
|
|
@ -211,6 +293,7 @@ namespace engine {
|
|||
PostProcessor postProcess_;
|
||||
Port& delegatePort_;
|
||||
|
||||
/** Storage data frame placed on the call stack */
|
||||
struct Feed
|
||||
: util::NonCopyable
|
||||
{
|
||||
|
|
@ -227,7 +310,7 @@ namespace engine {
|
|||
};
|
||||
|
||||
|
||||
/** forwarding-ctor to provide the detailed input/output connections */
|
||||
/** forwarding-ctor to used from within Turnout, to provide actual setup. */
|
||||
ParamWeavingPattern (BlockBuilder builder, PostProcessor postProc, Port& delegate)
|
||||
: blockBuilder_{move (builder)}
|
||||
, postProcess_{move (postProc)}
|
||||
|
|
@ -251,7 +334,7 @@ namespace engine {
|
|||
|
||||
/** Link the param-data-block into the current TurnoutSystem,
|
||||
* possibly post-process the param data. From this point on,
|
||||
* nodes within the nested scope can draw from this data.
|
||||
* Nodes within the nested scope can draw from this data.
|
||||
*/
|
||||
void
|
||||
shed (Feed& feed, TurnoutSystem& turnoutSys, OptionalBuff outBuff)
|
||||
|
|
@ -281,10 +364,8 @@ namespace engine {
|
|||
turnoutSys.detachChainBlock(feed.block());
|
||||
return *feed.outBuff;
|
||||
}
|
||||
|
||||
};
|
||||
|
||||
|
||||
|
||||
}}// namespace steam::engine
|
||||
#endif /*STEAM_ENGINE_PARAM_WEAVING_PATTERN_H*/
|
||||
|
|
|
|||
|
|
@ -5253,7 +5253,7 @@ Arrangement and interaction of components in the three Layers — {{red{envision
|
|||
</html>
|
||||
</pre>
|
||||
</div>
|
||||
<div title="OverviewRenderEngine" modifier="Ichthyostega" created="200706190647" modified="202304140057" tags="Rendering overview" changecount="17">
|
||||
<div title="OverviewRenderEngine" modifier="Ichthyostega" created="200706190647" modified="202501050056" tags="Rendering overview" changecount="18">
|
||||
<pre>As can be seen on the [[Architecture Overview|Overview]], the functionality of the »[[Render Engine|RenderEngine]]« is implemented through the collaboration of various components, spanning the Steam-Layer and the Vault-Layer. The rendering is orchestrated by „performing“ the LowLevelModel, which is a //node graph//. This render node graph has been prepared by the [[Builder]] -- thereby reading and interpreting the HighLevelModel, which is maintained and edited as part of the [[Session]]. The actual rendering happens when the [[Scheduler]] invokes individual [[render jobs|RenderJob]] to invoke media processing functions configured and wired as [[Processing Nodes|ProcNode]], thus generating new media data into the [[processing buffers|BufferProvider]] for [[output|OutputManagement]].
|
||||
|
||||
Any kind of rendering or playback requires a RenderProcess, which is initiated and controlled by the [[Player]].
|
||||
|
|
@ -5263,7 +5263,7 @@ see also &rarr; [[Fixture]] &rarr; [[Player]] &rarr; EngineFaçade &
|
|||
{{red{TODO 4/23: create a new drawing to reflect current state of the design}}}
|
||||
|
||||
!Render Engine Integration
|
||||
The Engine is unfinished and not in any usable shape {{red{as of 4/2023}}} -- currently an [[»integration slice«|PlaybackVerticalSlice]] is pursued, in an effort to complete foundation work done over the course of several years and achieve the first preliminary integration of rendering functionality.
|
||||
The Engine is unfinished and not in any usable shape {{red{as of 1/2025}}} -- currently an [[»integration slice«|PlaybackVerticalSlice]] is pursued, in an effort to complete foundation work done over the course of several years and achieve the first preliminary integration of rendering functionality.
|
||||
|
||||
Why is ''all of this so complicated''?
|
||||
* the Lumiera application is envisioned as a very flexible setup
|
||||
|
|
@ -6228,7 +6228,7 @@ __December.24__: after an extended break of several months (due to family-relate
|
|||
:Unfortunately, we are not sufficiently naïve to [[believe into the 15th standard to rule them all|https://xkcd.com/927/]]. And this implies that the design confronts the extremely challenging task to handle the mapping into several Domain Ontologies. The approach pursued for this is to //deflect decisions back// into a //binding,// which is provided by a Plug-in to attach an external Media-handling Library. Building such a Plug-in and binding will in itself be difficult for sure. It will have to respond to some pre-defined queries how to deal with aspects relevant for processing an arrangement of media. This includes the enumeration of [[processing assets|ProcAsset]] and [[Stream Type instances|StreamType]], and the implementation for a function to //outfit// a render node with a //function binding// to invoke the implementation of a processing asset.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Player" modifier="Ichthyostega" created="201012181700" modified="202304140114" tags="def overview" changecount="4">
|
||||
<div title="Player" modifier="Ichthyostega" created="201012181700" modified="202501050055" tags="def overview" changecount="5">
|
||||
<pre>Within Lumiera, &raquo;Player&laquo; is the name for a [[Subsystem]] responsible for organising and tracking //ongoing playback and render processes.// &rarr; [[PlayProcess]]
|
||||
The player subsystem does not perform or even manage any render operations, nor does it handle the outputs directly.
|
||||
Yet it addresses some central concerns:
|
||||
|
|
@ -6243,8 +6243,8 @@ Yet it addresses some central concerns:
|
|||
:to perform this [[quantisation|TimeQuant]], the help of the session for building a TimeGrid for each output channel is required.
|
||||
|
||||
|
||||
!{{red{WIP 4/2023}}} still not finished
|
||||
The design of the Player subsystem was settled several years ago, together with a draft implementation of the FrameDispatcher and some details regarding [[render jobs|RenderJob]] and [[processing nodes|ProcNode]]. The implementation could not be finished at that time, since too much further details in other parts of the engine were not quite settled yet. After focussing on the GUI for several years, a new effort towards [[integration of rendering|PlaybackVerticalSlice]] has been started...
|
||||
!{{red{WIP 1/2025}}} still not finished
|
||||
The design of the Player subsystem was settled several years ago, together with a draft implementation of the FrameDispatcher and some details regarding [[render jobs|RenderJob]] and [[processing nodes|ProcNode]]. The implementation could not be finished at that time, since too much further details in other parts of the engine were not quite settled yet. After focussing on the GUI for several years, a new effort towards [[integration of rendering|PlaybackVerticalSlice]] has been started, making good progress lately; we can now schedule and invoke render operations...
|
||||
&rarr; [[Rendering]]
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -7098,7 +7098,15 @@ An Activity is //performed// by invoking its {{{activate(now, ctx)}}} function -
|
|||
In a similar vein, also ''dependency notifications'' need to happen decoupled from the activity chain from which they originate; thus the Post-mechanism is also used for dispatching notifications. Yet notifications are to be treated specially, since they are directed towards a receiver, which in the standard case is a {{{GATE}}}-Activity and will respond by //decrementing its internal latch.// Consequently, notifications will be sent through the ''λ-post'' -- which operationally re-schedules a continuation as a follow-up job. Receiving such a notification may cause the Gate to become opened; in this case the trigger leads to //activation of the chain// hooked behind the Gate, which at some point typically enters into another calculation job. Otherwise, if the latch (in the Gate) is already zero (or the deadline has passed), nothing happens. Thus the implementation of state transition logic ensures the chain behind a Gate can only be //activated once.//
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RenderProcess" modifier="Ichthyostega" created="200706190705" modified="202412221701" tags="Rendering operational" changecount="26">
|
||||
<div title="RenderParamHandling" creator="Ichthyostega" modifier="Ichthyostega" created="202501050139" modified="202501050143" changecount="6">
|
||||
<pre>//Invocation- and ~Configuration-Parameters are essential for rendering.//
|
||||
Typically, a processing operation can be configured in various ways, by passing additional setup- and invocation parameters. This entails both technical aspects (like picking some specific data format), organisational concerns (like addressing a specific frame-number) and elements of artistic control, like choosing the settings of a media processing effect. Parameters will thus be collected from various sources, which leads to an additional binding step, where all these sources are retrieved and the actual parameter value or value tuple is produced. This specific //parameter binding// is represented as a [[Parameter-functor|NodeParamFunctor]]. Whenever the processing-function accepts a parameter argument, optionally a such parameter-functor can be installed; this functor is supplied with the TurnoutSystem of the actual invocation, which acts as front-end to access contextual parameters.
|
||||
!Synthesised additional parameters
|
||||
As an extension for (rare and elaborate) special cases, a special evaluation scheme is provided, which relies on a »''Param Agent Node''« as entry point, to invoke additional functors and compute additional parameter values, which can then be used in a nested //delegate Node tree.// The solution relies on placing those additional data values into a tuple, which is then stored directly in the render invocation stack frame, prior to descending into the recursive Node evaluations. Parameter-functors within the scope of this evaluation tree can then access these additional parameters through the TurnoutSystem of the overall invocation.
|
||||
|
||||
The use-case is to provide a set of additional parameter values, beyond what can be derived directly by a parameter-functor based on the //absolute-nominal-Time// of the invocation. The necessity for such a setup may arise when additional context or external state must be combined with the nominal time into a tuple of data values, which shall then be consumed by several follow-up evaluations further down into a //recursive invocation tree for one single render job.//</pre>
|
||||
</div>
|
||||
<div title="RenderProcess" modifier="Ichthyostega" created="200706190705" modified="202501050058" tags="Rendering operational" changecount="27">
|
||||
<pre>At a high level, the Render Process is what „runs“ a playback or render. Using the EngineFaçade, the [[Player]] creates a descriptor for such a process, which notably defines a [[»calculation stream«|CalcStream]] for each individual //data feed// to be produced. To actually implement such an //ongoing stream of timed calculations,// a series of data frames must be produced, for which some source data has to be loaded and then individual calculations will be scheduled to work on this data and deliver results within a well defined time window for each frame. Thus, on the implementation level, a {{{CalcStream}}} comprises a pipeline to define [[render jobs|RenderJob]], and a self-repeating re-scheduling mechanism to repeatedly plan and dispatch a //chunk of render jobs// to the [[Scheduler]], which cares to invoke the individual jobs in due time.
|
||||
|
||||
This leads to a even more detailed description at implementation level of the ''render processing''. Within the [[Session]], the user has defined the »edit« or the definition of the media product as a collection of media elements placed and arranged into a [[Timeline]]. A repeatedly-running, demand-driven, compiler-like process (in Lumiera known as [[the Builder|Builder]]) consolidates this [[»high-level definition«|HighLevelModel]] into a [[Fixture]] and a [[network of Render Nodes|LowLevelModel]] directly attached below. The Fixture hereby defines a [[segment for each part of the timeline|Segmentation]], which can be represented as a distinct and non-changing topology of connected render nodes. So each segment spans a time range, quantised into a range of frames -- and the node network attached below this segment is capable of producing media data for each frame within definition range, when given the actual frame number, and some designation of the actual data feed required at that point. Yet it depends on the circumstances what this »data feed« //actually is;// as a rule, anything which can be produced and consumed as compound will be represented as //a single feed.// The typical video will thus comprise a video feed and a stereo sound feed, while another setup may require to deliver individual sound feeds for the left and right channel, or whatever channel layout the sound system has, and it may require two distinct beamer feeds for the two channels of stereoscopic video. However -- as a general rule of architecture -- the Lumiera Render Engine is tasked to perform //all of the processing work,// up to and including any adaptation step required to reach the desired final result. Thus, for rendering into a media container, only a single feed is required, which can be drawn from an encoder node, which in turn consumes several data feeds for its constituents.
|
||||
|
|
@ -7114,8 +7122,8 @@ To summarise this break-down of the rendering process defined thus far, the [[Sc
|
|||
|
||||
__see also__
|
||||
&rarr; the [[Entities involved in Rendering|RenderEntities]]
|
||||
&rarr; the [[mechanics of rendering and buffer management|RenderMechanics]]
|
||||
&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
|
||||
&rarr; the [[mechanics of rendering and buffer management|RenderMechanics]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Rendering" modifier="Ichthyostega" created="200806010248" modified="202410292249" tags="def overview" changecount="1">
|
||||
|
|
|
|||
|
|
@ -94188,8 +94188,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133492043" ID="ID_901061219" MODIFIED="1734133509737" TEXT="ParamWeavingPattern hinzubauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1734133492043" ID="ID_901061219" MODIFIED="1736039264581" TEXT="ParamWeavingPattern hinzubauen">
|
||||
<arrowlink COLOR="#68b4c1" DESTINATION="ID_326138637" ENDARROW="Default" ENDINCLINATION="-107;-859;" ID="Arrow_ID_823498851" STARTARROW="None" STARTINCLINATION="-199;16;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -94198,8 +94199,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<linktarget COLOR="#4033e3" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="-2228;-103;" ID="Arrow_ID_1086551966" SOURCE="ID_1769136387" STARTARROW="None" STARTINCLINATION="1977;97;"/>
|
||||
<linktarget COLOR="#ff6936" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="-641;1944;" ID="Arrow_ID_1163958018" SOURCE="ID_311704401" STARTARROW="None" STARTINCLINATION="1383;132;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1735416170297" ID="ID_736958022" MODIFIED="1735519479807" TEXT="brauche ParamBuildSpec">
|
||||
<linktarget COLOR="#bb1f2e" DESTINATION="ID_736958022" ENDARROW="Default" ENDINCLINATION="-25;-162;" ID="Arrow_ID_44922252" SOURCE="ID_1577179744" STARTARROW="None" STARTINCLINATION="32;153;"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1735416170297" ID="ID_736958022" MODIFIED="1736039360054" TEXT="brauche ParamBuildSpec">
|
||||
<linktarget COLOR="#1f46bb" DESTINATION="ID_736958022" ENDARROW="Default" ENDINCLINATION="-25;-162;" ID="Arrow_ID_44922252" SOURCE="ID_1577179744" STARTARROW="None" STARTINCLINATION="32;153;"/>
|
||||
<linktarget COLOR="#87a8af" DESTINATION="ID_736958022" ENDARROW="Default" ENDINCLINATION="72;477;" ID="Arrow_ID_699899530" SOURCE="ID_348395437" STARTARROW="None" STARTINCLINATION="-1970;83;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1735422554816" ID="ID_197118422" MODIFIED="1735438575232" TEXT="Aufgabe: schrittweise aufbaubar">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
|
|
@ -94373,12 +94375,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1735416468553" ID="ID_1257939291" MODIFIED="1735416600613" TEXT="dient als Basis für einen ParamNode-Builder">
|
||||
<arrowlink COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" STARTARROW="None" STARTINCLINATION="-633;42;"/>
|
||||
<node BACKGROUND_COLOR="#c2b6c8" COLOR="#435e98" CREATED="1735416468553" ID="ID_1257939291" MODIFIED="1736040774386" TEXT="dient als Basis für einen ParamNode-Builder">
|
||||
<arrowlink COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" STARTARROW="None" STARTINCLINATION="-647;38;"/>
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1735607847586" ID="ID_326138637" MODIFIED="1735698010312" TEXT="Weaving-Pattern passend anlegen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1735607847586" ID="ID_326138637" MODIFIED="1736040402170" TEXT="Weaving-Pattern passend anlegen">
|
||||
<linktarget COLOR="#68b4c1" DESTINATION="ID_326138637" ENDARROW="Default" ENDINCLINATION="-107;-859;" ID="Arrow_ID_823498851" SOURCE="ID_901061219" STARTARROW="None" STARTINCLINATION="-199;16;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1735606520452" ID="ID_1370206629" MODIFIED="1735607879217" TEXT="Knackpunkt hier: Chain-Block ist non-copyable">
|
||||
<arrowlink COLOR="#71475a" DESTINATION="ID_410550585" ENDARROW="Default" ENDINCLINATION="-194;-5;" ID="Arrow_ID_1355764856" STARTARROW="None" STARTINCLINATION="58;229;"/>
|
||||
<node CREATED="1735606533963" ID="ID_232275034" MODIFIED="1735606547772" TEXT="das geht sehr wohl: FeedManifold ist ebenfalls non-copyable"/>
|
||||
|
|
@ -97503,10 +97507,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<linktarget COLOR="#5732c2" DESTINATION="ID_1282095550" ENDARROW="Default" ENDINCLINATION="-406;569;" ID="Arrow_ID_497899045" SOURCE="ID_35388918" STARTARROW="None" STARTINCLINATION="981;80;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734141168279" ID="ID_1127056731" MODIFIED="1734141875620" TEXT="Pram-Funktor in den Builder einführen">
|
||||
<arrowlink COLOR="#d90755" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="428;-33;" ID="Arrow_ID_1685749535" STARTARROW="None" STARTINCLINATION="-2201;158;"/>
|
||||
<node COLOR="#338800" CREATED="1734141168279" ID="ID_1127056731" MODIFIED="1736038915524" TEXT="Pram-Funktor in den Builder einführen">
|
||||
<arrowlink COLOR="#2bcbc1" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="428;-33;" ID="Arrow_ID_1685749535" STARTARROW="None" STARTINCLINATION="-2223;155;"/>
|
||||
<linktarget COLOR="#0299c0" DESTINATION="ID_1127056731" ENDARROW="Default" ENDINCLINATION="-1257;-48;" ID="Arrow_ID_1717201620" SOURCE="ID_1364724277" STARTARROW="None" STARTINCLINATION="-908;50;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1736038966051" ID="ID_864062784" MODIFIED="1736038996147" TEXT="haben nun einen »Feed Prototype« im MediaWeavingPattern eingebettet"/>
|
||||
<node CREATED="1736038997423" ID="ID_1618027387" MODIFIED="1736039025215" TEXT="dieser enthält die Bau-Anleitung für die Feed-Manifold"/>
|
||||
<node CREATED="1736039026592" ID="ID_1929400746" MODIFIED="1736039037875" TEXT="und zusätzlich / optional einen Parameter-Functor"/>
|
||||
<node CREATED="1736039039923" ID="ID_348395437" MODIFIED="1736039360054" TEXT="Außerdem wurde ein spezielles Param-Agent-Node-Schema definiert">
|
||||
<arrowlink COLOR="#87a8af" DESTINATION="ID_736958022" ENDARROW="Default" ENDINCLINATION="72;477;" ID="Arrow_ID_699899530" STARTARROW="None" STARTINCLINATION="-1970;83;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870929451" ID="ID_1740846481" MODIFIED="1728870951984" TEXT="der Gebrauch des BuffHandle::accessAs<TY>() ist zweifelhaft">
|
||||
|
|
@ -98084,8 +98094,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
per ParamAgentBuilder konstruieren
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#a9b4c1" DESTINATION="ID_600039329" ENDARROW="Default" ENDINCLINATION="-387;16;" ID="Arrow_ID_1024063898" SOURCE="ID_373701114" STARTARROW="None" STARTINCLINATION="-156;-13;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1736003503677" ID="ID_1356439395" MODIFIED="1736015439809" TEXT="brauche nun eine Delegate-Node">
|
||||
|
|
@ -98103,13 +98112,19 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#dee8ae" COLOR="#116b3a" CREATED="1736040102562" ID="ID_123563958" MODIFIED="1736040333376" STYLE="fork" TEXT="PASS!">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<font NAME="SansSerif" SIZE="16"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1735416494813" ID="ID_329885446" MODIFIED="1735962384703" TEXT="Builder für dedizierte ParamNode">
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1735416494813" ID="ID_329885446" MODIFIED="1736040774387" TEXT="Builder für dedizierte ParamNode">
|
||||
<linktarget COLOR="#482c86" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-553;-36;" ID="Arrow_ID_1024921689" SOURCE="ID_921902157" STARTARROW="None" STARTINCLINATION="598;1114;"/>
|
||||
<linktarget COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" SOURCE="ID_1257939291" STARTARROW="None" STARTINCLINATION="-633;42;"/>
|
||||
<linktarget COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" SOURCE="ID_1257939291" STARTARROW="None" STARTINCLINATION="-647;38;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#bcdcd5" CREATED="1735416968791" HGAP="28" ID="ID_1420751527" MODIFIED="1736015728624" STYLE="bubble" VSHIFT="20">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -98126,6 +98141,11 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<edge COLOR="#3495a4"/>
|
||||
<arrowlink COLOR="#53a3b5" DESTINATION="ID_1559115287" ENDARROW="Default" ENDINCLINATION="-116;8;" ID="Arrow_ID_35370272" STARTARROW="None" STARTINCLINATION="-39;-6;"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1736040011967" HGAP="69" ID="ID_1246573947" MODIFIED="1736040041258" TEXT="der Kern steht bereits...." VSHIFT="13">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node COLOR="#939bba" CREATED="1736040043507" ID="ID_1703541137" MODIFIED="1736040084992" TEXT="durch die ParamBuildSpec"/>
|
||||
<node COLOR="#939bba" CREATED="1736040053953" ID="ID_1306746371" MODIFIED="1736040084998" TEXT="und das darauf aufbauende ParamWeavingPattern"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1735862492660" HGAP="33" ID="ID_1597168085" MODIFIED="1735962375206" TEXT="ParamAgentBuilder aufbauen" VSHIFT="11">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1735862512753" ID="ID_851179462" MODIFIED="1735961868580" TEXT="funktioniert wie der PortBuilder">
|
||||
|
|
@ -98208,8 +98228,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
naja ... einige technische Kleinigkeiten haben noch <i>geklemmt</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#250f69" CREATED="1736015343670" ID="ID_1628252165" MODIFIED="1736015695155" TEXT="Wichtig: die regulären Builder-Operationen müssen eine RValue-Ref zurückgeben">
|
||||
|
|
@ -98220,8 +98239,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
...bisweilen hat man eben doch einen Builder (z.B. wie hier, für Operationen <i>in dem Builder selbst</i>). Dann kann es ggfs gefährlich sein, eine Operation auf dem Builder aufzurufen, wenn danach ein neues Objekt konstruiert wird. Wir <i>müssen</i> ein neues Objekt konstruieren bei jedem Cross-Builder-Schritt, d.h. diese Gefahr läßt sich nicht bannen. Die normalen Operationen jedoch können eine RValue-Referenz zurückgeben (analog zu lib::SeveralBuilder). Denn eine RValue-Referenz ist auch eine generelle Referen, und erlaubt den Aufruf von Member-Funktionen, so daß dann <i>deren</i> Rückgabewert eigentlich bestimmt, was gebaut wird. Das ist kniffelig und kapp am Abgrund, aber nur durch einen solchen RValue-Builder sind Cross-Builder mit Weiterentwicklung der Typ-Parameter im Build-Prozeß möglich
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#853a40" DESTINATION="ID_1628252165" ENDARROW="Default" ENDINCLINATION="199;0;" ID="Arrow_ID_133365781" SOURCE="ID_1840237951" STARTARROW="None" STARTINCLINATION="255;18;"/>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue