Draco is spatially-aware and configurably lossy, so the compression ratio will be better than gzip for geometry-heavy models. Decompression does take longer, though, so that is a tradeoff. Related: DRACOLoader: Web Worker support by donmccurdy · Pull Request #15249 · mrdoob/three.js · GitHub.
So I made this little tool.
https://www.titansoftime.com/draco.html
It seems for my purposes DRACO take a bit too long to decode. Since the assets get cached anyway, return users would have to deal with that decode time and not receive much benefit after initial load.
Seems like this would be most beneficial in a mostly non dynamic object viewer type situation with large mesh files, probably not best for games.
Oh well, still super cool. Legendary level compression.
1 Like
There seems to be a memory leak when using Draco.
When not using Draco, I reloaded my scene objects about 100 times and my memory went up by 0.4MB (some internal arrays).
I did the same using Draco and my memory usage went up by 17MB. The culprit here was the system ArrayBuffer. Does the DRACOLoader need to be disposed in some way?
This is reproducible in the link I posted above.
Edit: Seems it just shoots up to 25MB and stays there. Not a huge deal I guess.
About the memory use, see THREE.DRACOLoader.releaseDecoderModule(); (and https://github.com/google/draco/issues/349).
1 Like
Thanks for sharing the results.
Is this done using the Javascript or WebAssembly decoder ?
Right now, I am loading my scene as a zip file, and using THREE.ZipLoadingManager and it is cutting the file size down by about half, and it works great. The only thing I noticed is there is a second or two of really intense CPU activity, and everything freezes. Is draco any better, in that regard? If I understand correctly, draco won’t handle the texture data, only the mesh.
@Hyacinth Draco should give you significantly better compression on the geometry than ZIP compression. The decoding time is still nontrivial, but I don’t know if it will be more or less in your case. You may want to try to keep your textures out of the ZIP archive, they don’t usually tend to benefit from that sort of compression much.
We have a work-in-progress version of THREE.DRACOLoader that runs in a Web Worker, so (1) it can decode multiple models, or parts of a single model, in parallel, and (2) it doesn’t block the main thread: https://github.com/mrdoob/three.js/pull/15249
You could also do your ZIP decompression in a web worker, but I don’t have an example of that handy.
Finally, you may want to consider the new Basis texture compression library, which will significantly decrease the amount of time your application freezes during texture GPU upload.
1 Like
Wow, thank you. I will look into Draco then. And look forward to any new developments you guys make. Right now, the scenes I am loading are not very large. But I am modelling this world after OpenSim and Secondlife, where a region full of stuff can be up to a GB of data. So when the scenes start getting that large, I really need to think through loading it in stages, so your base scene loads first, so you can walk around. Then it overlays details on top of it without really freezing up. Though I think pressuring people to make better design choices will help too. 
Hi @Mugen87,
Thanks for your suggestion, I am new with glTF Loader and also try to reduce size of my model using gltf-pipeline.
My original file is 43.4MB, but when I do:
gltf-pipeline -i MyModel.glb -o modelDraco.gltf -d
and the new file is made with 51.3MB in size.
The other option to do is:
gltf-pipeline -i MyModel.glb -o model.gltf
But the new file is 57.9MB in size.
Am I doing anything wrong? 
Thanks,
You’ll want to keep it as a binary .glb file.
gltf-pipeline -i MyModel.glb -o modelDraco.glb -d
1 Like
Wow, great!
Thanks @looeee
Now I got 38.4MB in size. happy_face
But from 43.4MB down to 38.4MB, is it possible to reduce more? 
use
gltf-pipeline -i MyModel.glb -o modelDraco.glb -d --draco.quantizePositionBits 11 --draco.quantizeNormalBits 8 --draco.quantizeTexcoordBits 10 --draco.quantizeColorBits 8 --draco.quantizeGenericBits 8
Those are the new default quantize settings from draco.
If you still dont get favorable compression, try loading your model into blender and export it in blender to a glb file with compression using blender’s default compression settings.
thanks for the Blender tip! My draco compression using gltf-pipeline resulted in clearly visible losses. Blender default compression settings worked well and I got a 16% compression