Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
We made an extension for using Google Draco geometry compression library with glTF. It could also be easily extended to more compression libraries if it suits well to glTF 2.0.
Let us know if there is any flaws in the design. Thank you very much.
We also provide an alternative approach in the appendix in case anyone is interested in discussing it.
Having just recently added morph targets to my glTF generation, I'm suddenly noticing that they're absent from Draco considerations. It's likely out of scope and in any case too late to add this to the initial release of the extension, but may I join @donmccurdy in advocating for its usefulness?
Sparse accessors salvage morph targets from extreme bloat, but they're still likely to take up a disproportionate amount of space when all the other static geometry has been compressed.
As a corollary, I know the Draco team is at least thinking about the temporaral dimensions viz. animations, and so it's worth noticing here that the 'weights' target for animations is likely very compressible.
This is probably too close to final, as you said, but even if it weren't — if we added support for morph targets with the Draco format as it is now, I assume each target would need to be treated as a separate mesh by the decoder. This would limit the performance benefit, compared to using a temporal dimension per the long-term roadmap.
So let's give feedback on the use cases in the Draco repository (say, google/draco#126) and consider bringing Draco-compressed morph targets to glTF as an official
In the meantime it would certainly be possible to use vendor extensions for short-term needs.
For our use-case (physics-based simulations) we are very interested in animations, hence I created a proof-of-concept implementation of adding morph targets to this extension. It is actually pretty simple, the attributes within
Please see the simple additions I propose to add support for morph targets in the extension text and json schema in 13c1d79.
To demonstrate the usefulness of this feature, you can have a look at :
(you can use
Note that one of the reason why supporting this feature can be simple is by refactoring
Great comments, thanks @JeremieA!
I'll leave aside the question of whether it is too late in the process — I suspect that is so, but would defer to others. Noticing that you've used a
These changes for implementation within
The restriction on accessor IDs looks reasonable to me... is it considered OK for an extension to narrow the core spec when in use? I'm inclined to say this should be an implementation note, which we could still add after the extension is finished... This also buys me some time to work on implementation: I've been meaning to try to get DRACOLoader running in a Web Worker, with multiple workers in parallel for multiple meshes, which might get around the question of preprocessing.
This was referenced
Dec 23, 2017
referenced this pull request
Jan 29, 2018
About unique IDs on accessors — the pending three.js implementation does not require unique IDs, but I am fine with including the restriction in some form. Morph targets will be left for a future version of the extension (or new, separate extension, TBD) covering animation, and should be omitted from the proposed text.
A question about implications — suppose my model has three (3) compressed meshes, and each mesh is identical except for an application-specific attribute (say,
a. Duplicate all compressed data for each mesh, in a new Draco-compressed bufferView.
If I understand correctly, (a) and (b) are fine, but (c) would be disallowed with this requirement.
Congrats on the official launch of this extension !
I will update my tools to reflect the final standard (disabling the morph targets support by default).
Regarding the attributes from multiple mesh instances, option (b) is what I implemented in my compressor (see here). All primitives sharing the same indices and positions data are compressed as a single Draco-compressed mesh, as I assumed that it would be most efficient. While testing this compression on various glTF assets, I did not notice this case of two primitives using different attributes while referring to the same positions and indices. I suspect most exporters would duplicate all attributes in this case. But I know of at least
Sorry @donmccurdy for not answering your earlier questions. The ZIP export that I implemented was done as a completely separate code from