From f3dcbfe8b91e5375f97c6b63a43b36126c08c4ff Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 23 Jun 2026 23:18:08 +0200 Subject: [PATCH] pick up work after the LAC-26 Maynooth ...after having settled the problems related to buffer management and the interplay between buffers and output sinks, the ''next goal'' is to drive ahead the integration between job planning and invocation... --- src/steam/fixture/node-graph-attachment.hpp | 6 + tests/steam/engine/node-opera-test.cpp | 10 +- wiki/thinkPad.ichthyo.mm | 125 +++++++++++++++++--- 3 files changed, 123 insertions(+), 18 deletions(-) diff --git a/src/steam/fixture/node-graph-attachment.hpp b/src/steam/fixture/node-graph-attachment.hpp index 78de5ce01..975751481 100644 --- a/src/steam/fixture/node-graph-attachment.hpp +++ b/src/steam/fixture/node-graph-attachment.hpp @@ -50,6 +50,12 @@ namespace fixture { * must remain fixed in memory as long as any derived render jobs are alive. * * @todo WIP-WIP as of 4/2023 -- starting with a fake implementation /////////////////////TICKET #1306 : create an actual link to the low-level Model + * @deprecated 2025 now it looks like this entity was just a step stone towards the actual design; + * during the first prototypical implementation it became clear that the concept of an + * »ExitNode« needs to be repurposed (and shifted by one level in the architecture). + * However -- it is not clear yet in which way to address/designate the actual node + * that shall be pulled from a given render job; there might be some mapping based + * on a _feed ID_ (or a process-ID). */ class NodeGraphAttachment { diff --git a/tests/steam/engine/node-opera-test.cpp b/tests/steam/engine/node-opera-test.cpp index 09272194e..ec1d0c231 100644 --- a/tests/steam/engine/node-opera-test.cpp +++ b/tests/steam/engine/node-opera-test.cpp @@ -32,10 +32,18 @@ namespace test { /***************************************************************//** * @test check render node operation modes and collaboration. + * @todo 6/2026 this test shell demonstrate all relevant operation modes + * of render nodes, at the level of an component-integration-test. + * It is not clear yet what further operation modes this entails, + * beyond (obviously) invoking a render job... ////////////////////////////////////////////////TICKET #1367 : build a node invocation + * @remark the purpose of this test is to accomplish component integration + * regarding relevant usages of the render node network, seen from the + * perspective of an (exit) render node that is used / invoked / pulled. */ class NodeOpera_test : public Test { - virtual void run(Arg) + virtual void + run (Arg) { UNIMPLEMENTED ("operate some render nodes as linked together"); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 649116ea1..09e1fa1ce 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -90933,13 +90933,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ - - + + + + - + @@ -90978,7 +90981,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -91020,11 +91023,29 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

- + - - + + + + +

+ ...insofern es möglich ist, mit geschicktem Setup das Mapping zwischen CalcStream und DataSink implizit zu machen; innerhalb der Invocation wird ohnehin immer nur eine gewisse Ausprägung dieser Information gebraucht; stellenweise ist es die DataSink (in die man Daten ausgibt), an anderer Stelle ist es nur eine Art Prozeß-ID, an die man Mappings binden kann. Je nach Kontext ist diese Information abstrakter (eine Identität), oder eben etwas konkrtetes (ein Output-Kanal) — aber es ist nur ein Freiheitsgrad, nicht mehrere +

+ + + + + + + +

+ insofern dann Platz wäre für eine weitere Ausprägungs-ID — oder man diese verschiedenen Arten von »Ausprägung« allesamt per Mapping aus einer Prozeß-ID gewinnen kann, zum Zeitpunkt der Invocation. +

+ + + @@ -91035,12 +91056,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- +

- ...will sagen, eine »ExitNode« muß nicht eine besondere Art von Node sein, denn der Zwek von Nodes und der/den ExitNodes überschneidet sich überhaupt nicht + ...will sagen, eine »ExitNode« muß nicht eine besondere Art von Node sein, denn der Zweck von Nodes und der/den ExitNodes überschneidet sich überhaupt nicht

@@ -91049,7 +91070,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + + + +

+ ...und könnte tatsächlich sogar als mehrstufige Mapping-Tabelle realisiert sein; die erste Stufe wäre dann sogar pro Timeline (und wäre lediglich eine Zuordnung eines bestimmten Datenstrom-Typs, wie z.B. Sound, Video, zu einem Strom-Key); die zweite Stufe wäre dann das eigentliche Mapping pro Segment, welches einem Strom-Key jeweils eine konkrete ProcNode als Einstiegspunkt zuordnet. +

+ + + @@ -97040,7 +97070,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -98822,6 +98852,25 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + +

+ also ein (für sich selber genommen einfaches) Konzept, das aber mehrere darunterliegende »Säulen« zusammenführt +

+ + + + + + + @@ -116395,7 +116444,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -116619,9 +116668,50 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ inkrementell mit dem Kopf gegen die Wand +

+ + + + + @@ -116675,7 +116765,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -150005,8 +150095,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + @@ -152145,8 +152236,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + @@ -173276,7 +173367,7 @@ std::cout << tmpl.render({"what", "World"}) << s - +