Folge-Issue aus #299 (Antwort 3 im Kommentar vom 2026-10-03): Eine Kamera soll wählen können, welche Layers sie sieht. Damit lässt sich z. B. das UI in einer eigenen Kamera zeichnen, ohne dass der Post-Processing-Shader der Spielkamera darüber läuft.
Befund
Heute zeichnet genau eine Kamera: die erste eingeschaltete in Hierarchie-Reihenfolge (World.activeCamera, #5). Ein Kamerawechsel läuft über Set enabled.
Jede Kamera sieht alles in der Szene. HUD und Screens sind Container in der Welt und laufen deshalb mit durch einen Kamera-Shader (#299).
„Layer“ gibt es bisher nur für die Physik: die Kollisionsebenen aus #152 (Projekteinstellungen, Zeilen Layer und Collides with am Collider). Die haben mit dem Zeichnen nichts zu tun.
Auch der Mauszeiger der Laufzeit (world.pointer) wird über die eine aktive Kamera in die Welt umgerechnet.
Zu bauen (Vorschlag)
Liste Render layers in den Projekteinstellungen, neben Collision layers. Der erste Eintrag heißt Default und lässt sich nicht löschen.
Zeile Render layer an allem, was zeichnet: Sprite, Text, Tilemap, Partikelquelle und Container. Ohne eigene Wahl gilt der Layer des Parents, ganz oben Default. Ein HUD-Container auf UI nimmt so seinen ganzen Inhalt mit.
Zeile Sees an der Kamera: eine Mehrfachauswahl der Render-Layers wie Collides with, Standard alle.
Mehrere Kameras übereinander: Zeile Overlay (Schalter) an der Kamera, Standard aus.
Kameras ohne Overlay folgen weiter der Regel aus #5: Die erste eingeschaltete ist die Hauptkamera. Bestehende Projekte zeichnen dadurch unverändert.
Jede eingeschaltete Overlay-Kamera zeichnet zusätzlich über die Hauptkamera, in Hierarchie-Reihenfolge, mit durchsichtigem Hintergrund.
Jede Kamera trägt ihren eigenen Shader (#299) und wendet ihn nur auf ihr eigenes Bild an. Eine UI-Kamera ohne Shader bleibt also scharf, während die Spielkamera verschwimmt.
Gilt im Game-Tab und auf play.html. Die Scene View zeigt weiter alle Layers.
Die Physik bleibt davon unberührt: Render-Layers und Kollisionsebenen sind zwei getrennte Listen.
Beweis beim Schließen
Ein Sprite auf UI ist in einer Kamera, die nur Default sieht, nicht zu sehen. In einer Overlay-Kamera, die UI sieht, ist es zu sehen.
Eine Spielkamera mit flachem Rot als Shader färbt die Welt rot, das UI aus der Overlay-Kamera behält seine Farbe.
Ein Projekt mit zwei eingeschalteten Kameras ohne Overlay zeichnet wie vorher nur durch die erste.
Offen (mit Vorschlag)
Größe des Overlay-Bildes: Bestimmt die Hauptkamera Bildgröße und Game-Scale, und eine Overlay-Kamera wird auf dieselbe Fläche gelegt? Vorschlag: ja. Eine Overlay-Kamera mit anderem Seitenverhältnis wird eingepasst (Fit), nicht verzerrt.
Mauszeiger: Durch welche Kamera rechnet world.pointer? Vorschlag: weiter durch die Hauptkamera. Ein eigener Node „Pointer in camera“ kommt, sobald ein UI auf Klicks reagieren soll.
Render-Layer zur Laufzeit wechseln (Node Set render layer, wie #211 für die Physik): Vorschlag: erst bei Bedarf als eigenes Issue.
Sortierung: Wirkt ein Render-Layer auch auf die Z-Order innerhalb einer Kamera? Vorschlag: nein. Er entscheidet nur, ob eine Kamera ein Objekt sieht. Die Reihenfolge bleibt wie heute bei Z und Hierarchie.
Folge-Issue aus #299 (Antwort 3 im Kommentar vom 2026-10-03): Eine Kamera soll wählen können, welche Layers sie sieht. Damit lässt sich z. B. das UI in einer eigenen Kamera zeichnen, ohne dass der Post-Processing-Shader der Spielkamera darüber läuft.
## Befund
- Heute zeichnet genau **eine** Kamera: die erste eingeschaltete in Hierarchie-Reihenfolge (`World.activeCamera`, #5). Ein Kamerawechsel läuft über `Set enabled`.
- Jede Kamera sieht **alles** in der Szene. HUD und Screens sind Container in der Welt und laufen deshalb mit durch einen Kamera-Shader (#299).
- „Layer“ gibt es bisher nur für die Physik: die Kollisionsebenen aus #152 (Projekteinstellungen, Zeilen *Layer* und *Collides with* am Collider). Die haben mit dem Zeichnen nichts zu tun.
- Auch der Mauszeiger der Laufzeit (`world.pointer`) wird über die eine aktive Kamera in die Welt umgerechnet.
## Zu bauen (Vorschlag)
- **Liste *Render layers*** in den Projekteinstellungen, neben *Collision layers*. Der erste Eintrag heißt `Default` und lässt sich nicht löschen.
- **Zeile `Render layer`** an allem, was zeichnet: Sprite, Text, Tilemap, Partikelquelle und Container. Ohne eigene Wahl gilt der Layer des Parents, ganz oben `Default`. Ein HUD-Container auf `UI` nimmt so seinen ganzen Inhalt mit.
- **Zeile `Sees`** an der Kamera: eine Mehrfachauswahl der Render-Layers wie *Collides with*, Standard alle.
- **Mehrere Kameras übereinander:** Zeile `Overlay` (Schalter) an der Kamera, Standard aus.
- Kameras ohne Overlay folgen weiter der Regel aus #5: Die erste eingeschaltete ist die Hauptkamera. Bestehende Projekte zeichnen dadurch unverändert.
- Jede eingeschaltete Overlay-Kamera zeichnet zusätzlich über die Hauptkamera, in Hierarchie-Reihenfolge, mit durchsichtigem Hintergrund.
- Jede Kamera trägt ihren eigenen Shader (#299) und wendet ihn nur auf ihr eigenes Bild an. Eine UI-Kamera ohne Shader bleibt also scharf, während die Spielkamera verschwimmt.
- Gilt im Game-Tab und auf `play.html`. Die Scene View zeigt weiter alle Layers.
- Die Physik bleibt davon unberührt: Render-Layers und Kollisionsebenen sind zwei getrennte Listen.
## Beweis beim Schließen
- Ein Sprite auf `UI` ist in einer Kamera, die nur `Default` sieht, nicht zu sehen. In einer Overlay-Kamera, die `UI` sieht, ist es zu sehen.
- Eine Spielkamera mit flachem Rot als Shader färbt die Welt rot, das UI aus der Overlay-Kamera behält seine Farbe.
- Ein Projekt mit zwei eingeschalteten Kameras ohne Overlay zeichnet wie vorher nur durch die erste.
## Offen (mit Vorschlag)
1. **Größe des Overlay-Bildes:** Bestimmt die Hauptkamera Bildgröße und Game-Scale, und eine Overlay-Kamera wird auf dieselbe Fläche gelegt? Vorschlag: ja. Eine Overlay-Kamera mit anderem Seitenverhältnis wird eingepasst (Fit), nicht verzerrt.
2. **Mauszeiger:** Durch welche Kamera rechnet `world.pointer`? Vorschlag: weiter durch die Hauptkamera. Ein eigener Node „Pointer in camera“ kommt, sobald ein UI auf Klicks reagieren soll.
3. **Render-Layer zur Laufzeit wechseln** (Node `Set render layer`, wie #211 für die Physik): Vorschlag: erst bei Bedarf als eigenes Issue.
4. **Sortierung:** Wirkt ein Render-Layer auch auf die Z-Order innerhalb einer Kamera? Vorschlag: nein. Er entscheidet nur, *ob* eine Kamera ein Objekt sieht. Die Reihenfolge bleibt wie heute bei Z und Hierarchie.
grundsätzlich ja, aber ich habe eine frage dazu. beispiel: main camera hat post-processing shader (siehe #299) und rendert layer 1 (dort befindet sich sprite z 0), zweite camera hat anderen post-processing shader und render layer 2 (dort befinden sich zwei sprites, eines mit z -1, und eines mit z 1) => wie verhält sich dann das post-processing?
1. vorschlag passt
2. vorschlag passt, für node eigenes issue
3. ja bitte eigenes issue anlegen
4. grundsätzlich ja, aber ich habe eine frage dazu. beispiel: main camera hat post-processing shader (siehe #299) und rendert layer 1 (dort befindet sich sprite z 0), zweite camera hat anderen post-processing shader und render layer 2 (dort befinden sich zwei sprites, eines mit z -1, und eines mit z 1) => wie verhält sich dann das post-processing?
admin
added this to the Development project 2026-10-03 13:27:50 +02:00
admin
moved this to Next in Development on 2026-10-03 13:27:52 +02:00
Umgesetzt in b232608, Doku im Wiki (e3775c2): Concepts (Abschnitt „Render layers and overlay cameras“), API, Architecture, Development.
Was gebaut ist
Projekteinstellungen: Liste Render layers unter Collision layers, höchstens 16, nur die letzte lässt sich entfernen (wie bei den Kollisionsebenen). Knopf Add render layer.
Zeile Render layer an Sprite, Text, Tilemap, Partikelquelle und Container, unter den Schaltern (SWITCHES). Standard ist Inherit: der Layer des Parents, ganz oben der erste.
Kamera: Zeilen Sees (Häkchen je Layer, Standard alle) und Overlay.
Hauptkamera bleibt die erste eingeschaltete Kamera, jetzt aber nur unter denen ohne Overlay. Zwei normale Kameras zeichnen weiter nur durch die erste.
Jede eingeschaltete Overlay-Kamera zeichnet ein eigenes Bild über die Hauptkamera, in Hierarchie-Reihenfolge, durchsichtig. Gilt in der Vorschau des Game-Tabs, im Spiel und auf play.html. Die Scene View zeigt alle Layers.
Deine Antworten
Bildgröße: Die Hauptkamera bestimmt Bildgröße und Game-Scale. Eine Overlay-Kamera wird ohne Verzerrung in das ganze Bild der Hauptkamera eingepasst. Gleiche Größe und gleicher Zoom ergeben genau dieselbe Fläche.
Mauszeiger: läuft weiter durch die Hauptkamera. Der Eingang camera an Mouse position und Is hovered ist #304.
Deine Frage zu Post-Processing und z: Jede Kamera zeichnet zuerst ihr eigenes Bild, nur mit ihren Layers und darin nach z sortiert. Danach werden die Bilder als Ganzes übereinandergelegt, Hauptkamera unten. In deinem Beispiel liegen deshalb beide Sprites der zweiten Kamera über dem Sprite der Hauptkamera, auch das mit z -1. z sortiert nie über Kameras hinweg. Mit #299 bekommt jede Kamera ihren Shader auf ihr eigenes Bild: Shader A wirkt nur auf das Sprite z 0, Shader B nur auf die beiden anderen. Ein „Dazwischen“ gibt es nicht, weil ein Post-Processing-Shader ein fertiges Bild braucht.
Soll etwas unter die Welt (z. B. ein Hintergrund mit eigenem Blur), macht man die Hintergrund-Kamera zur Hauptkamera (erste ohne Overlay) und die Spielkamera zum Overlay.
Was ich selbst festgelegt habe
Overlay-Kameras sind nie Hauptkamera. Ist nur eine Overlay-Kamera eingeschaltet, bleibt das Bild leer (No active camera), so wie ohne Kamera.
Der Hintergrund der Szene kommt nur von der Hauptkamera. Overlays haben keinen.
Was die Hauptkamera am Bildschirmrand abschneidet, schneidet sie beim Overlay mit ab.
Der Beweis mit dem Shader („Spielkamera mit flachem Rot färbt die Welt, das UI behält seine Farbe“) gehört zu #299, weil es den Kamera-Shader erst dort gibt. Ich vermerke ihn dort in einem Kommentar.
Beweis
e2e 63 (neu, 4 Checks):
Hauptkamera sieht Default, Overlay-Kamera 2000 Einheiten daneben sieht UI. Ein grünes Sprite des Overlays mit z -10 deckt ein rotes der Hauptkamera mit z 1000 (Mitte #00ff00, rechts #ff0000).
Ein gelbes UI-Sprite vor der Hauptkamera und ein blaues Default-Sprite vor dem Overlay erscheinen nicht. Dasselbe gilt im laufenden Spiel.
Ohne Overlay zeichnet die zweite Kamera nichts.
Der Dialog listet die Render-Layers getrennt von den Kollisionsebenen und hängt einen neuen hinten an.
7 neue Unit-Tests: Erben über die Parents (Modell und laufendes Spiel), Sees, Wahl von Haupt- und Overlay-Kameras, Einpassen, Undo, Speichern alter Projekte.
Gegenproben: Ohne Erben über die Parents fällt 1 Unit-Test. Werden die Overlays nie gezeichnet, fallen die beiden Overlay-Checks in e2e 63.
Umgesetzt in b232608, Doku im Wiki (e3775c2): *Concepts* (Abschnitt „Render layers and overlay cameras“), *API*, *Architecture*, *Development*.
## Was gebaut ist
- **Projekteinstellungen:** Liste *Render layers* unter *Collision layers*, höchstens 16, nur die letzte lässt sich entfernen (wie bei den Kollisionsebenen). Knopf *Add render layer*.
- **Zeile `Render layer`** an Sprite, Text, Tilemap, Partikelquelle und Container, unter den Schaltern (*SWITCHES*). Standard ist *Inherit*: der Layer des Parents, ganz oben der erste.
- **Kamera:** Zeilen `Sees` (Häkchen je Layer, Standard alle) und `Overlay`.
- **Hauptkamera** bleibt die erste eingeschaltete Kamera, jetzt aber nur unter denen ohne *Overlay*. Zwei normale Kameras zeichnen weiter nur durch die erste.
- **Jede eingeschaltete Overlay-Kamera** zeichnet ein eigenes Bild über die Hauptkamera, in Hierarchie-Reihenfolge, durchsichtig. Gilt in der Vorschau des Game-Tabs, im Spiel und auf `play.html`. Die Scene View zeigt alle Layers.
## Deine Antworten
1. **Bildgröße:** Die Hauptkamera bestimmt Bildgröße und Game-Scale. Eine Overlay-Kamera wird ohne Verzerrung in das ganze Bild der Hauptkamera eingepasst. Gleiche Größe und gleicher Zoom ergeben genau dieselbe Fläche.
2. **Mauszeiger:** läuft weiter durch die Hauptkamera. Der Eingang `camera` an `Mouse position` und `Is hovered` ist #304.
3. **`Set render layer`:** eigenes Issue #305.
4. **Deine Frage zu Post-Processing und z:** Jede Kamera zeichnet zuerst ihr **eigenes** Bild, nur mit ihren Layers und darin nach z sortiert. Danach werden die Bilder **als Ganzes** übereinandergelegt, Hauptkamera unten. In deinem Beispiel liegen deshalb **beide** Sprites der zweiten Kamera über dem Sprite der Hauptkamera, auch das mit z -1. z sortiert nie über Kameras hinweg. Mit #299 bekommt jede Kamera ihren Shader auf ihr eigenes Bild: Shader A wirkt nur auf das Sprite z 0, Shader B nur auf die beiden anderen. Ein „Dazwischen“ gibt es nicht, weil ein Post-Processing-Shader ein fertiges Bild braucht.
Soll etwas **unter** die Welt (z. B. ein Hintergrund mit eigenem Blur), macht man die Hintergrund-Kamera zur Hauptkamera (erste ohne *Overlay*) und die Spielkamera zum Overlay.
## Was ich selbst festgelegt habe
- **Overlay-Kameras sind nie Hauptkamera.** Ist nur eine Overlay-Kamera eingeschaltet, bleibt das Bild leer (*No active camera*), so wie ohne Kamera.
- **Der Hintergrund der Szene** kommt nur von der Hauptkamera. Overlays haben keinen.
- **Was die Hauptkamera am Bildschirmrand abschneidet**, schneidet sie beim Overlay mit ab.
- **Der Beweis mit dem Shader** („Spielkamera mit flachem Rot färbt die Welt, das UI behält seine Farbe“) gehört zu #299, weil es den Kamera-Shader erst dort gibt. Ich vermerke ihn dort in einem Kommentar.
## Beweis
- **e2e 63 (neu, 4 Checks):**
- Hauptkamera sieht `Default`, Overlay-Kamera 2000 Einheiten daneben sieht `UI`. Ein grünes Sprite des Overlays mit z -10 deckt ein rotes der Hauptkamera mit z 1000 (Mitte `#00ff00`, rechts `#ff0000`).
- Ein gelbes `UI`-Sprite vor der Hauptkamera und ein blaues `Default`-Sprite vor dem Overlay erscheinen nicht. Dasselbe gilt im laufenden Spiel.
- Ohne *Overlay* zeichnet die zweite Kamera nichts.
- Der Dialog listet die Render-Layers getrennt von den Kollisionsebenen und hängt einen neuen hinten an.
- **7 neue Unit-Tests:** Erben über die Parents (Modell und laufendes Spiel), `Sees`, Wahl von Haupt- und Overlay-Kameras, Einpassen, Undo, Speichern alter Projekte.
- **Gegenproben:** Ohne Erben über die Parents fällt 1 Unit-Test. Werden die Overlays nie gezeichnet, fallen die beiden Overlay-Checks in e2e 63.
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.
Folge-Issue aus #299 (Antwort 3 im Kommentar vom 2026-10-03): Eine Kamera soll wählen können, welche Layers sie sieht. Damit lässt sich z. B. das UI in einer eigenen Kamera zeichnen, ohne dass der Post-Processing-Shader der Spielkamera darüber läuft.
Befund
World.activeCamera, #5). Ein Kamerawechsel läuft überSet enabled.world.pointer) wird über die eine aktive Kamera in die Welt umgerechnet.Zu bauen (Vorschlag)
Defaultund lässt sich nicht löschen.Render layeran allem, was zeichnet: Sprite, Text, Tilemap, Partikelquelle und Container. Ohne eigene Wahl gilt der Layer des Parents, ganz obenDefault. Ein HUD-Container aufUInimmt so seinen ganzen Inhalt mit.Seesan der Kamera: eine Mehrfachauswahl der Render-Layers wie Collides with, Standard alle.Overlay(Schalter) an der Kamera, Standard aus.play.html. Die Scene View zeigt weiter alle Layers.Beweis beim Schließen
UIist in einer Kamera, die nurDefaultsieht, nicht zu sehen. In einer Overlay-Kamera, dieUIsieht, ist es zu sehen.Offen (mit Vorschlag)
world.pointer? Vorschlag: weiter durch die Hauptkamera. Ein eigener Node „Pointer in camera“ kommt, sobald ein UI auf Klicks reagieren soll.Set render layer, wie #211 für die Physik): Vorschlag: erst bei Bedarf als eigenes Issue.Umgesetzt in
b232608, Doku im Wiki (e3775c2): Concepts (Abschnitt „Render layers and overlay cameras“), API, Architecture, Development.Was gebaut ist
Render layeran Sprite, Text, Tilemap, Partikelquelle und Container, unter den Schaltern (SWITCHES). Standard ist Inherit: der Layer des Parents, ganz oben der erste.Sees(Häkchen je Layer, Standard alle) undOverlay.play.html. Die Scene View zeigt alle Layers.Deine Antworten
cameraanMouse positionundIs hoveredist #304.Set render layer: eigenes Issue #305.Soll etwas unter die Welt (z. B. ein Hintergrund mit eigenem Blur), macht man die Hintergrund-Kamera zur Hauptkamera (erste ohne Overlay) und die Spielkamera zum Overlay.
Was ich selbst festgelegt habe
Beweis
Default, Overlay-Kamera 2000 Einheiten daneben siehtUI. Ein grünes Sprite des Overlays mit z -10 deckt ein rotes der Hauptkamera mit z 1000 (Mitte#00ff00, rechts#ff0000).UI-Sprite vor der Hauptkamera und ein blauesDefault-Sprite vor dem Overlay erscheinen nicht. Dasselbe gilt im laufenden Spiel.Sees, Wahl von Haupt- und Overlay-Kameras, Einpassen, Undo, Speichern alter Projekte.