1104. Lesson identity
1105. Learning objective
After this lesson, you can classify the responsibilities of simulation state, transforms, views, material appearance, and update owners along a 3D render path. You can express that classification as a responsibility map containing an owner, input, output, and reason for each relevant link.
1106. Why this matters
A 3D object on screen is evidence of state, not the state itself. When these responsibilities are mixed, a visual fix can silently change game rules, or two systems can fight over the same transform or material. Clear ownership gives you a stable basis for directing AI and reviewing its code. It also makes visual bugs easier to localize: you can ask whether the authoritative state is wrong, the transform is wrong, the view or material is wrong, or an unauthorized system is writing the value.
1107. Prior knowledge
You should be able to distinguish game state from presentation and read a basic 3D scene structure. The previous module introduced ownership discipline: a requested change should have a bounded diff and a named owner. This lesson applies that discipline to the path from simulation data to rendered pixels.
1108. Core concept
The rendered object is a view of simulation state. It is not the authoritative record of what the game believes.
Use the following separation:
- Simulation state: Authoritative facts used by game rules, such as an actor's logical position, velocity, health, or current mode.
- Transform: The spatial representation used to place an object in the scene. It may be derived from simulation state and may include interpolation, rotation, scale, or presentation offsets.
- View: The scene object and visual components that present state to the player, including a mesh, animation, particles, lights, and similar elements.
- Material responsibility: Control of surface appearance, such as color, texture, roughness, or emissive response. A material can communicate state without owning that state.
- Update owner: The one declared system responsible for deciding when and how a value changes.
The key distinction is authority. If a gameplay rule asks, “Where is the actor?”, it should query the simulation representation or the collision representation declared by the simulation. It should not inspect a mesh position merely because that position is visible. The view can lag, interpolate, shake, animate, change material parameters, or be temporarily hidden without changing the underlying game truth.
1109. Mental model
Use the truth-to-pixels chain:
simulation state
│ derives or synchronizes
▼
transform
│ is presented by
▼
view + material
│ is drawn by
▼
renderer / screen
In linear form: simulation state provides an input to a transform owner; the resulting transform is consumed by the view and material presentation; the renderer then draws that presentation to the screen.
Assign responsibilities separately:
| Responsibility | Main question | Typical owner |
|---|---|---|
| Simulation state | What does the game believe? | Simulation or gameplay system |
| Transform | Where should the scene object be placed? | Spatial synchronization or presentation system |
| View | What should the player see? | View, animation, or presentation system |
| Material | How should the surface appear or communicate state? | Material or presentation system |
| Update timing | When and by whom may this value change? | The declared owner of that value |
A responsibility map may be submitted as a table or as an ordered list. If you use a list, give every entry the headings classification, owner, input, output, and reason. Data-flow arrows may be written linearly, for example: simulation position → spatial synchronizer → scene transform.
When debugging, inspect the chain from left to right. Do not begin by changing the mesh because it is the most visible part. First determine which link contains the incorrect value and which system is allowed to write it.
1110. Concrete example
Imagine a drone whose simulation state contains:
logicalPosition = (4, 0, 8)
velocity = (0, 0, -2)
active = true
A presentation system copies the logical position into the drone's transform each render frame. It also adds a small vertical hover offset and interpolates between recent positions so movement appears smooth. A view system uses active to select an emissive material for the drone's indicator. The mesh may therefore be drawn at a position that differs slightly from logicalPosition, and its material may communicate activity without owning the active value.
Those differences can be valid. A collision rule should use the simulation position or the collision representation defined by the simulation, not the hover offset on the mesh. If a cutscene hides the drone, applies a visual tilt, or changes its material, those actions should not rewrite the drone's logical position or active state. Conversely, if gameplay moves the drone but the transform owner does not synchronize it, the simulation can be correct while the view is stale.
Use the symptom to choose the first bounded inspection:
- Gameplay reports the wrong location: inspect simulation state and its owner.
- State is correct but the scene object is misplaced: inspect transform synchronization and competing transform writers.
- Transform is correct but the object looks wrong: inspect the view, material, and renderer inputs.
- The object changes twice during one frame: inspect update ownership and competing writers.
1111. Common mistake
The common mistake is treating the visible scene object as the game object itself. This leads unrelated gameplay systems to read or write a mesh transform or material directly. It can also allow every system that needs a visual adjustment to become a writer. The result may look acceptable in one frame while making authority impossible to trace.
A transform or material is not authoritative merely because it exposes a convenient property such as position or color. Ask what the value means, which system owns it, whether it derives from a more authoritative value, and whether it belongs to game rules or only presents their result.
1112. Guided practice
A moving platform has a simulation position, velocity, and active state. A spatial synchronizer places its scene node. A presentation system changes the platform indicator's material when it is active. A camera system follows the platform with smoothing. During debugging, the platform appears one meter behind its expected location.
Classify each item. For every item, provide classification, owner, input, output, and reason.
- The platform's velocity determines its next logical position.
- The scene node receives a position from the spatial synchronizer.
- The indicator material changes color when the platform is active.
- The camera uses a smoothed target based on the platform's position.
- A debug script writes directly to the scene node every frame.
Attempt checkpoint
Complete all five entries before reading the model answer. Your initial map can be a table or an ordered list. Mark any owner you consider ambiguous and state what evidence would resolve the ambiguity.
Reveal the model answer after attempting the map
| Item | Classification | Owner | Data flow | Reason |
|---|---|---|---|---|
| 1 | Simulation state | Platform simulation or movement system | velocity → movement rule → logical position |
It changes the logical position used by game rules. |
| 2 | Transform | Spatial synchronizer | simulation position → spatial synchronizer → scene-node transform | It transfers simulation truth into scene space. |
| 3 | Material/view | Presentation or material system | simulation active state → presentation rule → indicator material parameter or selection |
It changes appearance without owning the platform's active state. |
| 4 | View behavior | Camera presentation system | platform position → smoothing function → camera target or transform | It derives a visual result and should not rewrite platform simulation state. |
| 5 | Ownership risk | No legitimate owner unless declared as a bounded debug override | debug script → scene transform, competing with spatial synchronizer → scene transform | It creates a second writer and makes the result dependent on update order. |
For the one-meter offset, first inspect the spatial synchronizer and the values it receives. Then determine whether the debug script overwrites the same transform. Do not begin by moving the mesh until the ownership question is resolved.
1113. Transfer case
A navigation marker has the correct logical destination, but its visible icon briefly jumps to the previous destination after a route refresh. A route system owns the logical destination, a marker synchronizer writes the icon transform, and a transition animation also writes that transform for two frames.
Create a three-entry responsibility map for the route system, marker synchronizer, and transition animation. Identify the competing writer and name the first bounded inspection you would perform. Do not treat the preceding platform answer as proof; this case must be reasoned from its own owners and data flow. No model answer is supplied inline.
1114. Validation and assessment
The lesson quiz checks the conceptual distinctions. The linked practical assessment requires an independent responsibility map for a novel object and symptom. It asks you to identify authoritative state, transform ownership, view or material ownership, data-flow arrows, a competing writer, and the first bounded inspection, then make a corrective decision.
You have met the objective when you can trace a visual discrepancy through simulation state, transform, view, material, and update responsibility without treating the rendered object as the source of truth.
1115. Key takeaways
- Simulation state records what the game believes; the rendered object presents that belief.
- A transform is a spatial representation and may include presentation-specific changes.
- Materials communicate appearance or state but do not automatically own the state they display.
- Views can animate, interpolate, hide, or decorate an object without changing simulation truth.
- Every writable value needs a declared owner and a traceable data flow.
- The first inspection should be bounded by the symptom and the responsibility map.
1116. Next lesson
Next: 3.6 L2 — Trace a 3D frame. The next lesson applies this responsibility model while tracing the ordered work of a complete 3D frame.