Runtime Model

String3D is one module instance inside the StringTune runtime, not a separate app-level scene manager you create by hand.

Main participants

• String3D owns settings, provider bootstrap, and the frame hook.
• String3DRenderer owns the render surface and frame output.
• String3DScene owns created 3D objects.
• String3DSynchronizer translates DOM state into 3D transforms and style-driven changes.
• DirtySyncManager optionally narrows updates to changed elements.

Initialization flow

1. StringTune starts.
2. String3D.onInit() runs.
3. The module bootstraps the provider and creates the renderer, camera, scene, and synchronizer.
4. Connected DOM objects are flushed into the scene.

Frame flow

Each frame:

1. the module batches layout reads
2. synchronizers update root objects and children
3. filter targets are collected
4. the renderer draws the final frame

Why this matters

This explains two important behaviors:

• DOM size and computed style are the input contract
• scene mutations are derived from markup instead of being authored as independent mesh code

When settings take effect

Module settings such as container, zIndex, useDirtySync, styleReadIntervalMs, and layoutReadIntervalMs are read from this.settings and can be re-applied through onSettingsChange().