The scene module stores 3D model content: geometry, textures, materials,
meshes, objects and transforms. It does not render by itself. Rendering is done
by attaching a Viewer and renderer such as
WebGLRenderer.
A Scene has a CoordinateSystem. Each SceneModel can also
define one. This lets one Scene contain models whose source data uses different
bases, units or origins.
Scene and SceneModel transforms use double-precision arrays on the CPU. Geometry
vertex arrays are single-precision. The WebGL renderer handles large world
coordinates with camera-relative matrices and tiled batches.
Creating a SceneModel
import { Scene } from"@xeokit/sdk/model/scene"; import { TrianglesPrimitive } from"@xeokit/sdk/base/constants";
"streaming" allows incremental model construction over time.
"sealed" closes the model to new topology after initial creation.
memoryPolicy is a renderer allocation
hint. It does not change the SceneModel's public data and is not a hard heap
limit. It tells renderers whether to use reusable backing stores or tightly
sized storage such as VBOs, data textures and renderer-side batch tables:
"stream" is the default for open, streaming or editable content.
Renderers may use their normal growable/reusable allocation strategy.
"compact" is for finalized content. Renderers should avoid avoidable
slack when allocating sealed models or committed batches.
Use seal when a model is complete and should reject
further topology/resource growth:
constsealRes = model.seal(); if (!sealRes.ok) thrownewError(sealRes.error);
For progressive construction of a single SceneModel, use batches when you
need to know exactly which components were created during a named loading
interval, or when an importer needs to partition a loading process into
explicit phases. A batch can stage a model file or file section and then
publish it as a unit. Viewers and renderers can defer partial batch content
until commit. Batch IDs are SceneModel construction IDs; they do not define
renderer draw batches or XGF stream structure.
constbatchRes = model.beginBatch({ id:"storey-02" }); if (!batchRes.ok) thrownewError(batchRes.error);
Scene Graph
📄 Cheatsheet — model/scene at a glance
The scene module stores 3D model content: geometry, textures, materials, meshes, objects and transforms. It does not render by itself. Rendering is done by attaching a Viewer and renderer such as WebGLRenderer.
A Scene owns one or more SceneModels. A SceneModel contains shared resources (geometries, materials, textures) and instances (meshes, objects, transforms).
Structure
Main types:
Coordinate Systems
A Scene has a CoordinateSystem. Each SceneModel can also define one. This lets one Scene contain models whose source data uses different bases, units or origins.
Scene and SceneModel transforms use double-precision arrays on the CPU. Geometry vertex arrays are single-precision. The WebGL renderer handles large world coordinates with camera-relative matrices and tiled batches.
Creating a SceneModel
Components are indexed by id:
Lifecycle and Memory Policy
A SceneModel can describe both how it will be built and how tightly renderers should allocate backing storage.
updateHint describes expected renderer-facing value upload cadence:
"auto"lets a renderer choose."static"is for models whose matrices, transforms, colors and object state are mostly stable while they are drawn many times."dynamic"is for models that frequently upload matrices, transforms, colors or object state.lifecycle describes construction:
"open"allows ordinary ad-hoc component creation."streaming"allows incremental model construction over time."sealed"closes the model to new topology after initial creation.memoryPolicy is a renderer allocation hint. It does not change the SceneModel's public data and is not a hard heap limit. It tells renderers whether to use reusable backing stores or tightly sized storage such as VBOs, data textures and renderer-side batch tables:
"stream"is the default for open, streaming or editable content. Renderers may use their normal growable/reusable allocation strategy."compact"is for finalized content. Renderers should avoid avoidable slack when allocating sealed models or committed batches.Use seal when a model is complete and should reject further topology/resource growth:
For progressive construction of a single SceneModel, use batches when you need to know exactly which components were created during a named loading interval, or when an importer needs to partition a loading process into explicit phases. A batch can stage a model file or file section and then publish it as a unit. Viewers and renderers can defer partial batch content until commit. Batch IDs are SceneModel construction IDs; they do not define renderer draw batches or XGF stream structure.
Rendering
Browser rendering is optional. A minimal setup uses a Scene, Viewer, WebGLRenderer, View and ViewController:
Compressed Geometry
Use compressGeometryParams when geometry has already been prepared for compact storage or faster SceneModel creation.
Dynamic Transforms
Meshes can reference SceneTransforms. Transforms can be nested and updated after creation.
Serialization
Import and Export
Format modules can load into, or export from, a SceneModel. For example, DotBIM:
Events and Lifecycle