Draco #10879
Draco #10879
Conversation
examples/js/loaders/DRACOLoader.js
Outdated
| this.materials = null; | ||
| }; | ||
|
|
||
| const DracoModule = Module; |
There was a problem hiding this comment.
Hmm... how does this work? draco_decoder.js adds a variable called Module to the global scope?
There was a problem hiding this comment.
Ah, yes I spotted that. Not ideal... I copied this from Google's DRACO threejs renderer example: https://storage.googleapis.com/demos.webmproject.org/draco/draco_loader_throw.html
It looks like Module is an artifact of their emscripten process for draco_decoder.js
There was a problem hiding this comment.
Hmm... I could just merge this, but I know people are going to run into problems with this so I would prefer if we can fix it before merging...
Ideally the original authors would clean that up. So, maybe you can point this out at https://github.com/google/draco?
Or... they could also "move" the loader to this repo and maintain the loader here.
There was a problem hiding this comment.
It looks like this library is built with Emscripten, which is where the global Module variable is coming from. Emscripten supports a couple arguments at compile time which lets you provide proper namespaced modules for compiled code.
The arguments you want would be something like -s MODULARIZE=1 -s EXPORT_NAME="'DRACO'" which will create the module definition in window.DRACO instead of window.Module.
|
We updated Draco with the requests from this ticket: google/draco#68 How should we proceed from here? |
|
@edsilv do you mind updating this PR with the updated draco? |
|
@mrdoob That's done. |
|
Sweet! Do you mind adding an example too? |
|
I have an example on the dev branch here: https://github.com/edsilv/virtex I could look at adding this to the three.js examples directory. Currently it loses the texture when compressing with DRACO. I also had to remove references to |
|
@edsilv Draco does not store any material info, but textures or material can be still loaded separately, e.g., you can still load the obj .mtl file and use it with a mesh loaded with Draco. When .obj is encoded to .drc, Draco actually preserves material ids in a generic attribute that could be used to map multiple materials to an object. We have plans to add support for metadata to our encoded file that would allow storing of arbitrary data inside the .drc file and this feature could be potentially used to store material info as well. Personally I think it is ok to go ahead with an example without textures as it should be pretty straightforward to add material or texture loading separately from Draco decoding. |
|
@edsilv |
examples/js/loaders/DRACOLoader.js
Outdated
| dracoDecoder.POSITION); | ||
| if (posAttId == -1) { | ||
| const errorMsg = "No position attribute found in the mesh."; | ||
| //fileDisplayArea.innerText = errorMsg; |
There was a problem hiding this comment.
Do you mind pulling again from draco?
They've removed the html element dependencies: google/draco#68
|
Thanks! |
|
Since v85 now ships with the dracoloader, I've tried implementing it. My .obj model has subgroups that got traversed on load (with the old objloader), but when pushed through the .drc and the dracoloader this information seems to be lost and it can't be traversed. I've tried searching for a solution, but there's not much draco specific discussion out there yet, that is why i came here to ask for help. Can groups be stored in the .drc format or does the format not support that? My understanding was that the draco format merely compresses an underlying .obj, instead of altering it. |
|
@stefan-kern Draco is actually converting the input .obj into an intermediate representation that is compressed, so some information can get lost. Subgroups (defined by the |
Added DRACOLoader.js and draco_decoder.js