Scene Model

After defining assets as the building blocks of content, the scene model defines how those assets are arranged, referenced, and combined into complete live 3D worlds.

Real-time 3D has traditionally been shaped by the needs of games, and many scene models still inherit game-centric concepts and terminology.

3dverse takes a different path, avoiding these object-oriented abstractions in favor of a data-oriented approach. It follows the principles of the Entity–Component–System (ECS) pattern, but adapts them for a cloud-native context.

The result is a generic model that avoids assumptions tied to game-engine object structures, making it applicable to any kind of real-time 3D experience.

Entity-Component-System (ECS)

The scene model in 3dverse is data-oriented. It follows the broad principles of ECS:

• Entities are containers with no behavior on their own.
• Components hold the data that defines an entity’s state.
• Systems act on entities based on their components, but remain invisible to users.

This separation keeps scenes lightweight to represent and easy to synchronize, while still allowing rich behavior to emerge from components.

Entities

An entity is the most basic building block of a scene. On its own, it has no behavior or predefined structure — it only gains meaning through the components it holds.

To keep the model simple and unambiguous, an entity can hold at most one instance of each component type. Its identity and role in the scene are defined entirely by this unique set of components.

For example:

• An entity with only a transform is just a logical point in space.
• Add a mesh_ref and a material_ref, and it becomes visible.
• Add a rigid_body, a sphere_geometry, and a physical_material, and it becomes a simulated sphere in the physics world.

Components

Components are the data units that give entities their meaning. They are simple structured data — no behavior, just fields and values.

Some fields encode state directly, while others store asset identifiers. This keeps entities lightweight while allowing them to reference external resources reliably.

For example:

• A mesh_ref component stores the UUID of a Mesh asset and may specify which submesh to render.
• A material_ref component stores the UUID of a Material asset that defines the object’s appearance.
• A rigid_body component stores physical properties such as mass or damping.

Because components are schema-based and pure data, they can be serialized, transmitted, and synchronized efficiently — a key property for real-time collaboration in the cloud. And since they reference assets rather than embed them, many entities can reuse the same resource, a principle that extends directly to instancing at scale.

Systems

Systems are the engine’s internal processes that provide behavior to entities based on their components. They run in bulk, acting on many entities at once, and remain invisible to users.

Examples include:

• A rendering system that produces pixels for entities with both a mesh_ref and a material_ref.
• A physics system that simulates motion for entities with rigid_body components.
• An animation system that updates entities carrying skeleton_ref and animation_controller components.

From the user’s perspective, systems themselves cannot be modified. Entity behavior can only be influenced by attaching or removing components.

Scripts

Scripts are a complementary way to add behavior, but at the entity level instead of in bulk. They are assets that can be bound to entities through a script_map component, which may reference multiple script assets.

While systems batch entities and provide built-in behavior, scripts let developers introduce custom, per-entity logic. They sit adjacent to the ECS: not components, not systems, but user-defined assets that extend behavior in a fine-grained way.

A Unified Data Model

Beyond individual entities and components, scenes must solve a set of common concerns: identity, hierarchy, composition, and instancing.

In many engines, each of these requires its own data model — object trees, prefab systems, instancing pipelines — which complicate storage and synchronization.

3dverse takes a different path.

All of these relationships are expressed within the same data-oriented entity–component model. With nothing but components, the platform can represent the full range of scene structure and reuse, without introducing parallel data models.

Identity

Any scene model needs a way to uniquely identify its entities.

In many tools this identity is implicit — tied to an entity’s position in a tree, a memory address, or an editor-assigned label. These approaches often break down in collaborative or streaming contexts, where content is created, destroyed, and reloaded dynamically.

3dverse makes identity explicit through the euid component (Entity Unique IDentifier).

It stores a UUID as plain data, stable across sessions, scenes, and users. This design ensures references are unambiguous and persistent, without relying on hidden structures or fragile naming schemes.

Entities may also hold a debug_name component for human-friendly labeling in tools, but this is purely a convenience — uniqueness of names is not required.

Lineage: Hierarchy without a Tree

Most engines hard-code hierarchy into the scene as an object tree, where entities are stored as parents and children.

This structure feels natural in an editor, but it complicates storage and synchronization: every change in hierarchy ripples through the tree, even if only a small part of the scene is affected.

3dverse avoids baking hierarchy into the model. Instead, hierarchy emerges through the lineage component, which records the euid of an entity’s parent. Scenes remain a flat list of entities, while tools can reconstruct the familiar tree view on demand.

This keeps the storage simple and efficient to stream, while still supporting hierarchical workflows for editing and visualization.

The only caveat is that invalid data can be produced if an entity is parented to one of its own descendants — but such cases are easy to detect and reject during validation.

Natural Instancing

Large scenes often require repeating the same content at scale — a forest with thousands of trees, or a city block made of identical buildings.

In many engines, this leads to either duplicated assets (wasting storage and breaking synchronization) or a dedicated instancing subsystem that adds its own rules on top of the scene model.

In 3dverse, instancing doesn’t need a separate mechanism. Because components only hold references to assets by UUID, many entities can point to the same Mesh or Material without duplicating the underlying data.

The heavy payload is stored, streamed, and uploaded to the GPU once, while each entity varies through lightweight component values like transform or material settings.

Users could still choose to duplicate assets, but when they rely on references, instancing emerges naturally from the unified data model rather than from a special-purpose system.

Scene Composition: Instancing at the Scene Level

Large environments are rarely built as a single scene. They are assembled from modules — a room inside a building, a block inside a city — and often need to be reused or varied across projects.

Most engines introduce dedicated constructs for this, such as prefabs or blueprints. While effective, these add another data model on top of the scene, with their own lifecycle and override rules, increasing complexity.

In 3dverse, scene composition is not a special case.

It follows the same principle as asset instancing: everything is expressed as components and references. Instead of many entities pointing to the same Mesh or Material, entire scenes can be referenced and combined inside others, with changes reflected live and without duplication.

Linkers

Scene composition is effectively enabled by the scene_ref component.

An entity with this component effectively embeds another scene inside the current one — this is what we call a linker. Because this reference is live, any change made to the source scene is immediately reflected in every consuming scene.

This makes it easy to assemble large environments from smaller scenes and to keep work in sync across teams, without duplication or manual updates.

Overriders

Sometimes reusing a scene is not enough — you also need variation.

In 3dverse, this is expressed with the overrider component.

When an entity carries this component, it becomes an overrider entity whose effects are applied at runtime. It always targets an entity inside a linked scene, and can resolve targets through arbitrarily deep chains of linkers.

The overrider component carries:

• Target euid — the identifier of the entity to affect in the referenced scene.
• Sequence of linker euids — the chain of linkers from the top scene to the target. This disambiguates which occurrence to modify when the same scene is linked multiple times, which can produce several live entities with the same euid in a single runtime context.
• Actions — the operations to apply:
  • Delete the target entity.
  • Delete selected components from the target entity.

In addition, any other components on the overrider entity are applied to the target at runtime: if a component is absent it is added; if it is present it is replaced entirely.

Only the overrider entity needs to exist in the top scene’s data. Everything else is resolved dynamically at runtime. The source scene remains untouched; only the consuming scene observes the overridden result.

---

By solving identity, hierarchy, composition, and instancing within the same flat model, 3dverse avoids the need for parallel data structures like object trees or prefab systems.

The result is a scene model that is simple to represent, efficient to synchronize, and scalable to massive environments — while still supporting the editing patterns creators expect.

---

Scene Model at a Glance

• Entities — containers for components; each carries an euid for identity.
• Components — plain data that define state; some fields reference assets by UUID.
• Systems — engine-side processes that provide built-in behavior, invisible to users.
• Scripts — user-defined assets that extend behavior at the entity level.
• Lineage — a component that builds hierarchy through parent references.
• Linkers — entities with a scene_ref component that reference other scenes.
• Overriders — entities with an overrider component that locally modify linked entities.
• Instancing — many entities referencing the same asset without duplication, efficient at scale.

Architectural Reflection

The 3dverse scene model is deliberately generic and data-oriented.

Where many engines build on object hierarchies with concepts like GameObjects or Players, 3dverse keeps everything expressed as entities and components. Behavior comes from engine systems or from scripts layered on top — never from hidden inheritance chains.

This approach can efficiently model a wide range of real-time 3D domains, including:

• Games and interactive experiences — gameplay, storytelling, and immersive apps
• Industrial digital twins — monitoring and simulating factories, plants, or infrastructure
• Collaborative design reviews — teams inspecting and iterating on CAD or BIM models
• Simulation and training — procedural environments for education, safety, or skills practice
• Robotics and autonomous systems — testing, validation, and visualization of agents in virtual worlds

By structuring scenes this way, 3dverse avoids the limitations of object-centric models and provides a foundation for building any kind of live, collaborative 3D environment.

---

With the scene model established, the next core concept is access control — how the platform governs who can view, edit, and collaborate on assets.