meleki/feuerwerk
1
0 Fork 0
Code Issues 38 Actions Projects 1 Wiki Activity

Kamera: Mausposition durch eine bestimmte Kamera (Eingang camera an Mouse position und Is hovered) #304

New Issue
Closed
opened 2026-10-03 15:04:31 +02:00 by meleki · 2 comments
meleki commented 2026-10-03 15:04:31 +02:00
Owner
Copy link
Copy source

Folge-Issue aus #302 (Antwort 2 im Kommentar vom 2026-10-03): Die Mausposition soll sich durch eine bestimmte Kamera umrechnen lassen, nicht nur durch die Hauptkamera.

Befund

  • Die Laufzeit rechnet den Mauszeiger über eine Kamera in die Welt um (world.pointer). Seit #302 ist das die Hauptkamera, also die erste eingeschaltete ohne Overlay.
  • Davon lesen Mouse position (x, y, inside) und Is hovered (Treffertest an dieser Stelle).
  • Eine Overlay-Kamera aus #302 kann woanders stehen und anders zoomen. Ein Knopf im UI, den nur sie zeigt, liegt dann in der Welt an einer ganz anderen Stelle als der Mauszeiger der Hauptkamera. Is hovered trifft ihn deshalb nicht, obwohl die Maus sichtbar darüber steht.

Zu bauen (Vorschlag)

  • Eingang camera (Objekt) an Mouse position und Is hovered. Offen bleibt alles wie heute: Es rechnet die Hauptkamera.
  • Mit einer Kamera am Eingang wird der Bildschirmpunkt durch deren Bild umgerechnet. Das ist das Bild, das #302 auf die Fläche der Hauptkamera legt (Fit).
  • inside heißt dann: Die Maus liegt auf dem Bild dieser Kamera.
  • Eine ausgeschaltete Kamera am Eingang liefert inside = false, so wie heute ohne aktive Kamera.

Beweis beim Schließen

  • Hauptkamera bei (0, 0), Overlay-Kamera bei (1000, 0) mit Zoom 2: Dieselbe Mausstelle ergibt über beide Kameras die erwarteten zwei Weltpunkte.
  • Ein Sprite auf UI, das nur die Overlay-Kamera zeigt: Is hovered mit dieser Kamera am Eingang wird wahr, sobald die Maus darüber steht. Ohne Kamera am Eingang bleibt es falsch.

Offen (mit Vorschlag)

  1. Soll Is hovered die Kamera selbst finden? Gemeint ist: die Kamera, die den Render-Layer des Objekts sieht. Vorschlag: nein. Sehen mehrere Kameras denselben Layer, wäre das nicht eindeutig, und ein offener Eingang soll wie heute bleiben.
  2. Klicks durch Overlay-Kameras: Mouse button bleibt, wie es ist, weil eine Taste keine Stelle hat. Vorschlag: nichts ändern.
Folge-Issue aus #302 (Antwort 2 im Kommentar vom 2026-10-03): Die Mausposition soll sich durch eine bestimmte Kamera umrechnen lassen, nicht nur durch die Hauptkamera. ## Befund - Die Laufzeit rechnet den Mauszeiger über **eine** Kamera in die Welt um (`world.pointer`). Seit #302 ist das die Hauptkamera, also die erste eingeschaltete ohne `Overlay`. - Davon lesen `Mouse position` (x, y, inside) und `Is hovered` (Treffertest an dieser Stelle). - Eine Overlay-Kamera aus #302 kann woanders stehen und anders zoomen. Ein Knopf im UI, den nur sie zeigt, liegt dann in der Welt an einer ganz anderen Stelle als der Mauszeiger der Hauptkamera. `Is hovered` trifft ihn deshalb nicht, obwohl die Maus sichtbar darüber steht. ## Zu bauen (Vorschlag) - Eingang **`camera`** (Objekt) an `Mouse position` und `Is hovered`. Offen bleibt alles wie heute: Es rechnet die Hauptkamera. - Mit einer Kamera am Eingang wird der Bildschirmpunkt durch deren Bild umgerechnet. Das ist das Bild, das #302 auf die Fläche der Hauptkamera legt (Fit). - `inside` heißt dann: Die Maus liegt auf dem Bild dieser Kamera. - Eine ausgeschaltete Kamera am Eingang liefert `inside` = false, so wie heute ohne aktive Kamera. ## Beweis beim Schließen - Hauptkamera bei (0, 0), Overlay-Kamera bei (1000, 0) mit Zoom 2: Dieselbe Mausstelle ergibt über beide Kameras die erwarteten zwei Weltpunkte. - Ein Sprite auf `UI`, das nur die Overlay-Kamera zeigt: `Is hovered` mit dieser Kamera am Eingang wird wahr, sobald die Maus darüber steht. Ohne Kamera am Eingang bleibt es falsch. ## Offen (mit Vorschlag) 1. **Soll `Is hovered` die Kamera selbst finden?** Gemeint ist: die Kamera, die den Render-Layer des Objekts sieht. Vorschlag: nein. Sehen mehrere Kameras denselben Layer, wäre das nicht eindeutig, und ein offener Eingang soll wie heute bleiben. 2. **Klicks durch Overlay-Kameras:** `Mouse button` bleibt, wie es ist, weil eine Taste keine Stelle hat. Vorschlag: nichts ändern.
admin added this to the Development project 2026-10-03 15:21:55 +02:00
admin commented 2026-10-03 15:24:14 +02:00
Copy link
Copy source

vorschläge passen denke ich

vorschläge passen denke ich
admin added the low-priority label 2026-10-03 15:24:24 +02:00
admin moved this to Next in Development on 2026-10-03 15:51:31 +02:00
admin moved this to Done in Development on 2026-10-03 19:09:52 +02:00
meleki commented 2026-10-03 19:10:40 +02:00
Author
Owner
Copy link
Copy source

Erledigt mit 70f3608.

Was gebaut ist

  • Eingang camera an Mouse position und Is hovered. Offen gelassen rechnet weiter die Hauptkamera, genau wie bisher.
  • Mit einer Kamera am Eingang wird der Mauszeiger durch das Bild dieser Kamera umgerechnet, so wie #302 es auf das Hauptbild legt (eingepasst, zentriert). Die Regel steht als reine Funktion in pointerThrough (src/core/properties/camera.ts).
  • in view (Mouse position) heißt dann: Die Maus liegt auf dem Bild dieser Kamera.
  • Eine Kamera, die nicht gezeichnet wird, liefert in view = false. Das gilt für eine ausgeschaltete Kamera, für eine zweite Kamera ohne Overlay und für ein Objekt, das gar keine Kamera ist.
  • Deine zwei offenen Punkte sind wie vorgeschlagen umgesetzt: Is hovered sucht sich keine Kamera selbst, und Mouse button (auch On click) bleibt bei der Hauptkamera.

Was ich selbst festgelegt habe

  • Die Ansicht meldet zusätzlich, wo die Maus im Hauptbild liegt, als Anteil von dessen Breite und Höhe. Die Laufzeit rechnet daraus für jede Kamera um.
    • Grund: world.pointer wird nur bei Mausereignissen neu berechnet. Hätte ich „Zeiger minus aktuelle Hauptkamera“ gerechnet, wäre die Maus bei laufender Hauptkamera über das HUD gewandert, obwohl sie still steht.
    • Der Unit-Test prüft genau das: Die Hauptkamera rückt um 500 weiter, der Punkt durch das Overlay bleibt (1050, 25).

Beweis

  • Zwei Weltpunkte: Hauptkamera bei (0, 0), Overlay bei (1000, 0) mit Zoom 2. Dieselbe Mausstelle ergibt (100, 50) durch die Hauptkamera und (1050, 25) durch das Overlay (Unit-Test).
  • Gleich mit dem Bild: An vier Bildschirmpunkten und für zwei Kameras landet die Regel auf demselben Weltpunkt wie overlayView + screenToWorld, also wie das gezeichnete Bild. Eine davon ist schmaler als das Hauptbild, damit fällt auch der Rand daneben richtig.
  • Im Browser (e2e 63c2): Overlay mit Zoom 2, echte Maus 30 Einheiten rechts der Bildmitte. Das Log zeigt true (Is hovered durch das Overlay auf dem grünen Sprite), false (ohne Kamera) und x = 2015 (Overlay auf 2000, plus 15).
  • Gegenproben greifen:
    • Math.max statt Math.min in der Regel lässt den Bild-Vergleich fallen.
    • Ohne die Prüfung „wird gezeichnet“ fällt der Test mit der ausgeschalteten und der zweiten normalen Kamera.
    • Meldet die Ansicht immer die Bildmitte, fällt 63c2 mit x = 2000 statt 2015.

Nebenbei

  • 1d0fa7b (Zoom bis 20×) hatte einen Unit-Test kaputt gemacht. play-settings.test.ts erwartete, dass 8 keine Stufe ist. Er prüft jetzt 20 als oberste Stufe und 21 als ungültig. Den Fehler habe ich damals nicht gesehen, weil ich nur view.test.ts und e2e 60 gefahren habe.

Tests (auf melektaus-atx)

Gate  → 231 Files, 3526 Tests, CHECK EXIT 0   (+6)
e2e 63 → ALL PASSED – 12 checks               (+1, Summe 1730)

Doku

Wiki bfbab14:

  • Behaviors, Abschnitt Mouse: der Eingang camera, in view, und wie man einen HUD-Knopf klickt.
  • Concepts: Verweis statt „#304 is about asking another“, dazu die Messung aus Schritt 63.
  • Architecture: gamePointer und pointerThrough.
  • Development: Summe 1730.
Erledigt mit 70f3608. ## Was gebaut ist - **Eingang `camera`** an `Mouse position` und `Is hovered`. Offen gelassen rechnet weiter die Hauptkamera, genau wie bisher. - **Mit einer Kamera am Eingang** wird der Mauszeiger durch das Bild dieser Kamera umgerechnet, so wie #302 es auf das Hauptbild legt (eingepasst, zentriert). Die Regel steht als reine Funktion in `pointerThrough` (`src/core/properties/camera.ts`). - **`in view`** (`Mouse position`) heißt dann: Die Maus liegt auf dem Bild dieser Kamera. - **Eine Kamera, die nicht gezeichnet wird**, liefert `in view` = false. Das gilt für eine ausgeschaltete Kamera, für eine zweite Kamera ohne *Overlay* und für ein Objekt, das gar keine Kamera ist. - **Deine zwei offenen Punkte** sind wie vorgeschlagen umgesetzt: `Is hovered` sucht sich keine Kamera selbst, und `Mouse button` (auch `On click`) bleibt bei der Hauptkamera. ## Was ich selbst festgelegt habe - **Die Ansicht meldet zusätzlich, wo die Maus im Hauptbild liegt**, als Anteil von dessen Breite und Höhe. Die Laufzeit rechnet daraus für jede Kamera um. - Grund: `world.pointer` wird nur bei Mausereignissen neu berechnet. Hätte ich „Zeiger minus aktuelle Hauptkamera“ gerechnet, wäre die Maus bei laufender Hauptkamera über das HUD gewandert, obwohl sie still steht. - Der Unit-Test prüft genau das: Die Hauptkamera rückt um 500 weiter, der Punkt durch das Overlay bleibt (1050, 25). ## Beweis - **Zwei Weltpunkte:** Hauptkamera bei (0, 0), Overlay bei (1000, 0) mit Zoom 2. Dieselbe Mausstelle ergibt (100, 50) durch die Hauptkamera und (1050, 25) durch das Overlay (Unit-Test). - **Gleich mit dem Bild:** An vier Bildschirmpunkten und für zwei Kameras landet die Regel auf demselben Weltpunkt wie `overlayView` + `screenToWorld`, also wie das gezeichnete Bild. Eine davon ist schmaler als das Hauptbild, damit fällt auch der Rand daneben richtig. - **Im Browser (e2e 63c2):** Overlay mit Zoom 2, echte Maus 30 Einheiten rechts der Bildmitte. Das Log zeigt `true` (`Is hovered` durch das Overlay auf dem grünen Sprite), `false` (ohne Kamera) und x = 2015 (Overlay auf 2000, plus 15). - **Gegenproben greifen:** - `Math.max` statt `Math.min` in der Regel lässt den Bild-Vergleich fallen. - Ohne die Prüfung „wird gezeichnet“ fällt der Test mit der ausgeschalteten und der zweiten normalen Kamera. - Meldet die Ansicht immer die Bildmitte, fällt 63c2 mit x = 2000 statt 2015. ## Nebenbei - **`1d0fa7b` (Zoom bis 20×) hatte einen Unit-Test kaputt gemacht.** `play-settings.test.ts` erwartete, dass 8 keine Stufe ist. Er prüft jetzt 20 als oberste Stufe und 21 als ungültig. Den Fehler habe ich damals nicht gesehen, weil ich nur `view.test.ts` und e2e 60 gefahren habe. ## Tests (auf `melektaus-atx`) ``` Gate → 231 Files, 3526 Tests, CHECK EXIT 0 (+6) e2e 63 → ALL PASSED – 12 checks (+1, Summe 1730) ``` ## Doku Wiki bfbab14: - *Behaviors*, Abschnitt *Mouse*: der Eingang `camera`, `in view`, und wie man einen HUD-Knopf klickt. - *Concepts*: Verweis statt „#304 is about asking another“, dazu die Messung aus Schritt 63. - *Architecture*: `gamePointer` und `pointerThrough`. - *Development*: Summe 1730.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
held-back
high-priority
low-priority
new
particles
question
shader
Shader-Assets, Shader-Graph, Filter
 state-machine
State machine follow-ups (from #51)
 todo-note
Aus dem alten todo-notes/-Ordner übernommen
No labels low-priority
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Development
Done
Assignees
Clear assignees
meleki
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meleki/feuerwerk#304