Shader: Rechen-Nodes zeigen den Typ, der wirklich herauskommt #219

Closed
opened 2026-09-23 07:05:36 +02:00 by meleki · 2 comments
Owner

Aus #207 (Befund: „Die naheliegenden nächsten Nutzer wären die Shader-Arithmetik-Nodes (a, b → result, alle any); die sind bewusst nicht angefasst.“).

Befund

  • Die Rechen-Nodes im Shader-Graph haben any-Eingänge und einen any-Ausgang result (src/core/shader/nodes.ts):
    • zweistellig über arithmetic() (Zeile 103): Add, Subtract, Multiply, Divide.
    • einstellig über unary() (Zeile 344): Sin, Floor, Fract, Abs und weitere.
    • dazu Clamp, Mix, Step, Pow mit any an value bzw. a/b.
  • Im Editor sind diese Ports immer grau, auch wenn eine Farbe (vec3) hineingeht.
  • Der Compiler kennt den echten Typ längst:
    • lifted() (Zeile 97): „a colour on either side makes the result a colour“, also vec3 mit number ergibt vec3.
    • unary() gibt den Typ des Eingangs weiter.
  • Seit #207 gibt es dafür im Behavior-Graph sharedType samt gefärbter Pins. Die Regel dort (agreedType) verlangt aber gleiche Typen. Im Shader ist vec3 * number gültig und ergibt vec3, die Regel passt also nicht eins zu eins.

Zu bauen (Vorschlag)

  • Eine zweite Einigungsregel neben agreedType, gleich der von lifted(): Ist ein Eingang vec3, ist der Ausgang vec3. Sind alle number, ist er number. Beide Stellen sollen dieselbe Funktion lesen, damit Anzeige und Compiler nicht auseinanderlaufen.
  • Die Rechen-Nodes bekommen sharedType mit dieser Regel. Der Ausgang zeigt dann Farbe und Typ dessen, was herauskommt. Die Eingänge bleiben any (Variante A aus #207) und werden nach ihrer Kante bemalt.
  • Ein Eingang ohne Kante zählt mit seinem Inline-Wert als number.
  • Tests: Unit für die Regel (vec3 + number → vec3, number + number → number, unverbunden = number, einstellig reicht durch). e2e im Shader-Tab (Modul 28): Texture color in Multiply, der Ausgang ist als Farbe gefärbt und passt nicht mehr an einen reinen Zahleneingang.

Offen (mit Vorschlag)

  1. Kette durch mehrere Rechen-Nodes (Multiply → Add → Output): Das hängt an #210 (Ketten, Folge aus #207, Antwort 2). Vorschlag: hier nur eine Stufe, die Kette kommt mit jenem.
  2. Unterscheidet sich das von #207 zu sehr? Hier ist ein unverbundener Eingang schon eine Zahl, nicht offen. Vorschlag: ja, der Shader-Graph bekommt diese eigene Regel. Im Behavior-Graph bleibt #207, wie es ist.
Aus #207 (Befund: „Die naheliegenden nächsten Nutzer wären die Shader-Arithmetik-Nodes (`a`, `b` → `result`, alle `any`); die sind bewusst nicht angefasst.“). ## Befund - Die Rechen-Nodes im Shader-Graph haben `any`-Eingänge und einen `any`-Ausgang `result` (`src/core/shader/nodes.ts`): - zweistellig über `arithmetic()` (Zeile 103): Add, Subtract, Multiply, Divide. - einstellig über `unary()` (Zeile 344): Sin, Floor, Fract, Abs und weitere. - dazu Clamp, Mix, Step, Pow mit `any` an `value` bzw. `a`/`b`. - Im Editor sind diese Ports immer grau, auch wenn eine Farbe (`vec3`) hineingeht. - Der Compiler kennt den echten Typ längst: - `lifted()` (Zeile 97): „a colour on either side makes the result a colour“, also `vec3` mit `number` ergibt `vec3`. - `unary()` gibt den Typ des Eingangs weiter. - Seit #207 gibt es dafür im Behavior-Graph `sharedType` samt gefärbter Pins. Die Regel dort (`agreedType`) verlangt aber **gleiche** Typen. Im Shader ist `vec3 * number` gültig und ergibt `vec3`, die Regel passt also nicht eins zu eins. ## Zu bauen (Vorschlag) - Eine zweite Einigungsregel neben `agreedType`, gleich der von `lifted()`: Ist ein Eingang `vec3`, ist der Ausgang `vec3`. Sind alle `number`, ist er `number`. Beide Stellen sollen dieselbe Funktion lesen, damit Anzeige und Compiler nicht auseinanderlaufen. - Die Rechen-Nodes bekommen `sharedType` mit dieser Regel. Der Ausgang zeigt dann Farbe und Typ dessen, was herauskommt. Die Eingänge bleiben `any` (Variante A aus #207) und werden nach ihrer Kante bemalt. - Ein Eingang ohne Kante zählt mit seinem Inline-Wert als `number`. - Tests: Unit für die Regel (`vec3 + number → vec3`, `number + number → number`, unverbunden = `number`, einstellig reicht durch). e2e im Shader-Tab (Modul 28): `Texture color` in `Multiply`, der Ausgang ist als Farbe gefärbt und passt nicht mehr an einen reinen Zahleneingang. ## Offen (mit Vorschlag) 1. **Kette durch mehrere Rechen-Nodes** (`Multiply` → `Add` → Output): Das hängt an #210 (Ketten, Folge aus #207, Antwort 2). Vorschlag: hier nur eine Stufe, die Kette kommt mit jenem. 2. **Unterscheidet sich das von #207 zu sehr?** Hier ist ein unverbundener Eingang schon eine Zahl, nicht offen. Vorschlag: ja, der Shader-Graph bekommt diese eigene Regel. Im Behavior-Graph bleibt #207, wie es ist.
meleki added the shadernew labels 2026-09-23 07:05:36 +02:00

vorschläge passen

vorschläge passen
admin added low-priority and removed new labels 2026-09-23 07:14:04 +02:00
admin added this to the Development project 2026-09-23 07:14:43 +02:00
admin moved this to Next in Development on 2026-10-02 10:34:18 +02:00
Author
Owner

Umgesetzt und live (Build auf stein2).

Was sich ändert

  • result zeigt den Typ, der wirklich herauskommt. Das gilt für alle 13 Rechen-Nodes im Shader-Graph: Add, Subtract, Multiply, Divide, Mix, Sin, Floor, Fract, Abs, Sqrt, Step, Pow und Clamp.
    • Gehen nur Zahlen hinein, ist result eine Zahl. Ein Eingang ohne Kante zählt als die getippte Zahl.
    • Sobald eine Farbe an einem der any-Eingänge hängt, ist result eine Farbe. Pin und Kante werden entsprechend eingefärbt.
  • Die Eingänge bleiben any und werden nach ihrer Kante bemalt, wie in #207.
  • Eine Regel für Anzeige und Compiler: Beide lesen liftedType.
  • Ein Farb-Ergebnis passt nicht mehr an einen Zahleneingang (alpha am Output, t am Mix). Bisher ließ sich das verbinden, und der Shader kompilierte dann nicht.
  • Eine schon gelegte Kante bleibt liegen, wenn dahinter eine Farbe dazukommt. Sie wird rot, und der Node an ihrem Ende meldet „"alpha" needs a number, not a color“.

Was ich selbst festgelegt habe

  • Die Kette ist gleich dabei. Vorschlag 1 war „nur eine Stufe, die Kette kommt mit #210“. #210 ist inzwischen gebaut, deshalb wandert der Typ ohne Zusatzcode durch Multiply → Add → Sin.
  • Eine Zahl darf jetzt an einen Farbeingang. Ohne das hätte ein Zahlen-Ergebnis nicht mehr an Output.color gepasst, obwohl der Compiler es auf drei Kanäle spreizt. Nebenwirkung: Number oder Luminance lassen sich jetzt auch direkt an einen Farbeingang hängen. Die Regel sitzt in der allgemeinen Kantenprüfung (portsCompatible), Farb-Ports gibt es aber nur im Shader-Graph.
  • Nur die any-Eingänge bestimmen den Typ. t, edge, exponent, min und max reden nicht mit.
  • In einem Ring bleibt result offen (any), außer eine Farbe hat schon entschieden.

Bestand

Die neun Shader in den vorhandenen Projekten (108 Kanten) bleiben unter der neuen Regel alle gültig, keine Kante wird rot.

Under the hood

  • liftedType in src/core/shader/nodes.ts ist die eine Regel. Der Compiler liest sie beim Anheben zweier Operanden, der Editor über liftedPortType für die Ports, die er zeichnet.
  • Eine SharedPortGroup kann eine eigene Regel als agree mitbringen. Ohne sie gilt agreedType wie bisher.

Tests (auf melektaus-atx)

Gate        → 212 Files, 3260 Tests, CHECK EXIT 0   (3240 + 20)
e2e 28      → ALL PASSED – 81 checks   (+3 für Block 28k-vii)
e2e 1-31    → 1059 PASS, 1 FAILED
e2e 1-18    → ALL PASSED – 602 checks  (Wiederholung)
  • Der rote Check liegt in Modul 18 (Pause). Nach dem Stoppen stand die Editor-Uhr bei 1,97 s statt unter 1 s. In der Wiederholung waren es 0,18 s und alles grün. Ich halte das für einen Zeit-Wackler; 1-31 ist danach nicht noch einmal komplett gelaufen.
  • 20 neue Unit-Tests in tests/core/shader-port-types.test.ts. Einer fährt alle 13 Nodes durch jede Mischung aus Zahl und Farbe und vergleicht Anzeige und erzeugten Code. Zwei bestehende Tests in shaders.test.ts sind umgestellt: Sie legen jetzt erst die Kante und bringen dann die Farbe.
  • Drei neue e2e-Checks mit echter Maus: Farbe in den Multiply ziehen (Typ, Kette, Kantenfarbe), die rote Kante samt Meldung am Output, und das Farb-Ergebnis, das an alpha abgewiesen und an color angenommen wird.
  • Alle 15 Unit-Gegenproben und beide Browser-Gegenproben greifen.
  • Die e2e-Summe 1676 ist gerechnet (1673 + 3). Volle Suite und Smokes liefen für diesen Stand nicht, das macht der CI-Lauf zu diesem Commit.
  • Nicht im Browser geprüft: die einstelligen Nodes, Mix und der Ring (nur Unit-Tests), eine Zahl direkt an einem Farbeingang (nur Unit-Test samt erzeugtem Code). Nach dem Build habe ich nichts mehr angesehen.

Nebenbei, eigener Commit c7dc0e4

Auf Wunsch sind die Knöpfe Hide link und Delete link aus dem Inspector einer gewählten Linie entfernt, beide Aktionen stehen im Rechtsklick-Menü. Mit ihnen gehen der Knopf unter mehreren gewählten Linien und Delete transition in der State Machine, sie kamen aus derselben Codezeile. Dafür liefen das Gate noch einmal (212 Files, 3260 Tests) und e2e 4,6,26 (275 Checks, grün). Eine Gegenprobe dazu habe ich nicht gefahren.

Commits: f02adab (#219) und c7dc0e4 (Knöpfe). Wiki: Shaders (Absatz zum Typ von result, dazu „In the code“), Behaviors (ein Satz zu agree, die Knöpfe sind raus) und Development (Summe).

Umgesetzt und live (Build auf stein2). ## Was sich ändert - **`result` zeigt den Typ, der wirklich herauskommt.** Das gilt für alle 13 Rechen-Nodes im Shader-Graph: Add, Subtract, Multiply, Divide, Mix, Sin, Floor, Fract, Abs, Sqrt, Step, Pow und Clamp. - Gehen nur Zahlen hinein, ist `result` eine Zahl. Ein Eingang ohne Kante zählt als die getippte Zahl. - Sobald eine Farbe an einem der `any`-Eingänge hängt, ist `result` eine Farbe. Pin und Kante werden entsprechend eingefärbt. - **Die Eingänge bleiben `any`** und werden nach ihrer Kante bemalt, wie in #207. - **Eine Regel für Anzeige und Compiler:** Beide lesen `liftedType`. - **Ein Farb-Ergebnis passt nicht mehr an einen Zahleneingang** (`alpha` am Output, `t` am Mix). Bisher ließ sich das verbinden, und der Shader kompilierte dann nicht. - **Eine schon gelegte Kante bleibt liegen**, wenn dahinter eine Farbe dazukommt. Sie wird rot, und der Node an ihrem Ende meldet „"alpha" needs a number, not a color“. ## Was ich selbst festgelegt habe - **Die Kette ist gleich dabei.** Vorschlag 1 war „nur eine Stufe, die Kette kommt mit #210“. #210 ist inzwischen gebaut, deshalb wandert der Typ ohne Zusatzcode durch `Multiply` → `Add` → `Sin`. - **Eine Zahl darf jetzt an einen Farbeingang.** Ohne das hätte ein Zahlen-Ergebnis nicht mehr an `Output.color` gepasst, obwohl der Compiler es auf drei Kanäle spreizt. Nebenwirkung: `Number` oder `Luminance` lassen sich jetzt auch direkt an einen Farbeingang hängen. Die Regel sitzt in der allgemeinen Kantenprüfung (`portsCompatible`), Farb-Ports gibt es aber nur im Shader-Graph. - **Nur die `any`-Eingänge bestimmen den Typ.** `t`, `edge`, `exponent`, `min` und `max` reden nicht mit. - **In einem Ring bleibt `result` offen (`any`)**, außer eine Farbe hat schon entschieden. ## Bestand Die neun Shader in den vorhandenen Projekten (108 Kanten) bleiben unter der neuen Regel alle gültig, keine Kante wird rot. ## Under the hood - `liftedType` in `src/core/shader/nodes.ts` ist die eine Regel. Der Compiler liest sie beim Anheben zweier Operanden, der Editor über `liftedPortType` für die Ports, die er zeichnet. - Eine `SharedPortGroup` kann eine eigene Regel als `agree` mitbringen. Ohne sie gilt `agreedType` wie bisher. ## Tests (auf `melektaus-atx`) ``` Gate → 212 Files, 3260 Tests, CHECK EXIT 0 (3240 + 20) e2e 28 → ALL PASSED – 81 checks (+3 für Block 28k-vii) e2e 1-31 → 1059 PASS, 1 FAILED e2e 1-18 → ALL PASSED – 602 checks (Wiederholung) ``` - **Der rote Check liegt in Modul 18 (Pause).** Nach dem Stoppen stand die Editor-Uhr bei 1,97 s statt unter 1 s. In der Wiederholung waren es 0,18 s und alles grün. Ich halte das für einen Zeit-Wackler; `1-31` ist danach nicht noch einmal komplett gelaufen. - **20 neue Unit-Tests** in `tests/core/shader-port-types.test.ts`. Einer fährt alle 13 Nodes durch jede Mischung aus Zahl und Farbe und vergleicht Anzeige und erzeugten Code. Zwei bestehende Tests in `shaders.test.ts` sind umgestellt: Sie legen jetzt erst die Kante und bringen dann die Farbe. - **Drei neue e2e-Checks** mit echter Maus: Farbe in den Multiply ziehen (Typ, Kette, Kantenfarbe), die rote Kante samt Meldung am Output, und das Farb-Ergebnis, das an `alpha` abgewiesen und an `color` angenommen wird. - **Alle 15 Unit-Gegenproben und beide Browser-Gegenproben greifen.** - Die e2e-Summe **1676** ist gerechnet (1673 + 3). Volle Suite und Smokes liefen für diesen Stand nicht, das macht der CI-Lauf zu diesem Commit. - **Nicht im Browser geprüft:** die einstelligen Nodes, Mix und der Ring (nur Unit-Tests), eine Zahl direkt an einem Farbeingang (nur Unit-Test samt erzeugtem Code). Nach dem Build habe ich nichts mehr angesehen. ## Nebenbei, eigener Commit `c7dc0e4` Auf Wunsch sind die Knöpfe *Hide link* und *Delete link* aus dem Inspector einer gewählten Linie entfernt, beide Aktionen stehen im Rechtsklick-Menü. Mit ihnen gehen der Knopf unter mehreren gewählten Linien und *Delete transition* in der State Machine, sie kamen aus derselben Codezeile. Dafür liefen das Gate noch einmal (212 Files, 3260 Tests) und e2e `4,6,26` (275 Checks, grün). Eine Gegenprobe dazu habe ich nicht gefahren. Commits: `f02adab` (#219) und `c7dc0e4` (Knöpfe). Wiki: *Shaders* (Absatz zum Typ von `result`, dazu „In the code“), *Behaviors* (ein Satz zu `agree`, die Knöpfe sind raus) und *Development* (Summe).
admin moved this to Done in Development on 2026-10-02 16:53:21 +02:00
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meleki/feuerwerk#219