benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/src/steam/engine/render-invocation.cpp

79 lines
3 KiB
C++
Raw Normal View History

WIP: ...to do so, some considerations regarding the entrance point..
2009-08-31 12:16:47 +02:00
/*
RenderInvocation - Interface for creating processing nodes of various kinds
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2008, Hermann Vosseler <Ichthyostega@web.de>
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** 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. See the file COPYING for further details.
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
WIP: ...to do so, some considerations regarding the entrance point..
2009-08-31 12:16:47 +02:00
Doxygen: insert actual filename into those automatically added file comments HOWTO for F in $(find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -exec egrep -q '§§§' {} \; -print); do D=$(basename $F); sed -r -e"s/§§§/$D/" $F ; done
2016-11-03 18:22:31 +01:00
/** @file render-invocation.cpp
Doxygen: fill in missing file level headlines for Proc-Layer (Engine II)
2016-11-09 19:50:16 +01:00
** Implementation details regarding the invocation of a single render node
** @deprecated very likely to happen in a different way, while the concept remains valid
Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network.
2024-12-05 23:58:22 +01:00
** @todo WIP-WIP-WIP 12/2024 about to build a Render Node invocation, combining the old
** unfinished draft from 2009 with the new Render Engine code
Doxygen: identify all files lacking a @file comment reason is, only files with a @file comment will be processed with further documentation commands. For this reason, our Doxygen documentation is lacking a lot of entries. HOWTO: find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -not -exec egrep -q '\*.+@file' {} \; -print -exec sed -i -r -e'\_\*/_,$ { 1,+0 a\ \ \ /** @file §§§\ ** TODO §§§\ */ }' {} \;
2016-11-03 18:20:10 +01:00
*/
Invocation: capture idea for sharpened invocation structure - the starting point is the idea to build a dedicated ''turnout system'' - `StateAdapter`, `BuffTable` ⟶ `FeedManifold` and _Invocation_ will be fused - actually, the `TurnoutSystem` will be ''pulled'' and orchestrate the invocation - the structure is assumed to be recursive The essence of the Node-Invocation, as developed 2009 / 2011 remains intact, yet it will be organised along a clearer structure
2024-05-12 17:27:07 +02:00
#include "steam/engine/turnout-system.hpp"
Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network.
2024-12-05 23:58:22 +01:00
#include "steam/engine/render-invocation.hpp"
using vault::gear::JobParameter;
WIP some further musing about how to do a simple invocation for unit testing ProcNode
2009-09-04 01:59:44 +02:00
WIP: ...to do so, some considerations regarding the entrance point..
2009-08-31 12:16:47 +02:00
Global-Layer-Renaming: rename namespaces
2018-11-15 23:55:13 +01:00
namespace steam {
WIP: ...to do so, some considerations regarding the entrance point..
2009-08-31 12:16:47 +02:00
namespace engine {
namespace { // Details...
} // (END) Details...
// using mobject::Placement;
// using mobject::session::Effect;
Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network.
2024-12-05 23:58:22 +01:00
string
RenderInvocation::diagnostic() const
{
return "TODO ... what can the ExitNode tell us here?"; ///////////////////////////////////////////////TICKET #1367 : once we have a working draft of a node invocation, it should be possible to retrieve some Node-Spec here...
}
InvocationInstanceID
RenderInvocation::buildInstanceID (HashVal) const
{
return InvocationInstanceID(); //////////////////////////////////////////////////////TICKET #1278 : so what do we need here for real, finally?
}
size_t
RenderInvocation::hashOfInstance (InvocationInstanceID invoKey) const
{ ////////////////////////////////////////////////TICKET #1295 : settle upon the parameters actually needed and decide what goes into this hash
std::hash<size_t> hashr;
HashVal res = hashr (invoKey.frameNumber);
return res;
}
WIP some further musing about how to do a simple invocation for unit testing ProcNode
2009-09-04 01:59:44 +02:00
/** @note this builds a one-way off invocation state context
* and then forwards the call; this may or may not cause
* actual calculations, depending on the cache.
*/
Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network.
2024-12-05 23:58:22 +01:00
void
RenderInvocation::invokeJobOperation (JobParameter invoParam)
{ ////////////////////////////////////////////////TICKET #905 : yess.... finally DO IT
UNIMPLEMENTED ("how to »doIt«");
WIP some further musing about how to do a simple invocation for unit testing ProcNode
2009-09-04 01:59:44 +02:00
Invocation: establish a concept for the rework As outlined in #1367, the integration effort requires some rework of existing code, which will be driven ahead by the `NodeLinkage_test` * redefine Node Connectivity * build simple `ProcNode` directly in scope * create an `TurnoutSystem` instance * perform a ''dummy Node-Invocation''
2024-06-21 16:14:24 +02:00
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
WIP some further musing about how to do a simple invocation for unit testing ProcNode
2009-09-04 01:59:44 +02:00
return theNode_->pull(invocationState, channel);
Invocation: establish a concept for the rework As outlined in #1367, the integration effort requires some rework of existing code, which will be driven ahead by the `NodeLinkage_test` * redefine Node Connectivity * build simple `ProcNode` directly in scope * create an `TurnoutSystem` instance * perform a ''dummy Node-Invocation''
2024-06-21 16:14:24 +02:00
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
WIP: ...to do so, some considerations regarding the entrance point..
2009-08-31 12:16:47 +02:00
}
cleanup: rectify Proc-Layer namespaces (I)
2011-12-02 16:10:03 +01:00
}} // namespace engine
Reference in a new issue Copy permalink