Assets

In the previous section we saw how rendering sessions bring scenes to life on GPU nodes.

So far, we’ve only touched on scenes and assets at a high level — as the content that sessions load and render.

This section takes a closer look: what assets actually are, how they’re identified, how they’re structured, and why the platform treats them as the foundation of every scene.

Note that even a scene itself is an asset, which means the same rules of identity, structure, and storage apply consistently across all content.

Fundamentals

In most 3D workflows, assets are synonymous with files — formats like OBJ, FBX, or glTF act as both the container and the identity of the data.

This works for interchange between tools, but it is fragile as a foundation: paths and filenames can break, updates require replacing entire files, and reuse across projects often means duplication.

3dverse takes a different approach. An Asset is not a file but a persistent object in the platform, identified by a UUID and managed independently of its original container.

This makes assets stable to reference, easy to update, and reusable across projects and sessions without duplication.

Files are still important, but only as a source of assets. When you upload a file in a format such as FBX or glTF, the platform runs a backend conversion that extracts and stores its contents as platform-native assets, no longer tied to the original file.

Assets in 3dverse can be created in three main ways:

• Uploading source files — common 3D file formats such as FBX, glTF, and others. These go through a backend conversion process that extracts assets from the file.

• Uploading native assets — files that already follow the 3dverse asset schema.

• Programmatic creation — creating new assets directly through the Asset API.

Asset Types

3dverse defines a fixed set of asset types, covering everything required for rendering, simulation, interaction, and orchestration.

The most fundamental are:

Scene — A complete world description, serving as the entry point for rendering sessions.

Mesh — Geometric data representing 3D shapes.

Material — Definitions of how surfaces appear when rendered.

The full catalog of supported types is available in the Assets Reference.

Custom Asset Types

Users cannot currently extend the system with custom asset types.

Asset Identification

In 3D workflows, reliably identifying assets is a constant challenge. File paths can change, names are often duplicated, and moving projects across machines or teams easily breaks references. Without a stable way to point to data, collaboration and long-term maintenance quickly become fragile.

To avoid these issues, every asset in 3dverse is assigned a UUID (version 4) at creation time. This identifier is the asset’s permanent identity in the system:

• UUIDs are globally unique across the entire platform — no two assets, even of different types, can ever share one.
• Once assigned, a UUID is never reused. It is bound to the asset for its lifetime.
• Assets can be updated while keeping the same UUID, ensuring that all references remain valid.
• References to assets are always made by UUID, making them safe to reuse across projects.

UUIDs generated by the platform are always guaranteed to be unique.

If an asset is uploaded with a user-provided UUID that already exists, the platform will reject it — unless it is the same type of asset and the upload explicitly requests an overwrite.

UUIDs vs Names

Every asset also has a human-readable name, but names are not unique. They can change freely and are only meant for UI display. The UUID is the only reliable way to identify and reference an asset.

Asset Structure

Each asset in 3dverse is divided into three logical parts. This separation allows the platform to treat lightweight metadata, heavy binary data, and inter-asset references differently, optimizing both performance and storage.

1. Description

The description is a lightweight JSON document that defines the structure and metadata of the asset:

• Contains technical metadata (e.g. buffer layouts, vertex/triangle counts).
• Stores the human-readable name of the asset for UI display.
• Validated against a public JSON schema, ensuring consistency across tools.

Descriptions are compact and self-contained, making them ideal for indexing, search, and fast inspection without touching heavy payloads.

2. Payload

The payload is the heavy binary data required for rendering when applicable:

• Vertex and index buffers for meshes.
• Pixel data for textures.
• Other data depending on the asset type.

Not all assets require a payload — for example, scenes or materials only have descriptions. When present, payloads can be split into sub-resources (such as mipmap levels or segmented buffers). This enables priority-based streaming: critical data can be loaded first to get to rendering quickly, with additional details streamed later.

3. Dependencies

Assets can reference other assets. These references are always stored as UUIDs in the description and are enforced by the platform:

• A Material may depend on one or more Texture assets.
• A Scene may depend on multiple Mesh and Material assets.

Because dependencies are tracked at the platform level, they cannot be broken. If an asset is still referenced, the platform will refuse to delete it until the dependency is removed.

---

Asset Structure at a Glance

• Description — lightweight JSON metadata, schema-validated, fast to query.
• Payload — heavyweight binary data, split into sub-resources for streaming.
• Dependencies — UUID-based references to other assets, enforced by the platform.

Assets in the Platform

All assets in 3dverse are stored and managed by the platform. The platform is the single authority responsible for keeping them secure, consistent, and available.

Because assets are divided into descriptions, payloads, and dependencies, each part can be handled in the backend that suits it best. This separation is invisible to developers: the platform ensures assets are always retrieved, validated, and streamed efficiently, without requiring applications to know where or how they are stored.

• Descriptions — stored in a document database, making metadata easy to query and validate at scale.
• Payloads — kept in blob storage, where large binary data can be streamed on demand without blocking other operations.
• Dependencies — tracked globally in a graph database, ensuring that references across assets remain valid and unbroken.

This design allows tools and applications to load only what they need: dependencies are resolved instantly, descriptions can be queried independently, and heavy payloads are streamed just-in-time when rendering requires them.

The platform abstracts this complexity away, ensuring that every asset behaves as a reliable, reusable building block.

Asset Maintenance

Because assets live entirely in the platform, maintaining and evolving them is straightforward. Patching an asset is simply an update to its description or payload, while keeping the same UUID. All references — across sessions, scenes, or applications — remain valid automatically.

This stands in contrast to traditional engines where upgrading projects from one version to another often requires manual re-imports, broken references, or large-scale migrations. In 3dverse, updates are seamless: the platform ensures that assets remain compatible and consistent across versions, making long-term maintenance and iteration far less painful.

Rethinking Assets

Thinking of assets as files ties them to fragile storage and local projects. 3dverse rethinks this model: assets are persistent objects in a shared platform, designed to stay consistent and valid regardless of how they’re used.

	Traditional Engines	Web-Based Frameworks	3dverse
Identity	File path or project-local ID	File path or URL	Global UUIDs, unique across the entire platform
Storage	Files on disk or in project packages	Files served from the web	Split across backends: graph (dependencies), document (JSON), blob (payloads)
Scope	Local to a project	Local to a site or app	Global — reusable across projects, apps, and organizations
Dependencies	File references, can break on rename/delete	URL references, fragile to changes	UUID-based, enforced by the platform
Collaboration	Requires source control or file sharing	Requires syncing assets across clients	Built-in: sessions and apps share the same platform assets
Updates	Replace/reimport files, may break references	Replace files manually	Update or replace while keeping the same UUID
Deletion Safety	Manual; risk of dangling references	Manual; risk of broken links	Safe: platform blocks deletion while an asset is referenced

This design makes 3dverse assets persistent, secure, and collaboration-ready by default, without the need for manual file management or external source control.

---

With assets defined, the next step is to look at the scene model — where entities and components organize references to assets into a coherent world for sessions.