Skip to content

Streaming without holes 11/12: a large world loads its object table by distance, without crashing the tab #404

Description

@pasquelin

Why

A large compiled world reads its whole object table before its first frame, and the tab crashes.

  • Seen: the open world with 2 regions (90 k placed nodes, 7 031 primitives) loads in 9.8 s to a 767 MB JS heap, then the tab crashes on the first frame.
  • Fetched and parsed before the first frame: scene-tables.json 72 MB (≈ 800 B per node), source.gltf 24 MB, scene.gltf 20 MB, clusters.json 9.6 MB. The full world holds ≈ 300 k nodes.

To do

Files

  • Reproduction: site/examples/an-open-world.html, scripts/docs-open-world.ts (branch 332-open-world).

Proof of done

  • A lightweight reproduction scene of the repository (comparable node/table shape, seconds to load) opens and draws its first frame without crashing the tab; JS heap and bytes fetched before the first frame published, before and after.
  • Proven on one scene never tuned on.
  • Verified against the open world in pasquelin/Trillion3D-openworld, once the engine there is pinned on the fixing commit.

Links

Moved out (CTO, 26 Sept.)

This issue keeps the audit remainders delivered by branch 404-audit-remainders: the dead code in the arrival queue, one frame budget, cellReach following the zoom, the inCellFrame shear, and a scale-down growing rows in place on engines with growPlacements. Moved:

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggeometryVirtualized geometry, DAG, cluster selection, rastermeasure okTiming passed (numbers in a comment)🔴 criticalCritical priority: rendering correctness and FPS

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions