Wunsch des Users (2026-10-03): ein Shader, den man der Kamera hinzufügen kann.
Befund
Ein Shader wirkt heute nur am eigenen Träger: Sprite, Text, Partikelquelle (je Partikel oder seit #170 über das ganze Feld). Einen Effekt über das ganze Spielbild gibt es nicht, z. B. Vignette, Farbstimmung, Graustufen, Scanlines, Bildschirm-Wackeln, ein roter Rand bei Treffer oder ein Ausblenden.
Die Kamera ist ein eigener Asset-Typ mit den Zeilen View width, View height und Zoom. Gezeichnet wird durch die erste eingeschaltete Kamera in Hierarchie-Reihenfolge (World.activeCamera).
Den Zeichenweg gibt es seit #170 schon: in eine RenderTexture zeichnen, dann ein Mesh mit dem Shader darüber (viewport/fieldFrame.ts, ParticleField). Die Bild-Nodes (Texture color, Sample texture, Texture size, seit #300 auch Blur) lesen dort das gezeichnete Bild.
Zu bauen
Zeile Shader an der Kamera, ein ganz normales Shader-Asset. Seine Property- und Color property-Nodes werden zu Zeilen an der Kamera. So lassen sie sich per Animation und Properties setzen (Treffer-Blitz, Ausblenden).
Die Welt wird so, wie die Kamera sie sieht, in ein Bild gezeichnet, und der Shader liegt darüber. Die UV laufen 0 bis 1 über das Kamerabild, Texture size ist dessen Größe in Pixeln.
Zeile Shader resolution an der Kamera (Antwort 1), nur sichtbar, solange ein Shader gewählt ist:
Screen pixels (Standard): so viele Pixel, wie das Kamerabild gerade auf dem Bildschirm einnimmt, wie bei #170. Scharf bei jeder Game-Scale.
Camera pixels: das Raster der Kamera (View width x View height), danach auf die Game-Scale hochskaliert. Für Pixel-Art-Spiele: Scanlines und Blur je Spielpixel.
Gilt im Game-Tab (Play und die Vorschau ohne Play) und auf der Spiel-Link-Seite (play.html). Jede Kamera trägt ihren eigenen Shader, ein Kamerawechsel wechselt also auch den Effekt.
Scene View (Antwort 2): ein Schalter Camera shader im Auge-Menü links oben, Standard aus. Ist er an, liegt der Shader der aktiven Kamera über deren Rahmen in der Scene View.
HUD und Screens (Antwort 3) laufen mit durch den Shader, weil sie Container in der Welt sind. Sie auszunehmen ist #302 (Render-Layers und Overlay-Kameras).
Ein Shader je Kamera (Antwort 4). Mehrere Durchgänge sind #301, wiederverwendbare Teile eines Shaders #303.
Vertex output und Padding wirken dort nicht, wie beim Feld-Shader.
Messung wie in #67 und #170: Bilder je Sekunde mit und ohne Kamera-Shader, bei Fit im großen Game-Tab, je Auflösung.
Beweis beim Schließen
Ein Kamera-Shader, der nur durchreicht, zeichnet das Spielbild byte-gleich und richtig herum.
Ein flaches Rot füllt das ganze Spielbild.
Eine Kamera ohne Shader zeichnet wie vorher.
Bei Camera pixels ist Texture size gleich View width x View height, bei Screen pixels gleich der Fläche auf dem Bildschirm.
In der Scene View zeichnet der Shader nur, solange der Schalter im Auge-Menü an ist.
Entschieden (Kommentar vom 2026-10-03)
Auflösung wählbar, Standard Bildschirmpixel.
Scene View: über das Auge-Menü ein- und ausschaltbar, Standard aus.
HUD und Screens laufen vorerst mit. Folge-Issue #302 für Render-Layers.
Ein Shader je Kamera. Folge-Issue #303 für eigene Shader-Funktionen als Asset.
Wunsch des Users (2026-10-03): ein Shader, den man der Kamera hinzufügen kann.
## Befund
- Ein Shader wirkt heute nur am eigenen Träger: Sprite, Text, Partikelquelle (je Partikel oder seit #170 über das ganze Feld). Einen Effekt über das ganze Spielbild gibt es nicht, z. B. Vignette, Farbstimmung, Graustufen, Scanlines, Bildschirm-Wackeln, ein roter Rand bei Treffer oder ein Ausblenden.
- Die Kamera ist ein eigener Asset-Typ mit den Zeilen *View width*, *View height* und *Zoom*. Gezeichnet wird durch die erste eingeschaltete Kamera in Hierarchie-Reihenfolge (`World.activeCamera`).
- Den Zeichenweg gibt es seit #170 schon: in eine `RenderTexture` zeichnen, dann ein Mesh mit dem Shader darüber (`viewport/fieldFrame.ts`, `ParticleField`). Die Bild-Nodes (`Texture color`, `Sample texture`, `Texture size`, seit #300 auch `Blur`) lesen dort das gezeichnete Bild.
## Zu bauen
- Zeile **`Shader`** an der Kamera, ein ganz normales Shader-Asset. Seine `Property`- und `Color property`-Nodes werden zu Zeilen an der Kamera. So lassen sie sich per Animation und `Properties` setzen (Treffer-Blitz, Ausblenden).
- Die Welt wird so, wie die Kamera sie sieht, in ein Bild gezeichnet, und der Shader liegt darüber. Die UV laufen 0 bis 1 über das Kamerabild, `Texture size` ist dessen Größe in Pixeln.
- **Zeile `Shader resolution`** an der Kamera (Antwort 1), nur sichtbar, solange ein Shader gewählt ist:
- **Screen pixels** (Standard): so viele Pixel, wie das Kamerabild gerade auf dem Bildschirm einnimmt, wie bei #170. Scharf bei jeder Game-Scale.
- **Camera pixels**: das Raster der Kamera (*View width* x *View height*), danach auf die Game-Scale hochskaliert. Für Pixel-Art-Spiele: Scanlines und Blur je Spielpixel.
- Gilt im Game-Tab (Play und die Vorschau ohne Play) und auf der Spiel-Link-Seite (`play.html`). Jede Kamera trägt ihren eigenen Shader, ein Kamerawechsel wechselt also auch den Effekt.
- **Scene View** (Antwort 2): ein Schalter *Camera shader* im Auge-Menü links oben, Standard aus. Ist er an, liegt der Shader der aktiven Kamera über deren Rahmen in der Scene View.
- **HUD und Screens** (Antwort 3) laufen mit durch den Shader, weil sie Container in der Welt sind. Sie auszunehmen ist #302 (Render-Layers und Overlay-Kameras).
- **Ein Shader je Kamera** (Antwort 4). Mehrere Durchgänge sind #301, wiederverwendbare Teile eines Shaders #303.
- `Vertex output` und `Padding` wirken dort nicht, wie beim Feld-Shader.
- Messung wie in #67 und #170: Bilder je Sekunde mit und ohne Kamera-Shader, bei Fit im großen Game-Tab, je Auflösung.
## Beweis beim Schließen
- Ein Kamera-Shader, der nur durchreicht, zeichnet das Spielbild byte-gleich und richtig herum.
- Ein flaches Rot füllt das ganze Spielbild.
- Eine Kamera ohne Shader zeichnet wie vorher.
- Bei *Camera pixels* ist `Texture size` gleich *View width* x *View height*, bei *Screen pixels* gleich der Fläche auf dem Bildschirm.
- In der Scene View zeichnet der Shader nur, solange der Schalter im Auge-Menü an ist.
## Entschieden (Kommentar vom 2026-10-03)
1. Auflösung wählbar, Standard Bildschirmpixel.
2. Scene View: über das Auge-Menü ein- und ausschaltbar, Standard aus.
3. HUD und Screens laufen vorerst mit. Folge-Issue #302 für Render-Layers.
4. Ein Shader je Kamera. Folge-Issue #303 für eigene Shader-Funktionen als Asset.
meleki
added the shader label 2026-10-03 12:30:53 +02:00
ich würde sagen dass man es auswählen kann: bildschirmpixel vs. kameraraster (default bildschirmpixel)
vorschlag passt fast - scene view links oben im "auge" menü aktivier-/deaktivierbar (default aus)
vorschlag passt, folge issue für render layers. bei kamera kann man dann auswählen welche layers diese "sieht", braucht dann wahrscheinlich mehrere kameras um z.b. das ui in einer eigenen kamera zu rendern
vorschlag passt, ein shader pro kamera. später überlegen wir uns ob wir vielleicht eigene shader funktionen als asset anlegen könnten (auch wieder graph), die man dann in shader als node wieder verwenden kann. bitte hier auch ein issue anlegen
1. ich würde sagen dass man es auswählen kann: bildschirmpixel vs. kameraraster (default bildschirmpixel)
2. vorschlag passt fast - scene view links oben im "auge" menü aktivier-/deaktivierbar (default aus)
3. vorschlag passt, folge issue für render layers. bei kamera kann man dann auswählen welche layers diese "sieht", braucht dann wahrscheinlich mehrere kameras um z.b. das ui in einer eigenen kamera zu rendern
4. vorschlag passt, ein shader pro kamera. später überlegen wir uns ob wir vielleicht eigene shader funktionen als asset anlegen könnten (auch wieder graph), die man dann in shader als node wieder verwenden kann. bitte hier auch ein issue anlegen
Issue-Text an die Antworten oben angepasst. Die alten Fragen stehen jetzt als Entschieden am Ende.
Folge-Issues
#302 Kamera: Render-Layers (was eine Kamera sieht) und Overlay-Kameras
#303 Shader: eigene Funktionen als Asset (ein Graph als Node in anderen Shadern)
Was ich beim Einarbeiten selbst festgelegt habe (änderbar, bis gebaut wird)
Die Auflösung ist eine Zeile Shader resolution (Screen pixels / Camera pixels) an der Kamera. Sie erscheint nur, solange ein Shader gewählt ist, wie Field width bei #170.
Camera pixels wird ohne Glättung (Nearest) auf die Game-Scale hochskaliert, damit Pixel-Art-Kanten hart bleiben.
Der Schalter im Auge-Menü wird mit dem Projekt gespeichert, wie die übrigen Schalter dort.
In der Scene View liegt der Shader nur über dem Rahmen der aktiven Kamera, nicht über der ganzen Arbeitsfläche. Auswahl, Gizmos und Rahmenlinien liegen darüber und laufen nicht durch den Shader.
Gemessen wird bei beiden Auflösungen.
Geprüft am Code (Stand df61b08):World.activeCamera, die drei Kamera-Zeilen, der Zeichenweg aus #170 und das Auge-Menü (SceneVisibilityPopup) sind so, wie im Befund beschrieben.
Issue-Text an die Antworten oben angepasst. Die alten Fragen stehen jetzt als *Entschieden* am Ende.
**Folge-Issues**
- #302 Kamera: Render-Layers (was eine Kamera sieht) und Overlay-Kameras
- #303 Shader: eigene Funktionen als Asset (ein Graph als Node in anderen Shadern)
**Was ich beim Einarbeiten selbst festgelegt habe** (änderbar, bis gebaut wird)
- Die Auflösung ist eine Zeile `Shader resolution` (*Screen pixels* / *Camera pixels*) an der Kamera. Sie erscheint nur, solange ein Shader gewählt ist, wie *Field width* bei #170.
- *Camera pixels* wird ohne Glättung (Nearest) auf die Game-Scale hochskaliert, damit Pixel-Art-Kanten hart bleiben.
- Der Schalter im Auge-Menü wird mit dem Projekt gespeichert, wie die übrigen Schalter dort.
- In der Scene View liegt der Shader nur über dem Rahmen der aktiven Kamera, nicht über der ganzen Arbeitsfläche. Auswahl, Gizmos und Rahmenlinien liegen darüber und laufen nicht durch den Shader.
- Gemessen wird bei beiden Auflösungen.
**Geprüft am Code (Stand `df61b08`):** `World.activeCamera`, die drei Kamera-Zeilen, der Zeichenweg aus #170 und das Auge-Menü (`SceneVisibilityPopup`) sind so, wie im Befund beschrieben.
Nachtrag aus #302 (Render-Layers und Overlay-Kameras sind gebaut, b232608):
Jede Kamera zeichnet ihr eigenes Bild. Die Hauptkamera liegt unten, eingeschaltete Overlay-Kameras liegen darüber. z sortiert nur innerhalb einer Kamera. Der Kamera-Shader aus diesem Issue wirkt deshalb je Kamera auf ihr eigenes Bild, bevor die Bilder übereinanderkommen.
Zusätzlicher Beweis beim Schließen (aus #302 hierher verschoben, weil es den Kamera-Shader erst hier gibt): Eine Spielkamera mit flachem Rot als Shader färbt die Welt rot, das UI aus einer Overlay-Kamera behält seine Farbe.
e2e 63 stellt die Szene schon auf (Hauptkamera sieht Default, Overlay sieht UI). Der Shader-Beweis kann dort angehängt werden.
Nachtrag aus #302 (Render-Layers und Overlay-Kameras sind gebaut, b232608):
- **Jede Kamera zeichnet ihr eigenes Bild.** Die Hauptkamera liegt unten, eingeschaltete Overlay-Kameras liegen darüber. z sortiert nur innerhalb einer Kamera. Der Kamera-Shader aus diesem Issue wirkt deshalb je Kamera auf ihr eigenes Bild, bevor die Bilder übereinanderkommen.
- **Zusätzlicher Beweis beim Schließen** (aus #302 hierher verschoben, weil es den Kamera-Shader erst hier gibt): Eine Spielkamera mit flachem Rot als Shader färbt die Welt rot, das UI aus einer Overlay-Kamera behält seine Farbe.
- e2e 63 stellt die Szene schon auf (Hauptkamera sieht `Default`, Overlay sieht `UI`). Der Shader-Beweis kann dort angehängt werden.
An der Kamera stehen die Zeilen Shader und, solange ein Shader gewählt ist, Shader resolution (Screen pixels / Camera pixels). Die Property- und Color property-Nodes des Shaders werden zu Zeilen an der Kamera. Sie lassen sich überschreiben, animieren und im Properties-Node unter Type: Camera setzen. Namen, die die Kamera schon hat (zoom, sees …), bleiben ihre.
Die Welt wird so, wie die Kamera sie sieht, in ein Bild ihres Rahmens gezeichnet, mit dem Szenenhintergrund darunter. Der Shader liegt darüber, u/v laufen 0 bis 1 über das Kamerabild.
Das gilt im Game-Tab (Play und Vorschau) und auf play.html. Jede Kamera trägt ihren eigenen Shader, Overlay-Kameras (#302) auch. Ein roter Blitz an der Spielkamera lässt das HUD einer Overlay-Kamera also in Ruhe.
Scene View: Im Auge-Menü hat die Zeile Camera eine neue Spalte Shader, Standard aus. Ist sie an, liegt der Shader der Hauptkamera über deren Rahmen. Symbole, Namen und Gizmos liegen darüber, die Welt außerhalb des Rahmens bleibt sichtbar.
Padding und Vertex output wirken dort nicht, wie beim Feld-Shader.
Abweichung vom Issue-Text (deine Entscheidung vom 2026-10-03)
Ein Pixel zählt in beiden Auflösungen als Kamerapixel. Texture size ist also immer View width x View height, und ein Blur 4 reicht bei jeder Game-Scale 4 Kamerapixel weit. Im Issue stand beim Beweis noch „bei Screen pixels gleich der Fläche auf dem Bildschirm“. Screen pixels unterscheidet sich jetzt nur darin, dass das Bild scharf statt blockig ist.
Was ich selbst festgelegt habe
Das Bild hat höchstens 4096 Pixel je Seite (beim Feld-Shader sind es 2048), damit ein großer Game-Tab nicht unscharf wird.
Camera pixels wird ohne Glättung (Nearest) hochskaliert, wie im Kommentar 3030 angekündigt.
In der Scene View enthält das Kamerabild alle Render-Layers, weil die Scene View alle zeigt. Der Filter nach Sees gilt nur im Game-Tab.
Messung (stein2, HD 630, 1920x1080, Game-Tab bei Fit 1310x679, fps)
Sprites
100
400
ohne Kamera-Shader (3 Läufe)
35,5 - 41,0
29,2 - 33,3
durchreichen, Screen pixels (3 Läufe)
35,0 - 41,5
31,1 - 34,1
durchreichen, Camera pixels (3 Läufe)
33,9 - 35,9
30,0 - 31,7
Blur 4, Screen pixels (1 Lauf, ohne 41,7 / 37,9)
33,5
33,3
Blur 4, Camera pixels (1 Lauf)
33,9
33,6
In dieser Fenstergröße hält der Editor schon ohne Shader deutlich unter 60 fps, und dieselbe Szene schwankt zwischen zwei Läufen um bis zu 5 fps. Deshalb habe ich das Durchreichen dreimal gemessen.
Ein Kamera-Shader, der nur durchreicht, kostet weniger, als die Szene von selbst schwankt.
Ein Blur 4 über das ganze Bild hat im einen Lauf 4 bis 8 fps gekostet, bei beiden Auflösungen ähnlich.
Ein Kamera-Shader, der nur durchreicht, zeichnet das Spielbild bei 100 % byte-gleich (0 abweichende Pixel in zwei Zeilen) und richtig herum: Ein blaues Quadrat 100 Einheiten über der Mitte bleibt oben.
Ein flaches Rot füllt das Spielbild bis in die vier Ecken. Das grüne UI-Quadrat der Overlay-Kamera behält seine Farbe (der Beweis aus #302).
Texture size ergibt bei Screen pixels und Camera pixels je 640 x 360 (Farbe #a35c00), bei einem auf 670 x 377 gestreckten Game-Tab. Nur Camera pixels zeichnet das Bild mit 640 x 360 Pixeln, Screen pixels mit 670 x 377.
Eine Kamera ohne Shader zeichnet wie vorher, byte-gleich.
In der Scene View ist der Rahmen nur rot, solange der Schalter im Auge-Menü an ist (echter Klick), und außerhalb des Rahmens nie.
Gegenproben greifen: Kamera beim Laden nicht als Shader-Träger → 1 Unit-Test fällt. Zählt der Shader Bildschirmpixel, fällt 63g mit #ab6000.
Nicht im Browser geprüft
play.html, ein Shader an einer Overlay-Kamera, ein Time-Shader an der Kamera
die Kamera-Zeilen im Inspector, Animation und Properties-Node der Kamera-Parameter (nur Unit-Tests)
Wiki: Shaders (Abschnitt unter Wearing a shader, Messtabelle, In the code), Scene editing (Auge-Menü), Concepts (Verweis bei den Overlay-Kameras), Development (Summe 1725).
Gebaut mit 2e55071 (Wiki 986aad5).
**Was neu ist**
- An der Kamera stehen die Zeilen `Shader` und, solange ein Shader gewählt ist, `Shader resolution` (*Screen pixels* / *Camera pixels*). Die `Property`- und `Color property`-Nodes des Shaders werden zu Zeilen an der Kamera. Sie lassen sich überschreiben, animieren und im `Properties`-Node unter *Type: Camera* setzen. Namen, die die Kamera schon hat (`zoom`, `sees` …), bleiben ihre.
- Die Welt wird so, wie die Kamera sie sieht, in ein Bild ihres Rahmens gezeichnet, mit dem Szenenhintergrund darunter. Der Shader liegt darüber, `u`/`v` laufen 0 bis 1 über das Kamerabild.
- Das gilt im Game-Tab (Play und Vorschau) und auf `play.html`. Jede Kamera trägt ihren eigenen Shader, Overlay-Kameras (#302) auch. Ein roter Blitz an der Spielkamera lässt das HUD einer Overlay-Kamera also in Ruhe.
- **Scene View:** Im Auge-Menü hat die Zeile *Camera* eine neue Spalte *Shader*, Standard aus. Ist sie an, liegt der Shader der Hauptkamera über deren Rahmen. Symbole, Namen und Gizmos liegen darüber, die Welt außerhalb des Rahmens bleibt sichtbar.
- `Padding` und `Vertex output` wirken dort nicht, wie beim Feld-Shader.
**Abweichung vom Issue-Text (deine Entscheidung vom 2026-10-03)**
- Ein Pixel zählt in beiden Auflösungen als **Kamerapixel**. `Texture size` ist also immer *View width* x *View height*, und ein `Blur` 4 reicht bei jeder Game-Scale 4 Kamerapixel weit. Im Issue stand beim Beweis noch „bei *Screen pixels* gleich der Fläche auf dem Bildschirm“. *Screen pixels* unterscheidet sich jetzt nur darin, dass das Bild scharf statt blockig ist.
**Was ich selbst festgelegt habe**
- Das Bild hat höchstens 4096 Pixel je Seite (beim Feld-Shader sind es 2048), damit ein großer Game-Tab nicht unscharf wird.
- *Camera pixels* wird ohne Glättung (Nearest) hochskaliert, wie im Kommentar 3030 angekündigt.
- In der Scene View enthält das Kamerabild alle Render-Layers, weil die Scene View alle zeigt. Der Filter nach *Sees* gilt nur im Game-Tab.
**Messung** (stein2, HD 630, 1920x1080, Game-Tab bei Fit 1310x679, fps)
| Sprites | 100 | 400 |
| --- | --- | --- |
| ohne Kamera-Shader (3 Läufe) | 35,5 - 41,0 | 29,2 - 33,3 |
| durchreichen, Screen pixels (3 Läufe) | 35,0 - 41,5 | 31,1 - 34,1 |
| durchreichen, Camera pixels (3 Läufe) | 33,9 - 35,9 | 30,0 - 31,7 |
| Blur 4, Screen pixels (1 Lauf, ohne 41,7 / 37,9) | 33,5 | 33,3 |
| Blur 4, Camera pixels (1 Lauf) | 33,9 | 33,6 |
- In dieser Fenstergröße hält der Editor schon ohne Shader deutlich unter 60 fps, und dieselbe Szene schwankt zwischen zwei Läufen um bis zu 5 fps. Deshalb habe ich das Durchreichen dreimal gemessen.
- Ein Kamera-Shader, der nur durchreicht, kostet weniger, als die Szene von selbst schwankt.
- Ein `Blur` 4 über das ganze Bild hat im einen Lauf 4 bis 8 fps gekostet, bei beiden Auflösungen ähnlich.
- Werkzeug: `tools/perf-camera-shader.mjs` (`GM_PERF_BLUR`, `GM_PERF_COUNTS`).
**Beweise (e2e 63e bis 63i)**
- Ein Kamera-Shader, der nur durchreicht, zeichnet das Spielbild bei 100 % byte-gleich (0 abweichende Pixel in zwei Zeilen) und richtig herum: Ein blaues Quadrat 100 Einheiten über der Mitte bleibt oben.
- Ein flaches Rot füllt das Spielbild bis in die vier Ecken. Das grüne UI-Quadrat der Overlay-Kamera behält seine Farbe (der Beweis aus #302).
- `Texture size` ergibt bei *Screen pixels* und *Camera pixels* je 640 x 360 (Farbe `#a35c00`), bei einem auf 670 x 377 gestreckten Game-Tab. Nur *Camera pixels* zeichnet das Bild mit 640 x 360 Pixeln, *Screen pixels* mit 670 x 377.
- Eine Kamera ohne Shader zeichnet wie vorher, byte-gleich.
- In der Scene View ist der Rahmen nur rot, solange der Schalter im Auge-Menü an ist (echter Klick), und außerhalb des Rahmens nie.
- Gegenproben greifen: Kamera beim Laden nicht als Shader-Träger → 1 Unit-Test fällt. Zählt der Shader Bildschirmpixel, fällt 63g mit `#ab6000`.
**Nicht im Browser geprüft**
- `play.html`, ein Shader an einer Overlay-Kamera, ein Time-Shader an der Kamera
- die Kamera-Zeilen im Inspector, Animation und `Properties`-Node der Kamera-Parameter (nur Unit-Tests)
Wiki: *Shaders* (Abschnitt unter *Wearing a shader*, Messtabelle, *In the code*), *Scene editing* (Auge-Menü), *Concepts* (Verweis bei den Overlay-Kameras), *Development* (Summe 1725).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Wunsch des Users (2026-10-03): ein Shader, den man der Kamera hinzufügen kann.
Befund
World.activeCamera).RenderTexturezeichnen, dann ein Mesh mit dem Shader darüber (viewport/fieldFrame.ts,ParticleField). Die Bild-Nodes (Texture color,Sample texture,Texture size, seit #300 auchBlur) lesen dort das gezeichnete Bild.Zu bauen
Shaderan der Kamera, ein ganz normales Shader-Asset. SeineProperty- undColor property-Nodes werden zu Zeilen an der Kamera. So lassen sie sich per Animation undPropertiessetzen (Treffer-Blitz, Ausblenden).Texture sizeist dessen Größe in Pixeln.Shader resolutionan der Kamera (Antwort 1), nur sichtbar, solange ein Shader gewählt ist:play.html). Jede Kamera trägt ihren eigenen Shader, ein Kamerawechsel wechselt also auch den Effekt.Vertex outputundPaddingwirken dort nicht, wie beim Feld-Shader.Beweis beim Schließen
Texture sizegleich View width x View height, bei Screen pixels gleich der Fläche auf dem Bildschirm.Entschieden (Kommentar vom 2026-10-03)
Issue-Text an die Antworten oben angepasst. Die alten Fragen stehen jetzt als Entschieden am Ende.
Folge-Issues
Was ich beim Einarbeiten selbst festgelegt habe (änderbar, bis gebaut wird)
Shader resolution(Screen pixels / Camera pixels) an der Kamera. Sie erscheint nur, solange ein Shader gewählt ist, wie Field width bei #170.Geprüft am Code (Stand
df61b08):World.activeCamera, die drei Kamera-Zeilen, der Zeichenweg aus #170 und das Auge-Menü (SceneVisibilityPopup) sind so, wie im Befund beschrieben.Nachtrag aus #302 (Render-Layers und Overlay-Kameras sind gebaut,
b232608):Default, Overlay siehtUI). Der Shader-Beweis kann dort angehängt werden.Gebaut mit
2e55071(Wiki 986aad5).Was neu ist
Shaderund, solange ein Shader gewählt ist,Shader resolution(Screen pixels / Camera pixels). DieProperty- undColor property-Nodes des Shaders werden zu Zeilen an der Kamera. Sie lassen sich überschreiben, animieren und imProperties-Node unter Type: Camera setzen. Namen, die die Kamera schon hat (zoom,sees…), bleiben ihre.u/vlaufen 0 bis 1 über das Kamerabild.play.html. Jede Kamera trägt ihren eigenen Shader, Overlay-Kameras (#302) auch. Ein roter Blitz an der Spielkamera lässt das HUD einer Overlay-Kamera also in Ruhe.PaddingundVertex outputwirken dort nicht, wie beim Feld-Shader.Abweichung vom Issue-Text (deine Entscheidung vom 2026-10-03)
Texture sizeist also immer View width x View height, und einBlur4 reicht bei jeder Game-Scale 4 Kamerapixel weit. Im Issue stand beim Beweis noch „bei Screen pixels gleich der Fläche auf dem Bildschirm“. Screen pixels unterscheidet sich jetzt nur darin, dass das Bild scharf statt blockig ist.Was ich selbst festgelegt habe
Messung (stein2, HD 630, 1920x1080, Game-Tab bei Fit 1310x679, fps)
Blur4 über das ganze Bild hat im einen Lauf 4 bis 8 fps gekostet, bei beiden Auflösungen ähnlich.tools/perf-camera-shader.mjs(GM_PERF_BLUR,GM_PERF_COUNTS).Beweise (e2e 63e bis 63i)
Texture sizeergibt bei Screen pixels und Camera pixels je 640 x 360 (Farbe#a35c00), bei einem auf 670 x 377 gestreckten Game-Tab. Nur Camera pixels zeichnet das Bild mit 640 x 360 Pixeln, Screen pixels mit 670 x 377.#ab6000.Nicht im Browser geprüft
play.html, ein Shader an einer Overlay-Kamera, ein Time-Shader an der KameraProperties-Node der Kamera-Parameter (nur Unit-Tests)Wiki: Shaders (Abschnitt unter Wearing a shader, Messtabelle, In the code), Scene editing (Auge-Menü), Concepts (Verweis bei den Overlay-Kameras), Development (Summe 1725).