I’ve been playing around with GLTF and Draco compression and it works really amazing so far (90% size reduction on my models).
I noticed that animations aren’t compressed though. I’m using gltf-pipeline for the compressions, perhaps the tool doesn’t support animations or does Draco just not compress any animations?
I see that the official Draco repo has “Draco Animation” in v1.3.4. So I’m guessing the issue is with gltf-pipeline.
Any alternatives to gltf-pipeline for draco animation compressions?
Wow, thanks for recommending meshoptimizer/gltfpack.
It almost seems surreal since the asset size is cut down by half and its now 4x faster to load when compared to Draco.
Why is Draco a thing if meshoptimizer/gltfpack produces both smaller files and faster load times? And why doesn’t ThreeJS have the meshoptimizer loader integrated in the lib instead of Draco?
It seems like there are only advantages from the results I’m seeing. Perhaps I’m missing something…
–
P.S. These are my results for the asset size and load time (Loader.load()):
Thanks for sharing your results! Always good to see numbers.
Just to confirm here — what options are you enabling with gltfpack?
Many of gltfpack’s optimizations (excluding the -c compression flag) are already compatible with three.js. But that compression option requires a custom version of GLTFLoader, because it’s still just a proposal for the glTF format. In the meantime you’ll see “UNSUPPORTED_EXTENSION” or something like that on the official glTF validator: glTF Validator
Of course you’re free to use it in the meantime, but it won’t be supported by most glTF tools unless/until it becomes approved as part of the standard. See https://github.com/KhronosGroup/glTF/pull/1702.
Generally speaking, Draco can compress geometry smaller than gltfpack does, but (1) decoding takes longer and (2) animation isn’t currently supported. So that’s a tradeoff, although in your example it seems to work out well. It’s possible that Draco’s animation compression would be added to the glTF spec in the future too, I’m not sure.
Ah gotcha, that makes sense since my model seems to scale (in both size and load time) with animations. I’m indeed only using the -c flag with the custom GLTFLoader
I went ahead and did 2 more tests:
Environment, 18k tris, no rig/animations, no textures
Subsurfed my previously tested model, 268k tris, removed the rig/animations
It does seem like Draco compresses better for higher poly models, and I imagine it would perform even better as the poly count increases. The size reduction is almost insignificant for ~20k tris models when compared to MeshOpt (MeshOpt has smaller .gz too). However, the loading time seems to be really long though, and I guess that’s the main trade-off.
Based on these results, it seems that:
Draco: smallest model size, but slow loading time
Good for high poly models with no animations and don’t care about loading time
E.g. big environments, architectural models, sculpts, etc
MeshOpt: small-ish model size, but fast loading time
Good for low-mid poly models with animations, needing fast load times
E.g. game characters, props, animated models
If the MeshOpt extension is approved, it could be useful for ThreeJS to use it to have that missing middle-ground between Raw GLB and Draco.
I’m using Blender 2.8.2 to export the FBX, and it seems to be in binary format by default (not entirely sure).
The loading time for FBX is really high for some reason. It also seems like FBX’s loading time scales a lot with animations, and not so much the mesh (see the 268k tris example).
Also, the FBX file is significantly smaller in size compared to the raw GLB one (for the 268k tris example). Not sure why that’s the case.
P.S. There’s an error in my first image, it showed 19320s for FBX, but its actually 19320ms = 19.3s
The reason I asked is that dropping from 12mb to 3mb when gzipped seems unlikely for a binary file. As you can see in the second set of tests, the 7.8mb fbx only drops to 7.32mb gzipped. That’s what I would expect from binary.
In any case, binary or not, gltfpack is the clear winner here in terms of tradeoff between file size and load times.
@donmccurdy are there any potential negatives to using gltfpack? I guess it’s doing some lossy compression?
I double-checked, 12MB binary FBX gzipped into 3MB. That is indeed really weird. I’m suspecting its the quick animations I made, many are copies of each other, so its really just ~4s anims but copied 10 times for a total of 40s. Maybe that might skew the tests, as there wouldn’t be any identical anims in a real situation.
It’s not lossless compression (neither is Draco) so you might have to fiddle with settings a bit to get the right balance of results. For a complex scene with multiple meshes and varying levels of detail, there might not be a single ideal quality setting for the whole scene. And the tool is relatively new, so be sure to report bugs if you find them. But all of those things are pretty general limitations to compression/optimization tools, I don’t think there’s anything inherent in gltfpack that stands out as a negative, no.
^Well, and none of these tools will affect your textures or draw call count.
Bingo @donmccurdy: I was going to mention the texture issue and draw count. @Droopie: right on the money. Draco is best for super high triangle count. (Scans etc.)
We’ve been benchmarking a lot on our side but stayed away from Draco because our biggest goal is to enable high quality textures in huge scenes… which has been the limiting factor. Webgl seems really good about drawing triangles. @donmccurdy: are we on the same page? Am I missing something?
That sounds right. It’s not uncommon — most of what you’ll find on Sketchfab, for example — for textures to be much larger than the geometry. Often those models have textures that are larger than they need to be, or various texture-specific compression methods can help beyond that.
