related it to the ConManager and the wiring requests
This commit is contained in:
parent
e541c71995
commit
1724e019ea
4 changed files with 93 additions and 24 deletions
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
ConManager - manages the creation of additional ProcNode connections for the Renderengine
|
||||
ConManager - manages the creation of data/control connections when building the Renderengine
|
||||
|
||||
Copyright (C) Lumiera.org
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
@ -22,15 +22,13 @@
|
|||
|
||||
|
||||
#include "proc/mobject/builder/conmanager.hpp"
|
||||
#include "proc/control/stypemanager.hpp"
|
||||
|
||||
namespace mobject
|
||||
{
|
||||
|
||||
namespace builder
|
||||
{
|
||||
|
||||
|
||||
|
||||
namespace mobject {
|
||||
namespace builder {
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* TODO !!!!!!!!!!!!!!!!!!
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
CONMANAGER.hpp - manages the creation of additional ProcNode connections for the Renderengine
|
||||
CONMANAGER.hpp - manages the creation of data/control connections when building the Renderengine
|
||||
|
||||
Copyright (C) Lumiera.org
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
@ -26,17 +26,20 @@
|
|||
|
||||
|
||||
|
||||
namespace mobject
|
||||
{
|
||||
namespace builder
|
||||
{
|
||||
|
||||
|
||||
namespace mobject {
|
||||
namespace builder {
|
||||
|
||||
|
||||
/**
|
||||
* Connection Manager: used to build the connections between render engine nodes
|
||||
* if these nodes need to cooperate besides the normal "data pull" operation.
|
||||
* Esp. the Connection Manager knows how to wire up the effect's parameters
|
||||
* with the corresponding ParamProviders (autmation) in the Session.
|
||||
* Questions regarding the possibility of a media stream connection are
|
||||
* delegated internally to the STypeManager.
|
||||
* \par
|
||||
* The primary service of the connection manager is to accept a wiring request
|
||||
* and handle the details of establishing the necessary connections.
|
||||
*/
|
||||
class ConManager
|
||||
{
|
||||
|
|
|
|||
54
src/proc/mobject/builder/wiringrequest.hpp
Normal file
54
src/proc/mobject/builder/wiringrequest.hpp
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
/*
|
||||
WIRINGREQUEST.hpp - (interface) the intention to make a data or control connection
|
||||
|
||||
Copyright (C) Lumiera.org
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License as
|
||||
published by the Free Software Foundation; either version 2 of the
|
||||
License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
*/
|
||||
|
||||
|
||||
#ifndef MOBJECT_BUILDER_WIRINGREQUEST_H
|
||||
#define MOBJECT_BUILDER_WIRINGREQUEST_H
|
||||
|
||||
|
||||
|
||||
namespace mobject {
|
||||
namespace builder {
|
||||
|
||||
|
||||
/**
|
||||
* A stateful value object denoting the wish to establish a link or connection
|
||||
* between two entities. Used to organize the proper working of the build process.
|
||||
* Wiring requests are first to be checked and can be deemed impossible to
|
||||
* satisfy. Internally, wiring requests contain specific information about
|
||||
* the objects to be connected. This information is exposed only to the
|
||||
* ConManager, which is the facility actually wiring the connections.
|
||||
*/
|
||||
class WiringRequest
|
||||
{
|
||||
public:
|
||||
/**
|
||||
* TODO design sketch......
|
||||
*/
|
||||
};
|
||||
|
||||
|
||||
|
||||
} // namespace mobject::builder
|
||||
|
||||
} // namespace mobject
|
||||
#endif
|
||||
|
|
@ -928,13 +928,18 @@ TertiaryMid: #99a
|
|||
TertiaryDark: #667
|
||||
Error: #f88</pre>
|
||||
</div>
|
||||
<div title="ConManager" modifier="Ichthyostega" created="200806050208" tags="def Builder" changecount="1">
|
||||
<pre>The Connection Manager is a __Facade__ for querying information and deriving decisions regarding various aspects of data streams and possible connections.
|
||||
* retrieve information about capabilities of a stream type given by ID
|
||||
<div title="ConManager" modifier="Ichthyostega" modified="200810060300" created="200806050208" tags="def Builder" changecount="4">
|
||||
<pre>The Connection Manager is a service for wiring connections and for querying information and deriving decisions regarding various aspects of data streams and the possibility of connections. The purpose of the Connection Manager is to isolate the [[Builder]], which is client of this information and decision services, from the often convoluted details of type information and organizing a connection.
|
||||
|
||||
!control connections
|
||||
my intention was that it would be sufficient for the builder to pass an connection request, and the Connection Manager will handle the details of establishing a control/parameter link.
|
||||
{{red{TODO: handling of parameter values, automation and control connections still need to be designed}}}
|
||||
|
||||
!data connections
|
||||
Connecting data streams of differing type involves a StreamConversion. Mostly, this aspect is covered by the [[stream type system|StreamType]]. The intended implementation will rely partially on [[rules|ConfigRules]] to define automated conversions, while other parts need to be provided by hard wired logic. Thus, regarding data connections, the ConManager can be seen as a specialized Facade and will delegate to the &rarr; [[stream type manager|STypeManager]]
|
||||
* retrieve information about capabilities of a stream type given by ID
|
||||
* decide if a connection is possible
|
||||
* retrieve a //strategy// for implementing a connection
|
||||
|
||||
In the intended implementation, a good deal of this functionality will actually be implemented by [[rules|ConfigRules]], while other parts need to be provided by hard wired logic, at least as a fallback. Anyway, the purpose of the Connection Manager ois to isolate the [[Builder]], which is client of this information and decision services, from these details
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ConfigQuery" modifier="Ichthyostega" modified="200804110335" created="200801181308" tags="def" changecount="5">
|
||||
|
|
@ -3338,10 +3343,10 @@ if (oldText.indexOf("SplashScreen")==-1)
|
|||
* in a future version, it may also encapsulate the communication in a distributed render farm
|
||||
</pre>
|
||||
</div>
|
||||
<div title="StreamConversion" modifier="Ichthyostega" modified="200810020338" created="200810020337" tags="design spec" changecount="2">
|
||||
<pre>Conversion of a media stream into a stream of another type is done by a processor module (plugin). The problem of finding such a module is closely related to the StreamType and especially [[problems of querying|StreamTypeQuery]] for such. There can be different kinds of conversions, and the existance or non-existance of such an conversion can influence the stream type classification.
|
||||
<div title="StreamConversion" modifier="Ichthyostega" modified="200810060308" created="200810020337" tags="design spec" changecount="4">
|
||||
<pre>Conversion of a media stream into a stream of another type is done by a processor module (plugin). The problem of finding such a module is closely related to the StreamType and especially [[problems of querying|StreamTypeQuery]] for such. (The builder uses a special Facade, the ConManager, to access this functionality). There can be different kinds of conversions, and the existance or non-existance of such an conversion can influence the stream type classification.
|
||||
* different //kinds of media// can be ''transformed'' into each other
|
||||
* stream types //subsumed// by a given prototype should be ''lossless convertible''
|
||||
* stream types //subsumed// by a given prototype should be ''lossless convertible'' and thus can be considered //equivalent.//
|
||||
* besides, between different stream //implementation types,// there can be a ''rendering'' (lossy conversion) &mdash; or no conversion at all.
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -4917,6 +4922,15 @@ If ''not processing'' we don't have any input buffers, instead we get our output
|
|||
Otherwise, in the default case of actually ''processing'' out output, we have to organize input buffers, allocate output buffers, call the {{{process()}}} function of the WiringDescriptor and finally release the input buffers.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="WiringRequest" modifier="Ichthyostega" modified="200810060404" created="200810060344" tags="def spec" changecount="2">
|
||||
<pre>{{red{This is an early draft as of 9/08}}}
|
||||
Wiring requests rather belong to the realm of the high-level model, but play an important role in the build process, because the result of "executing" a wiring request will be to establish an actual low-level data connection. Wiring requests will be created automatically in the course of the build process, but they can be created manually and attached to the media objects in the high-level model as a ''wiring plug'', which is a special kind of LocatingPin (&rarr; [[Placement]])
|
||||
|
||||
Wiring requests are small stateful value objects. They will be collected, sorted and processed ordered, such as to finish the building and get a completely wired network of processing nodes. Obviously, there needs to be some reference or smart pointer to the objects to be wired, but this information remains opaque.
|
||||
|
||||
&rarr; ConManager
|
||||
</pre>
|
||||
</div>
|
||||
<div title="automation" modifier="Ichthyostega" modified="200805300125" created="200805300057" tags="overview" changecount="8">
|
||||
<pre>The purpose of automation is to vary a parameter of some data processing instance in the course of time while rendering. Thus, automation encompasses all the variability within the render network //which is not a structural change.//
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue