VisualWorld
Visual configuration & rendering
How A3D handles ownership, simulation scheduling, rigid-body physics, and rendering.
Ownership
Application
is A3D's default top-level owner, owning the active
Scene
and the
Runner
that drives it.
Scene
is the central container for simulation state. It owns the node graph and scene content —
including meshes, physics bodies, materials, lights, and cameras — along with the major
systems that operate on them:
VisualWorld,
PhysicsWorld,
and
InputContext.
VisualWorld
drives the rendering stack,
PhysicsWorld
delegates rigid-body simulation to Bullet, and
InputContext
provides polling and mapping of platform input. The node graph hierarchically organizes all
scene content.
Runner
is responsible for advancing the
Scene
without owning it, keeping simulation scheduling separate from scene lifetime and state
ownership.
Application
is provided as the default application host, but
Runner
and
Scene
can also be embedded directly into arbitrary application frameworks.
VisualWorld
Visual configuration & rendering
PhysicsWorld
Physics configuration & simulation
PhysicsWorldProxy
→
Bullet
InputContext
Input polling & mapping
GLFW
TransformSimulation
Runner decouples host updates, rendering, and physics/simulation timing. Each host update
measures elapsed time, processes application and input work, then schedules zero, one, or up to a
configured maximum number of fixed-duration simulation steps. Physics and application simulation
therefore see a stable timestep even as frame timing varies. Once the scheduled steps are complete,
rendering observes the latest completed simulation state and a frame is presented.
Catch-up is bounded: if the host falls behind, Runner performs only a limited number of
simulation steps rather than allowing an ever-growing backlog. Excess accumulated time is discarded
and recorded. Pause, single-step, reset, and the simulation clock and step count are handled by the
scheduler itself rather than being left to the application.
Within each simulation step, execution follows a defined order. Queued pre-step work runs before application callbacks and physics, while post-step work runs afterward. This gives application code predictable places to modify and observe simulation state, while keeping physics updates and other step-sensitive changes from occurring at arbitrary points in the cycle.
sceneWillStep callbacksceneDidStep callbackPhysics
Physics is integrated directly with the scene graph. A Node may own a
PhysicsBody, which references a shareable PhysicsShape. As nodes enter or
leave the active scene, their bodies are added to or removed from the scene's PhysicsWorld
automatically.
PhysicsBody instances are automatically maintained by the PhysicsWorld as their
nodes are added to or removed from the scene. Public physics types delegate through internal proxies to
Bullet,
keeping backend-specific types out of the public object model.
Static · Kinematic · Dynamic
Convex hull · Concave decomposition · Primitive
Rendering
VisualWorld coordinates rendering for the active scene. Each frame,
scene traversal gathers the visible cameras, lights, meshes, materials, and transforms into an immutable
snapshot
needed to render the frame. This keeps the mutable scene graph as the application-facing model while giving
rendering a stable set of inputs. The gathered state is then resolved to graphics resources and converted
into
backend-oriented render packets. Packets are sorted by pipeline state before execution, reducing unnecessary
graphics-state
changes. Those packets are consumed by Renderer, which owns OpenGL/WebGL execution through the
active
RenderContext. The result is a staged pipeline from scene representation to extracted frame
state to GPU work, rather than rendering logic being embedded throughout scene objects.