How can I stream a 3D model with 100,000,000 triangles?

Every one of these grows with the source. A streaming viewer replaces them with fixed budgets: a triangle count per frame, a byte limit for the cache and a screen-space error target. Those budgets are set per device class and stay the same whether the file behind them holds 20 million triangles or 200 million.

• A multiresolution hierarchy, built offline

  The mesh is cut into small patches of a few thousand triangles, and the patches are merged and simplified level by level into a tree. The top node is a few thousand triangles for the whole model; the leaves are the original data. Every level is stored, so the client can pick any mix of coarse and fine.

• Per-piece compression

  Each patch is compressed on its own so it can be decoded independently. Corto gets textured photogrammetry geometry down to a handful of bytes per triangle, and decoding runs in WebAssembly faster than the network delivers.

• One file, fetched by byte range

  The whole hierarchy sits in one file with an index at the front. The client reads the index, then asks the server for exact byte ranges of the patches it needs. That needs nothing more than a static host that honours HTTP Range requests.

• A client that chooses a cut, not a model

  Every frame, the viewer walks the tree from the top, projects each node’s geometric error to screen pixels, and stops refining where the error drops below a threshold or where the node is outside the view. The result is a cut of one to three million triangles, whatever the source size.

• Bounded caches with eviction

  Decoded patches live in a cache with a hard byte limit. Pieces that leave the view are released after a short grace period. This is what makes the source size irrelevant to the client’s memory.

• Textures that stream the same way

  Each node carries its own texture crop, requested with its geometry. Decoding happens in a worker and uploads to the GPU are spread over frames, otherwise a single large upload freezes movement for a tenth of a second.

The full mesh never exists in the client. The GPU only ever sees a pre-selected batch of a few million triangles.

• First pixels one to two seconds after the link opens, measured on the live site; the first complete coarse view is there within about three. The top of the tree is tiny.
• Per frame one to three million triangles on a desktop, a fraction of that on phones, from a cut chosen at a 2 px error target.
• Client memory bounded by the cache setting: half a gigabyte on phones, a gigabyte or more on laptops, never the file size.
• Bytes per triangle include the textures, which are most of the file. Geometry alone compresses to a few bytes per triangle.

Nexus is the multiresolution toolchain from the Visual Computing Lab at CNR-ISTI, released under a permissive licence, with Corto as its compressor and a JavaScript client that plugs into Three.js. These are the commands and settings we use for our own scans.

1. Condition the source

   One OBJ (or PLY) with its MTL and textures next to it; merge separate parts first. Re-pack textures so each is a power of two if you want mipmaps later. Avoid UV layouts shattered into thousands of tiny islands: they still work, but they bloat the coarse levels and the top node.

2. Build the hierarchy

   nxsbuild scan.obj -o scan.nxs -f 16384 -t 1024 -s 0.5 -r 16000 -w 4 -n -c

   -f triangles per patch (smaller means less popping, more overhead), -t triangles in the top node (smaller means a faster first frame), -s decimation between levels, -r RAM in megabytes to use during the build, -n -c drop per-vertex normals and colours when textures carry the look. Add -k to force power-of-two node textures for mipmaps at a memory cost. Expect hours for 100 million triangles and a file a few times the size of the compressed result.

3. Compress it

   nxscompress scan.nxs -o scan.nxz

   Corto compression, with quantization set as a fraction of each node's own error so coarse levels keep fewer bits. Typically 4 to 15 times smaller than the source geometry plus textures.

4. Check what you built

   nxsedit scan.nxz -i

   Prints triangle and vertex counts, node count and the depth of the tree. The numbers in the table above came from this command.

5. Host it where Range requests work

   curl -sI -H "Range: bytes=0-1023" https://example.org/scans/scan.nxz

   You want HTTP/1.1 206 Partial Content and a Content-Range header. A server that answers 200 with the whole file breaks streaming silently: the viewer appears to load forever. Enable CORS if the page lives on another origin, and set long cache lifetimes, because the file never changes.

6. Load it in Three.js

   <script src="three.min.js"></script>
   <script src="corto.js"></script>
   <script src="nexus.js"></script>
   <script src="nexus_three.js"></script>
   <script>
   var model = new NexusObject('scans/scan.nxz', onLoad, function () { needsRedraw = true; }, renderer, material);
   scene.add(model);
   Nexus.setTargetError(renderer.getContext(), 2);              // screen-space error, pixels
   Nexus.setMaxCacheSize(renderer.getContext(), 1024 * 1024 * 1024); // decoded cache, bytes
   </script>

   The loader asks for the file index, then requests byte ranges as the camera moves. Raise the error target and lower the cache on phones; drop the error target while the camera is still for a sharper picture.

• A server without Range support

  The single most common failure. Nothing errors; the scan just never appears. Test with curl before blaming the viewer.

• Texture uploads that freeze movement

  Uploading one large node texture to the GPU blocks the main thread for 50 to 130 ms, which reads as a hiccup. Decode in a worker, upload in bounded strips over several frames, and only switch to the new texture when it is complete.

• Evicting what you are looking at

  A cache that drops pieces one second after they leave the view re-downloads and re-uploads them the moment you turn around. Keep a grace period and retain the current view's dependencies.

• Non-power-of-two textures

  Without square power-of-two node textures WebGL 1 cannot mipmap, so distant surfaces shimmer. Pad source textures before the build or accept the memory cost of the pow-2 option.

• Fragmented UVs

  Photogrammetry exports often split the surface into thousands of UV islands. Every island needs padding in every node texture, which is what ruins the coarse levels. Fewer, larger charts at the source help more than any viewer setting.

• Build RAM and time

  A 100 M build wants tens of gigabytes of RAM and hours of wall time. Give the builder an explicit RAM budget, plenty of disk for the uncompressed intermediate, and split the source spatially if one build will not finish.

Do I need WebGPU?

No. All the selection logic (tree traversal, error metric, culling, cache eviction, decompression) runs on the CPU in JavaScript and WebAssembly. The GPU only rasterizes the chosen cut, which plain WebGL 1.0 handles on integrated graphics.

Will it work on a phone?

Yes, with smaller budgets: fewer triangles per frame, a larger allowed screen-space error and a cache of about half a gigabyte. Our published scans open on phones from the same file the desktop uses.

Can I host it on ordinary shared hosting or a CDN?

Yes, as long as the server answers Range requests with a 206 response. Apache, nginx, S3, R2 and most CDNs do. Our live site streams its scans from a shared FTP host. If a host cannot do ranges, nxsbuild has a mode that writes every node as its own file instead.

How long does the conversion take?

Minutes for a few million triangles, hours for 100 million. It is a batch job: run it once per scan on a workstation or a server with plenty of RAM and disk, then serve the result forever.

How large will the streamed file be?

Our published scans come to 16 to 27 bytes per triangle including textures, so a 100-million-triangle scan lands around 1.6 to 2.7 GB. Visitors only ever download the parts they look at.

What about the textures?

They are the harder half. The build repacks each node’s texture into its own crop, so textures stream with the geometry. Highly fragmented UV layouts inflate the coarse levels; source textures padded to powers of two allow mipmaps. On the client, decode and upload textures incrementally or movement will stutter.

Is 100 million the limit?

No. The client cost does not grow with the source; only the build time and the file size do. Very large builds are limited by RAM on the build machine, and a source can be split spatially into several files that the viewer loads together.