WorldOriginAnchor

A bare marker for the one entity the renderer's floating origin should track, so a space-scale world stays centred on your ship.

What it does

WorldOriginAnchorSystem finds the first active entity carrying this marker plus a Transform6DOF, reads its post-step x/y/z each frame, and records it as the renderer's floating-origin offset through the adapter's setOriginOffset(x, y, z). That's the whole job — it's the "rebase the large world around this subject" half of Wingman's split OriginAnchor (its sibling, ChaseCameraTarget, is the "camera follows this subject" half). Why it matters: fly astronomically far from (0,0,0) and float precision collapses — shaders shimmer, physics jitters — so the fix is to keep the rendered world centred on a chosen subject and offset everything by its position. The System runs at priority -88 (after the movement integrator at 60, before the camera systems) so the recorded offset reflects this frame's new position, and it's non-pauseable. Phase-1 is contract-only / dormant: the adapter stores the offset (a HUD can read it back via getOriginOffset) but performs no per-frame rebase yet, so the rest of the game keeps passing real world coordinates — this component is already the piece that will feed an active large-world backend when one lands.

Use it in a scene

A scene is just data — a list of entities, each with its components. At startup the SceneLoader turns this JSON into a live world; edit the file and reload to rebuild it.

Build it from scratch with the bjs CLI:

1Scaffold a project
```
npm create @babylonjsmarket/arcade@latest my-game
```
World, renderer, and dev server — ready to run.
2Install dependencies
```
cd my-game && npm install
```
3Add WorldOriginAnchor
```
bjs download WorldOriginAnchor
```
Copies its source into src/ so the scene resolves.
First time? Run bjs login once.
4Paste the scene into src/scenes/arcade-room.ts and run
```
npm run dev
```
SceneLoader builds the world from the JSON; reload to rebuild.

JSON

{
  "Player": {
    "tags": ["player"],
    "components": {
      "Transform6DOF": { "x": 0, "y": 0, "z": 0, "rx": 0, "ry": 0, "rz": 0 },
      "Renderable": { "shape": "spaceplane", "glbSrc": "/wingman/falconship.glb" },
      "WorldOriginAnchor": {}
    }
  }
}

Props

None. WorldOriginAnchor is a pure marker — its component holds no data (serialize() returns {}) and takes no parameters. Declare it as an empty block: "WorldOriginAnchor": {}.

Events

Emits nothing and listens for nothing on the EventBus — it's a passive per-frame reader, not a bus participant.
Side effect: calls renderer.setOriginOffset(x, y, z) with the anchor's Transform6DOF position every frame; a HUD reads the same value back via renderer.getOriginOffset().

Dependencies

Transform6DOF — required by the System's query and the source of the x/y/z it records as the origin offset. Put the marker on the same entity that carries the pose you want the world centred on (in Wingman, the player ship — the one that also carries ChaseCameraTarget and a Renderable).

Notes

Only the first active anchor wins. The origin tracks a single subject; extra WorldOriginAnchor markers on other entities are ignored while the first is active, and parked/inactive anchors are skipped.
Nothing renders for the marker itself — give the entity a Renderable (or MeshPrimitive) if you want to see the ship it's centred on.
Phase-1 is dormant by design: setOriginOffset only records the target, so adding this component won't move anything on screen yet. It's wired and contract-locked so an active floating-origin backend can switch on later with no scene changes.
Pair it with ChaseCameraTarget on the same ship: one marks the camera's subject, the other marks the world's rebase subject. They're deliberately separate jobs — conflating them is what made the original OriginAnchor overloaded.