In early September 2026, NVIDIA released an update to its open-source vk_lod_clusters sample, a Vulkan demonstration that pairs driver-exposed clustered raytracing with a Nanite-like clustered level-of-detail (LOD) pipeline to stream and display an extremely detailed scene with full pathtracing. The update added a new Zorah scene as a glTF file, and it led Arseny Kapoulkine, author of the meshoptimizer mesh-processing library, to publish a follow-up writeup titled "Billions of triangles redux." The new article focuses less on processing time than his earlier report on the scene and more on compression and other pipeline aspects; reading the earlier article is not required to follow it.

The new Zorah scene scales to roughly 1.6 billion triangles and arrives as a download of about 70 GB. What is most striking is not the download size but the glTF scene data itself: about 32 GB in the 2026 version, versus roughly 36 GB in the 2025 version, despite the overall amount of geometry having changed very little. In contrast, NVIDIA now also provides the original, attribute-less and texture-less version of the scene at just 9 GB, underscoring that the attribute and texture additions were largely what pushed the earlier file toward 36 GB.

The size reduction comes from meshoptimizer compression extensions in the glTF scenes: EXT_meshopt_compression, which exposes vertex and index compression using the older "v0" vertex format, and the newer KHR_meshopt_compression, which uses the upgraded v1 vertex format and was standardized in early 2026. Rather than packaging one mesh at a time, these extensions organize data as arrays of bytes representing vertex or index data, leaving tools free to decide how to split and buffer meshes. The meshoptimizer vertex codec itself is lossless — it reproduces the original byte sequence exactly — but a layer underneath can make it lossy, either via pre-quantized data when glTF accessors support it or via "filters" that trade a little precision for better compression ratios. The Zorah scene, being an intermediate file rather than the final delivery format, uses the lossless option; last-mile delivery would instead use tuned lossy compression to minimize file size.

Kapoulkine reports the following sizes for the scene: raw (decompressed), v0 (what is stored on disk in the downloaded file), and v1 (recompressed with the v1 format):

Category Raw v0 v1 Positions 14.3 GB 9.1 GB (63.5%) 8.9 GB (62.1%) Attributes 30.1 GB 21.6 GB (71.8%) 20.5 GB (68.2%) Indices 18.9 GB 1.9 GB (10.1%) 1.9 GB (10.1%) Total 63.3 GB 32.6 GB (51.5%) 31.3 GB (49.5%)

Index data compresses especially well; positions and attributes compress more modestly. Switching to the v1 vertex format recovers a few extra percentage points and decodes faster.

Why bother compressing an intermediate file? Kapoulkine gives two reasons. First, it cuts the cost of reading the scene from disk: decoding vertex or index data runs at multiple gigabytes per second of output on a single core, decompression takes under 1% of total processing time, runs fully in parallel, and cuts the disk read footprint in half. Second, a mesh-optimized compressor can end up smaller than a general-purpose one. Using Zstandard at level 6 on raw data yields a 38.0 GB file (60.1% of raw), whereas applying Zstandard on top of v1 meshopt compression reaches 27.4 GB (43.3% of raw) — a seemingly paradoxical result. The design point behind it is explicit: meshoptimizer codecs do not reimplement an entire lossless compressor but target features general-purpose compressors often miss, while keeping the output stream friendly to both fast decoding and further post-compression. The original motivation was simply that SSDs were becoming unreasonably fast; when a drive can stream many gigabytes per second, slow but compact compression may not pay off at all, and the layered approach lets a publisher pick the underlying codec (LZMA, Zstandard, and so on) without touching the mesh layer.

On the processing side, the pipeline largely mirrors the prior writeup: split the input mesh into clusters, partition clusters into groups, simplify each group while preserving the boundary, split the new group into more clusters, and repeat. On the runtime side, clusterlod.h now provides clodBuildHierarchy, which builds a BVH over the cluster DAG to quickly select the clusters at the correct level of fidelity, as described in the original Nanite presentation. Because the scene now carries attributes, attribute-aware simplification via meshopt_simplifyWithAttributes is used: each attribute receives a scalar weight according to how much it changes the surface appearance, so the simplifier's error metric reflects the full visual result.

Recent changes to clusterlod.h improve spatial coherence and simplification robustness. The partition_sort option orders partitions by Morton order, making the DAG more spatially coherent and helping streaming locality; meshopt_buildMeshletsSpatial is faster thanks to strategically placed prefetches; and meshopt_partitionClusters has improved over recent releases. Permissive mode, enabled with the meshopt_SimplifyPermissive flag, has been refined and marked stable: it waives most topological restrictions so that meshes rich in seams do not stall the simplifier — a problem for hierarchical LOD schemes that rely on simplifying high-detail source meshes down to a single cluster — and attribute error can now be clamped to avoid overly pessimistic LOD selection. When permissive mode is used, attributes with discontinuities should be passed to the simplifier for attribute-based weighting, and LOD selection should rely on the computed output error rather than a fixed triangle budget; Zorah does not use selective discontinuity protection. On the Zorah scene, the low-quality "sloppy" fallback is now taken for about 0.01% of simplified groups, which the author considers benign.

The writeup notes testing on a GeForce RTX 5070 with 12 GB of VRAM and includes an appendix covering lossy compression tuning for last-mile delivery scenarios.