AMD DGF and DGFS: GPU Geometry Compression Explained

AMD DGF and DGFS: GPU Geometry Compression Explained

Modern graphics workloads are running into a problem that raw GPU compute performance cannot solve on its own: geometry data is becoming increasingly expensive to store, move, decompress, and prepare for rendering.

As game engines push toward film-quality geometric detail, traditional vertex and index buffers create growing demands on VRAM bandwidth, storage capacity, and ray tracing acceleration structure construction.

AMD’s answer is Dense Geometry Format (DGF), a hardware-oriented geometry representation designed around compact, fixed-size blocks. Its companion technology, DGF SuperCompression (DGFS), adds another compression stage to reduce the amount of geometry data stored in game assets.

The two technologies address different parts of the graphics pipeline:

• DGF defines a compact geometry format designed for efficient GPU consumption and ray tracing.
• DGFS compresses DGF data further for storage, distribution, and cross-device compatibility.

Together, they represent an attempt to bring the benefits of modern texture compression formats to triangle geometry.

There is an important distinction, though: DGF is not simply another mesh compression algorithm, and DGFS is not a new hardware decompression format. Understanding how the two fit into the graphics pipeline explains why AMD is investing in them and what they could mean for future GPU architectures.

🚀 Why Geometry Compression Matters

#

Modern game engines increasingly depend on extremely detailed geometry.

Common rendering workloads include:

• High-density polygon meshes.
• Nanite-style virtualized geometry systems.
• Hardware-accelerated ray tracing.
• Large open-world asset streaming.
• Detailed character animation.
• Real-time global illumination.
• Procedurally generated environments.

As triangle counts reach hundreds of millions or more across a scene, geometry data becomes a significant consumer of memory bandwidth and storage capacity.

Traditional GPU pipelines were designed around conventional vertex and index buffers. These representations work well, but they are not necessarily efficient for the increasingly dense geometry used in modern rendering.

The Growing Geometry Bottleneck

#

Several related bottlenecks emerge as geometric complexity increases.

Ray tracing makes the problem particularly visible.

Rasterization can process geometry through dedicated vertex and rasterization pipelines, but hardware ray tracing also needs an acceleration structure, usually a Bounding Volume Hierarchy (BVH), to organize geometry for efficient intersection testing.

This creates additional memory and processing requirements.

In conventional rendering pipelines, geometry may need to be decoded, reorganized, and converted into hardware-specific acceleration structures before the GPU can use it efficiently.

AMD DGF targets this gap by making compressed geometry more suitable for direct hardware consumption.

🧩 Understanding DGF: Dense Geometry Format

#

DGF is a block-based geometry compression format developed by AMD.

Instead of storing a large mesh as a conventional collection of vertex and index buffers, DGF partitions the geometry into small, spatially localized triangle clusters called meshlets.

Each meshlet is encoded into a compact, fixed-size block.

Core DGF Characteristics

#

The fundamental DGF block has the following properties:

The 128-byte block size is particularly significant.

DGF is designed so that the information required to retrieve a triangle can be accessed through a single 128-byte-aligned memory read.

This is a hardware-oriented design decision.

Rather than requiring numerous unrelated memory accesses to reconstruct triangle data, the format groups the relevant information into a predictable cache-aligned structure.

The result is a geometry representation designed around GPU memory transactions rather than conventional asset interchange requirements.

Understanding the DGF Block Layout

#

A DGF block contains three primary sections:

1. Header.
2. Geometry data.
3. Topology data.

The header contains information required to interpret the block, including vertex-position encoding parameters and metadata.

The geometry section stores compressed vertex positions.

The topology section encodes triangle connectivity using a compact representation inspired by generalized triangle strips.

Optional metadata, such as geometry identifiers, can also be stored.

This arrangement minimizes unnecessary storage while retaining the information required to reconstruct individual triangles.

Vertex Position Compression

#

DGF does not store every vertex as three conventional floating-point coordinates.

Instead, it uses a local coordinate representation.

Each block stores an anchor position for its geometry. Individual vertices are represented using quantized offsets relative to that anchor.

Conceptually:

Where:

• \(P_i\) is the reconstructed vertex position.
• \(A\) is the block’s anchor position.
• \(O_i\) is the quantized vertex offset.
• \(E\) is the block’s encoded scale exponent.

The anchor coordinates use signed 24-bit integer values, while the vertex offsets use variable-width unsigned integers.

Each coordinate component can use between 1 and 16 bits.

The exponent determines the scale required to reconstruct the final floating-point position.

This approach takes advantage of an important property of mesh geometry: vertices within a small spatial cluster are usually close to one another.

By storing local offsets rather than independent full-precision coordinates, DGF significantly reduces the number of bits needed per vertex.

The trade-off is quantization. DGF is a lossy geometry representation relative to the original input mesh, so the encoder must choose suitable precision to avoid visible artifacts and cracks.

Meshlets as the Fundamental Processing Unit

#

Meshlets are small, independently processable geometry clusters.

They have become increasingly relevant to modern rendering architectures because they allow the GPU to work with manageable sections of large meshes rather than processing everything as one monolithic object.

A meshlet-oriented architecture aligns with several modern graphics techniques:

• Mesh shaders.
• GPU-driven rendering.
• Cluster-level culling.
• Virtualized geometry.
• Level-of-detail systems.
• Ray tracing acceleration structures.

DGF takes this model further by defining a standardized, compact representation for these geometry clusters.

The DGF Baker processes an input mesh, partitions it into clusters, and encodes those clusters into 128-byte blocks.

For ray tracing, spatial organization matters as much as compression ratio. AMD’s documentation emphasizes Spatially-Aware Surface Area Heuristic (SAH) clustering to improve acceleration structure quality.

A smaller geometry representation does not automatically produce a faster BVH. Cluster boundaries and spatial distribution still matter.

Why Fixed-Size Blocks Matter for Hardware

#

Fixed-size blocks simplify several aspects of GPU architecture.

First, memory access becomes predictable. Hardware can retrieve a complete block without following a variable-length chain of unrelated geometry records.

Second, the format reduces the complexity of hardware decompression and triangle reconstruction.

Third, the block structure allows geometry to be organized in a way that aligns with cache behavior and ray intersection workloads.

This is particularly useful when a GPU needs to retrieve individual triangles during ray traversal rather than decode an entire mesh.

For the original technical design, see AMD’s research paper, DGF: A Dense, Hardware-Friendly Geometry Format for Lossily Compressing Meshlets with Arbitrary Topologies.

⚙️ DGFS: DGF SuperCompression

#

If DGF defines the hardware-oriented geometry representation, DGFS provides a second compression stage designed primarily for storage and portability.

DGFS stands for DGF SuperCompression.

AMD introduced it as part of the updated DGF SDK in May 2026.

The motivation comes from a limitation in DGF’s original design.

DGF is optimized for hardware access, not minimum file size.

Its fixed 128-byte blocks contain information that must be repeated across blocks, including vertex-position parameters and other metadata. When blocks are not completely filled, alignment requirements can also introduce unused padding bits.

These design choices make DGF efficient for hardware, but they leave room for additional compression when the data is stored on disk.

DGFS addresses that problem.

How DGFS Works

#

DGFS converts DGF geometry into a variable-length compressed byte stream.

Rather than treating every 128-byte DGF block as an independent storage unit, it groups geometry into larger clusters and removes redundant information shared between blocks.

A DGFS cluster can contain up to 256 unique vertices and triangles.

Its encoding includes several transformations.

Vertex De-Duplication

#

One major source of redundancy comes from duplicated vertices across neighboring DGF blocks.

Adjacent meshlets frequently share vertices along their boundaries.

Storing the same vertex information repeatedly increases the total geometry footprint.

DGFS identifies these repeated vertices and stores shared information more efficiently.

This reduces duplication between blocks without changing the resulting DGF geometry.

Delta Encoding

#

DGFS also uses delta encoding for suitable data.

Instead of storing every value independently, it stores differences between related values.

For example:

Absolute values:

• 1000
• 1002
• 1005

Delta values:

• 1000
• +2
• +3

Smaller differences often require fewer bytes than their original absolute values.

DGFS uses this principle for data such as geometry identifiers and other suitable structures.

Zig-Zag Encoding

#

Signed differences can be transformed into unsigned integer values through zig-zag encoding.

This maps small positive and negative values to small unsigned integers, making them more suitable for variable-length encoding.

It is particularly useful when adjacent values tend to have small differences.

Byte Interleaving

#

DGFS also uses byte interleaving to improve the compressibility of the resulting stream.

This rearranges data so that general-purpose compression algorithms can identify more repetitive byte patterns.

These transformations work together to reduce the storage footprint without introducing another geometry-quality reduction stage.

An Important Distinction: DGFS Is Lossless Relative to DGF

#

There are two separate compression stages:

1. DGF compresses the original geometry using quantized vertex positions and compact topology encoding.
2. DGFS compresses the resulting DGF representation further.

The first stage can introduce geometric approximation.

The second stage preserves the exact DGF blocks supplied to it.

In other words, DGFS can reconstruct the original DGF data exactly, but that does not mean the entire DGF-to-DGFS pipeline is lossless relative to the original uncompressed mesh.

This distinction matters when evaluating visual quality.

DGFS does not need to introduce additional geometric quantization to achieve its storage savings.

DGFS Supports Both DGF and Non-DGF Devices

#

Another important design decision is cross-device compatibility.

A DGFS stream can be decoded into either:

• The original DGF block representation.
• A conventional vertex and index buffer.

This allows developers to maintain a common geometry asset format for different hardware generations.

On hardware with native DGF support, the application can reconstruct the DGF blocks.

On hardware without native DGF support, it can decode the same content into conventional geometry buffers.

This resembles the role that Basis Universal plays in texture asset pipelines: a compact storage representation can be transcoded into a format suitable for the target device.

AMD’s implementation and design details are documented in Introducing AMD DGF SuperCompression.

📊 DGFS Compression Results

#

AMD demonstrated DGFS using several high-density geometry models.

The results show that compression efficiency depends on the mesh structure and the amount of redundant information between clusters.

Published Geometry Benchmark

#

The following results compare raw DGF storage with DGFS-compressed data.

The Dragon benchmark is a useful example.

Its DGF representation occupies approximately 29.25 MB. Applying DGFS reduces that to approximately 20.15 MB.

That is a reduction of roughly 31%.

These numbers describe the raw storage footprint of the respective representations.

Results With General-Purpose Compression

#

Game asset packages typically use additional compression.

AMD also compared the results after applying GDeflate to the geometry data.

This is the more relevant comparison for packaged game assets.

The Dragon model drops from 20.15 MB to 15.67 MB after the additional DGFS optimization, even though both versions use GDeflate.

Across these five models, the additional storage savings range from approximately 18.6% to 22.2%.

The exact result depends on mesh topology, shared vertices, geometry identifiers, and the structure of the source data.

What These Savings Mean at Scale

#

Consider an asset package containing 100 GB of geometry data.

A compression improvement of 20% would reduce its size to approximately 80 GB.

That means:

• Lower asset storage requirements.
• Reduced SSD bandwidth demand.
• Less data transferred during downloads and updates.
• Faster geometry delivery under suitable I/O conditions.
• More efficient asset distribution.

The benefit becomes more significant when a game contains large collections of high-density assets.

There is one important caveat: DGFS is primarily a storage and transport optimization. Compressed DGFS streams are decoded before the resulting geometry is consumed as DGF or conventional mesh data.

Its compressed file size should not be confused with the amount of VRAM occupied by the final decoded representation.

🎮 Ray Tracing and BVH Optimization

#

One of DGF’s most important applications is hardware ray tracing.

Modern ray tracing pipelines depend on acceleration structures to reduce the cost of intersection testing.

The most common structure is the Bounding Volume Hierarchy.

Why BVH Construction Becomes Expensive

#

A BVH organizes triangles into a hierarchy of bounding volumes.

When a ray enters a scene, the GPU traverses the hierarchy to determine which triangles are potential intersections.

This avoids testing every triangle individually.

However, building and updating acceleration structures becomes increasingly expensive as geometry complexity increases.

The processing pipeline generally involves:

1. Preparing the input geometry.
2. Organizing triangles into suitable spatial groups.
3. Constructing bounding volumes.
4. Building the acceleration structure.
5. Storing the resulting data in GPU memory.

For dynamic scenes, some of this work may need to be repeated when geometry changes.

As triangle counts grow, both preparation time and memory requirements become increasingly significant.

How DGF Helps

#

DGF is designed to make geometry more suitable for acceleration structure construction and hardware traversal.

Its benefits come from several architectural properties:

• Compact geometry representation.
• Spatially localized triangle clusters.
• Predictable 128-byte memory access.
• Reduced geometry storage overhead.
• Efficient triangle reconstruction.
• Hardware-friendly data organization.

Pre-clustering geometry also reduces the amount of work required to organize arbitrary input triangles at acceleration structure build time.

The Vulkan DGF extension describes how applications can provide pre-compressed DGF geometry when constructing acceleration structures.

This does not eliminate the BVH.

Instead, it changes the representation of the geometry from which the acceleration structure is built.

AMD’s approach aims to reduce the overhead associated with moving and preparing dense geometry for ray tracing.

DGF and Cluster-Level Acceleration Structures

#

DGF should not be confused with Cluster Level Acceleration Structures (CLAS).

They operate at different architectural levels.

DGF defines how triangle geometry is compressed and represented.

CLAS defines an acceleration structure built around a cluster of geometry.

A rendering engine can use DGF blocks as geometry input for acceleration structure construction, including cluster-oriented approaches where supported.

AMD has explicitly described DGF and CLAS as complementary rather than competing technologies.

For a closer look at cluster-level acceleration structures and their role in modern DirectX ray tracing, see DirectX Raytracing Update: CLAS, PTLAS, and 66× Demo Gains.

Why This Matters for Path Tracing

#

Path tracing requires large numbers of ray queries across scene geometry.

Complex lighting, reflections, global illumination, and indirect illumination all increase the importance of efficient acceleration structure management.

When geometry becomes extremely dense, acceleration structure memory and construction overhead can limit the amount of detail that can be supported.

DGF targets this problem by making triangle data more compact and better suited to direct hardware processing.

Potential applications include:

• Real-time path tracing.
• Dynamic geometry.
• High-density virtualized environments.
• Detailed character models.
• Procedural geometry.
• Large-scale real-time global illumination.

The objective is to make detailed geometry more practical for both rasterization and ray tracing, reducing the gap between the geometric detail supported by the two pipelines.

💾 VRAM Efficiency and Future GPU Architectures

#

DGF’s long-term significance extends beyond smaller asset files.

Its hardware-oriented design creates an opportunity to reduce the amount of memory required for active geometry and acceleration structures.

Traditional geometry pipelines often require data to be expanded into conventional vertex and index representations before hardware processing.

DGF is designed to avoid some of that expansion by allowing future GPU architectures to consume the compressed representation directly.

Potential Memory Benefits

#

A simplified comparison illustrates the architectural difference.

The actual memory savings depend on the mesh, acceleration structure implementation, additional vertex attributes, and GPU hardware.

DGF does not compress every GPU resource.

Textures, render targets, shaders, animation buffers, and other application data remain separate memory consumers.

Could a 12 GB GPU Handle Geometry Workloads Designed for 16 GB?

#

DGF could improve the effective geometry budget of a GPU by reducing geometry and acceleration structure memory requirements.

However, it would be inaccurate to claim that a 12 GB GPU automatically becomes equivalent to a 16 GB model.

The usable memory advantage depends on how much of the original VRAM footprint comes from geometry.

For example, a game dominated by large textures may see a much smaller overall benefit than a ray-traced game with extremely dense geometry.

DGF is therefore best understood as a way to improve geometry memory efficiency, not as a general replacement for physical VRAM capacity.

What AMD Has Confirmed About Future GPU Support

#

AMD describes DGF as a hardware-friendly format intended for direct support in future GPU architectures.

That is the key architectural direction.

However, AMD’s public DGF documentation does not identify a specific RDNA generation as the confirmed launch target.

As of November 2026, AMD’s public Radeon architecture overview identifies RDNA 4 as its latest announced graphics architecture. Native RDNA 5 DGF support should therefore be treated as unconfirmed rather than an established product specification.

The current DGF SDK already provides CPU and GPU software decompression paths, allowing developers to experiment with the format across different GPU vendors.

This means developers do not have to wait for native hardware support to begin integrating DGF into their asset pipelines.

The distinction between software support and native hardware support is significant:

• Software decompression allows existing GPUs to process DGF through shader or CPU-based decoding.
• Native hardware support can potentially reduce decompression overhead and allow more direct geometry consumption.
• Hardware-level acceleration depends on the actual GPU architecture and driver implementation.

AMD’s DGF SDK provides the reference implementation and tools for evaluating these workflows.

🕹️ Console Implications: PlayStation 6 and Next-Generation Xbox

#

DGF could also be relevant to future console architectures.

AMD has a long-standing relationship with Sony and Microsoft through semi-custom processor development.

Both platforms face similar graphics constraints:

• Fixed memory pools.
• Limited power and thermal budgets.
• Increasing geometric complexity.
• Higher ray tracing requirements.
• Large open-world asset streaming.
• Growing storage bandwidth demands.

These constraints make geometry compression attractive.

Why Future Consoles Could Benefit

#

A geometry representation optimized for hardware consumption could help console developers allocate memory more efficiently.

Potential advantages include:

• Higher geometric detail within fixed memory budgets.
• Reduced geometry storage requirements.
• More efficient ray tracing acceleration structures.
• Lower asset streaming overhead.
• Better support for virtualized geometry systems.

DGF’s portability also provides an interesting path for multi-generation game development.

A developer could maintain DGFS-compressed assets and decode them into conventional geometry for older hardware while targeting native DGF processing on compatible future platforms.

Native Support Is Still a Separate Question

#

The possibility of DGF being useful for future consoles should not be confused with confirmed hardware support.

AMD has not publicly established that PlayStation 6 or the next-generation Xbox will implement native DGF hardware acceleration.

Console compatibility will depend on the final semi-custom GPU architecture, graphics APIs, driver support, and platform-specific engine integration.

The same distinction applies to claims about RDNA 5.

DGF is clearly designed with future GPU hardware in mind, but its exact adoption across future gaming platforms remains a separate architectural decision.

🔄 DGF vs NVIDIA RTX Mega Geometry

#

AMD and NVIDIA are approaching the dense geometry problem from different architectural directions.

However, comparing DGF directly with NVIDIA RTX Mega Geometry as if both were equivalent compression formats misses an important distinction.

AMD’s DGF Approach

#

AMD focuses on the geometry representation itself.

Its main objectives include:

• Compact triangle storage.
• Fixed-size geometry blocks.
• Meshlet-based processing.
• Reduced memory traffic.
• Hardware-friendly ray tracing data.
• Cross-device geometry asset portability through DGFS.

The central idea is to make the underlying geometry more efficient before it enters the rendering pipeline.

NVIDIA’s RTX Mega Geometry Approach

#

NVIDIA’s RTX Mega Geometry addresses the challenge of rendering extremely dense geometry in hardware ray tracing workloads.

Its focus is on handling high-detail geometry and making ray tracing practical at a much larger geometric scale.

The technologies target related problems, but they operate through different implementations and hardware/software integration strategies.

The Architectural Distinction

#

The two approaches should not be reduced to raw processing power versus compression.

A better comparison is how each ecosystem reduces the cost of representing, preparing, and processing dense geometry.

Geometry compression and acceleration structure optimization are related, but they are not interchangeable.

🏗️ Implications for Game Engines and Asset Pipelines

#

If DGF and DGFS gain widespread adoption, engine developers will need to reconsider how geometry is stored and delivered.

Traditional game asset pipelines commonly follow this general structure:

1. Import source meshes.
2. Optimize vertex and index buffers.
3. Generate mesh LODs.
4. Compress the resulting assets.
5. Stream geometry into GPU memory.
6. Build or update ray tracing acceleration structures.

DGF introduces another possible target representation.

A DGF-Oriented Asset Pipeline

#

A future geometry pipeline could look like this:

1. Import high-resolution source geometry.
2. Partition the mesh into spatially coherent clusters.
3. Optimize cluster topology and triangle ordering.
4. Quantize vertex positions.
5. Encode clusters into 128-byte DGF blocks.
6. Apply DGFS for asset storage.
7. Compress the resulting asset package using a general-purpose compression system.
8. Decode DGFS at runtime.
9. Upload native DGF blocks or conventional geometry according to hardware support.
10. Build the appropriate ray tracing acceleration structures.

This creates a clean separation between asset storage and runtime geometry consumption.

The asset package does not need to store multiple independently maintained versions of the same mesh for every GPU generation.

DGFS can serve as the common storage representation, while runtime decoding selects the appropriate target format.

Sideband Data Requires Special Attention

#

One implementation detail is easy to overlook.

DGF compression can reorder triangles and rotate triangle vertices while preserving winding order.

This matters when an engine stores additional per-triangle information outside the geometry buffer.

Examples include:

• Material identifiers.
• Shader-specific primitive metadata.
• Per-triangle gameplay information.
• External index references.
• Visibility or deformation metadata.

Any sideband data that depends on the original triangle ordering must be remapped to match the compressed representation.

Failing to account for this can produce incorrect material assignments, mismatched metadata, or rendering errors.

The geometry decoder itself may work perfectly while the surrounding asset pipeline produces incorrect results.

Meshlet-Native Rendering Becomes More Attractive

#

DGF also reinforces the trend toward meshlet-native engine architectures.

Instead of viewing a mesh as one large collection of triangles, engines can organize geometry around small clusters that support:

• Independent culling.
• Fine-grained LOD selection.
• Streaming.
• Animation.
• GPU-driven visibility.
• Acceleration structure construction.

This is particularly useful for engines implementing virtualized geometry systems.

The same cluster can become a unit of storage, streaming, visibility processing, and ray tracing preparation.

However, the cluster size and topology must still be selected according to the intended rendering workload. Smaller clusters improve granularity but increase metadata and management overhead.

AMD’s DGF SDK provides a reference implementation of this pipeline, including geometry clustering, compression, CPU/GPU decompression, and sample applications.

🔬 Vulkan Integration and the DGF Ecosystem

#

DGF is not limited to AMD-specific shader code.

AMD has released an open-source SDK and worked with Samsung on a multivendor Vulkan extension for the format.

This is significant because native geometry formats require graphics API support if multiple hardware vendors are expected to implement them consistently.

The VK_AMDX_dense_geometry_format Extension

#

The provisional Vulkan extension VK_AMDX_dense_geometry_format introduces a mechanism for building acceleration structures directly from pre-compressed DGF triangle geometry.

Its stated goals include:

• Reducing acceleration structure construction overhead.
• Reducing geometry storage requirements.
• Lowering acceleration structure memory footprint.
• Making hardware geometry compression more accessible to applications.

The extension also makes the distinction between conventional geometry and DGF explicit in the graphics API.

An application can supply DGF blocks instead of requiring the implementation to reconstruct a conventional mesh and then convert it into a hardware-specific acceleration structure representation.

This can remove unnecessary conversion stages from the pipeline.

The extension remains provisional, so developers should track its specification and implementation status rather than assuming finalized, universal driver support.

The current specification is available in the Vulkan Dense Geometry Format documentation.

SDK Development and Current Capabilities

#

AMD’s DGF SDK has evolved beyond its original research implementation.

The May 2026 v1.2 release added:

• DGF SuperCompression.
• Sample integration with MeshOptimizer clustering.
• Optional internal multithreading.
• Optional post-quantization vertex welding.
• Additional performance improvements and bug fixes.

The SDK also includes CPU libraries, GPU decompression reference code, documentation, and sample tools.

For engine developers, this makes DGF available for experimentation today without requiring a future GPU generation.

The real challenge is integrating it into production asset pipelines and deciding when to use DGF, conventional geometry, or both.

A mature implementation will likely maintain multiple runtime paths until native hardware support and driver availability are widespread.

🔭 The Technical Direction of AMD Geometry Compression

#

DGF and DGFS point toward a broader change in GPU architecture.

Historically, graphics performance improvements have focused heavily on increasing shader throughput, memory bandwidth, and raw rasterization capability.

Those improvements remain necessary, but dense geometry workloads expose another problem: the cost of moving and preparing the data itself.

AMD’s approach addresses that problem through several related mechanisms:

• Fixed-size 128-byte geometry blocks.
• Meshlet-oriented geometry organization.
• Quantized vertex representation.
• Compact triangle topology.
• Cross-block redundancy elimination.
• Additional storage compression through DGFS.
• Direct geometry consumption by future hardware.
• More efficient integration with ray tracing acceleration structures.

For developers, the distinction between DGF and DGFS should remain central to implementation decisions.

DGF is the runtime-oriented geometry representation designed for efficient GPU processing.

DGFS is the storage-oriented compression format designed to reduce the footprint of that representation while preserving exact reconstruction.

As geometric complexity increases, this separation between asset storage, transport, and runtime execution becomes increasingly useful.

The next major engineering challenge is making these representations work efficiently across the complete rendering pipeline, from mesh import and cluster generation to asset streaming, GPU decoding, acceleration structure construction, and ray traversal.