feat: Scene | Runtime tabs in the graph during play mode (closes #898)

[marquezmiguel]

Summary

Implements #898: while playing, the graph now shows two tabs following the inspector's tabs pattern — Scene keeps the edited scene fully editable exactly as before (undo/redo, context menu, drag and drop, save), and Runtime shows the live hierarchy of the play scene: objects created by scripts appear as they spawn, can be selected and inspected, and tweaked through the inspector (volatile changes, lost on stop). This mirrors the Local/Remote workflow of other editors for data-driven games where most content is spawned at runtime.

When the game is not playing, behavior is byte-equivalent to the current editor: no tabs, no guards, nothing changes.

Changes made

• Graph: dual tree state (edited scene / play scene) with tabs rendered only while playing. Separate trees keep id collisions between the exported scene and the play scene from leaking selection or expansion states across tabs.
• Selection/expansion preservation across refreshes is now indexed by id (Map) instead of scanning the previous tree per node: runtime scenes can hold tens of thousands of nodes and the previous O(n²) matching froze the UI (measured 46s → ~0.2s per refresh on a 22k-node scene).
• Structural operations (rename, reparent, remove, clone, paste, drops, enabled toggles) are guarded per object: play scene objects are read-only, edited scene objects keep the exact current behavior even while playing.
• Undo/redo: registerUndoRedo items now carry an optional object used by a volatile predicate installed during play — edits on edited scene objects keep recording history, edits on play scene objects execute without polluting the stack (they would reference disposed objects after stop).
• Play lifecycle hardening: re-entrance guards on restart (double restart / src watcher / ipc triggers), stop-during-loading and stop-during-restart are now safe, and forceCompileAllSceneMaterials resolves when its scene is disposed mid-compilation instead of hanging forever.
• Scene inspector: global sections (physics gravity, rendering pipelines) are hidden when inspecting the play scene — they edit the edited scene and would silently persist without undo.
• New tools/scene/play/runtime.ts helpers (isScenePlaying, getObjectScene, isPlaySceneObject) shared by all the guards, with unit tests. Existing behavior is preserved by 72 passing tests.

Benefits

• The editor becomes usable for data-driven / procedurally-loaded games (worlds loaded from data at runtime), where today the graph shows nothing of what actually runs.
• Runtime objects can be selected and inspected live (materials, transforms) like in other engines' play modes.
• No behavior change at all outside play mode, and the edited scene can still be worked on while the game runs.

Follow-ups (out of scope, happy to discuss)

• Viewport picking of runtime objects while playing.
• Gizmos attached to runtime objects (requires a utility layer on the play scene).
• Structural editing of the play scene (Unity-like volatile hierarchy edits) and an "apply play changes to scene" action.

Note for reviewers: future registerUndoRedo call sites should pass object when reachable during play; items without it fall back to the inspector's edited object to classify volatility.

🤖 Generated with Claude Code

[julien-moreau]

@marquezmiguel love the way it renders the orignal scene and runtime scene in tabs. I'm reviewing it and trying it.

[marquezmiguel]

@marquezmiguel love the way it renders the orignal scene and runtime scene in tabs. I'm reviewing it and trying it.

I thought it was important to keep the original scene, since there may be people who need to keep it. In the tests I ran, it works pretty well, and both worlds coexist perfectly

[julien-moreau]

@marquezmiguel I totally agree. What is the real usage of having the 2 scenes coexisting ? I really don't use it at all so I need help to understand ^^

[marquezmiguel]

@marquezmiguel I totally agree. What is the real usage of having the 2 scenes coexisting ? I really don't use it at all so I need help to understand ^^

For projects that build content at runtime it's the only way to see what the game actually created. My world is fully spawned by scripts on Play (thousands of meshes from data files) — those nodes don't exist in the edit scene, so without the Runtime tab I can't select a spawned mesh and check why it looks wrong. And keeping the Scene tab means Play doesn't lock you out of your real scene: you always know your edits land somewhere persistent, not in the runtime copy that dies on Stop. Same idea as Godot's Local/Remote tabs

[julien-moreau]

And keeping the Scene tab means Play doesn't lock you out of your real scene: you always know your edits land somewhere persistent, not in the runtime copy that dies on Stop. Same idea as Godot's Local/Remote tabs

I totally understand but what makes the editor useful is the realtime feedback when changing values. In the original scene, when playing, I modify values but I don't see the effect so I don't use it anymore. So my question is how is it useful to have the orignal scene graph still accessible? The rest is really ok for me