Antony Adhiban
OptimizeGLB engineering
7 min read
Large-model processing
Compressing large GLB files in the browser
OptimizeGLB can process GLB and glTF assets measured in hundreds of megabytes without uploading the model. The useful limit is not a number on a file picker; it is the amount of working memory the browser needs to finish the job.
A large GLB is not simply a larger upload. Before an optimizer can write a smaller file, it may need to hold decoded textures, mesh attributes, indices, and several intermediate buffers at once.
That distinction matters because file size on disk is a poor proxy for peak memory. Two 700 MB models can behave very differently: one might contain a few large meshes; the other might be dominated by high-resolution textures, animation data, or thousands of small objects. A credible large-file workflow has to survive the complete path—not just accept the selection.
Browser compression path
The file is only the starting allocation
Processing stays on the device
- 01
Read
Source container
- 02
Parse
Scene and resources
- 03
Transform
Geometry and textures
- 04
Encode
Draco and output buffers
- 05
Inspect
Original and result
Several stages can coexist in memory. Decoded textures and geometry buffers may be much larger than their compressed representation inside the GLB container.
Practical limitPeak working set
The result we validated
In an end-to-end browser run, OptimizeGLB read a 783.56 MB GLB, applied Draco geometry compression, rendered the result for comparison, and produced a 99.76 MB download. The workflow completed locally; the model was not sent to a compression server.
Browser test · Draco enabled
87.3%
smaller in this run
This establishes that an 800 MB-class asset can complete the workflow. It does not establish a universal maximum, and it does not promise an 87.3% reduction for every model. Geometry topology, texture payloads, animations, enabled transforms, and available memory determine the outcome.
The difficult part can be one primitive, not the whole file
A model may be within the browser's overall memory budget and still fail during Draco encoding. The pressure can come from one mesh primitive whose vertex or index data is too large to encode safely in a single operation.
OptimizeGLB now divides such primitives into bounded, triangle-safe pieces before encoding, then writes those pieces back into the same scene. The visible geometry is preserved, while the encoder works on smaller inputs. The tradeoff is that splitting can add draw calls, so the downloaded model should still be profiled in its target runtime.
| Constraint | Why it matters | Practical response |
|---|---|---|
| Browser working memory | The source, decoded resources, intermediate buffers, and output can overlap in memory. | Use a current 64-bit desktop browser and close memory-heavy tabs. |
| One oversized primitive | A single vertex or index buffer can exceed what the Draco encoder can safely process in one operation. | OptimizeGLB divides the primitive into bounded, triangle-safe pieces before encoding. |
| Large textures | Compressed image bytes can expand substantially when decoded for conversion and preview. | Treat texture dimensions and formats as a separate optimization decision. |
| Runtime compatibility | Draco makes geometry smaller, but the destination loader must decode the extension. | Validate the downloaded file in the same viewer or engine used in production. |
| Additional draw calls | Splitting an unusually large primitive can exchange one encoding bottleneck for more runtime work. | Inspect visual fidelity and profile rendering performance in the target scene. |
Draco output uses the KHR_draco_mesh_compression extension. See the Khronos extension specification for decoder requirements.
A workflow that catches expensive failures early
Large assets reward a staged approach. Confirm that the source is healthy before asking the browser to do the most memory-intensive work.
- 01
Establish a clean baseline
Open the source with the Compatible preset first. This separates parsing or rendering problems from codec-specific problems.
- 02
Add geometry compression deliberately
Enable Draco only when the target runtime supports KHR_draco_mesh_compression. Geometry savings are not useful if the production loader cannot decode them.
- 03
Tune textures independently
Texture resolution and format often dominate both memory use and visual change. Adjust them after the geometry path is known to work.
- 04
Compare before downloading
Use the original and optimized views to check framing, materials, silhouettes, and fine geometry before accepting the result.
- 05
Test the actual deliverable
Load the downloaded GLB in the destination application. Browser comparison catches visual regressions; production testing catches decoder and performance constraints.
What large-file support should mean
It should mean that the entire job can finish: parse, transform, encode, inspect, and download. It should also describe the boundary honestly. OptimizeGLB supports models measured in hundreds of megabytes and has completed the 783.56 MB test above. The ceiling for a different file remains a property of that model, the selected transforms, and the machine running them.
- Established
- A 783.56 MB GLB completed local Draco compression and produced a 99.76 MB result.
- Not universal
- The same size ceiling or compression ratio cannot be guaranteed for every model and device.
Questions about large GLB compression
Can OptimizeGLB compress GLB files larger than 500 MB?
Yes. OptimizeGLB has completed an end-to-end browser test with a 783.56 MB GLB. The practical limit still depends on available browser memory, model structure, texture sizes, and the selected compression options.
Is there a fixed maximum GLB file size?
No fixed service-side upload limit applies because model compression runs locally. The practical ceiling is set by your browser and device memory, and a model can need considerably more working memory than its file size on disk.
Can Draco compression be used on very large GLB files?
Yes. When necessary, OptimizeGLB divides an oversized mesh primitive into bounded, triangle-safe pieces before Draco encoding. Your target application must support the KHR_draco_mesh_compression extension.
Are large model files uploaded to OptimizeGLB?
No. The model stays on your device while it is parsed, transformed, compared, and downloaded. Support text, contact details, and screenshots are sent only when you explicitly submit the support form.
Why can a large GLB still run out of memory?
The browser may hold decoded textures, mesh attributes, indices, intermediate buffers, and the output at the same time. Scene structure and peak working memory matter as much as the source file size.