Closed bertt closed 3 months ago
I have to admit the prospect of adding draco compression is not very good.
I've been thinking a lot about different approaches to support Draco, and this is what I came with:
First and foremost:
Given these considerations, these are the possible solutions I am considering:
For now I am not considering binding the core library to the draco native DLLs.
Things would change dramatically if someone develops a c# implementation of Draco, but I don't see that possibility in the foreseeable future
Finally, although I would love to support Draco, it's way over the available time I have, and I preffer to invest it in other, more useful glTF extensions; I'm waiting for the Universal Basis texture extensions to be final to begin working on them.
So for now I'm afraid the best you can do is to write your glTFs to a temporary directory, and post-process them with the glTF pipeline or some other library able to write draco compressed files.
ok thanks for the explanation! At the moment after glTF/3D Tile creation I do a post process step (using gltf-pipeline) but its not optimal because of the temporary files involved .
At some point, when I have time (very busy right now) I'll look at Andress Attender draco for unity bindings...
@vpenades 2023 now, Draco compression is very necessary.
@pigLoveRabbit520 if you care to read this thread, I already explained the case.
Draco extension requires using Google's Draco compression library which is a very large and very complex C++ project, and the Draco Extension uses that project under the hood.
I don't have enough free time for neither port that draco project to c#, which would literaly take months of work, nor to write bindings and test them on all platforms. If someone takes care of porting the google library to c# I would be glad to support the extension, otherwise, it's beyond my pay check.
Other users are using gltf-pipeline to pre process or post process gltf's with draco. If you really need draco, I suggest you to use the pipeline to strip draco from the models you want to read before import them.
ok
@vpenades Hey, man!
What if we add an encoding plugin support for your library? I don't know if we have that today. This way, people interested can create a plugin for your library for Draco or any other encoding we have now and in the future.
This way, your code, the Core, will still be 100% C# but you will let people extend your library to satisfy their needs.
For example, I want to use your library today but all models of our company now are using Draco.
For one specific case, if we have a way to read a model without decoding/encoding the texture that would be awesome, because I only need to get the boundaries of some models.
Other users are using gltf-pipeline to pre process or post process gltf's with draco. If you really need draco, I suggest you to use the pipeline to strip draco from the models you want to read before import them.
Yes, that is something that came into my mind as a workaround.
Something came into my mind and I will give it a try because that might solve our problems... Apparently, Draco is being exposed as WASM and, as far as I know, we can run WASM in .NET nowadays. This might be a way to use it without relying on any native library too.
@danfma right now we're in the process to modify the library to make a bit easier to write extensions as third party libraries, but for something like Draco it would also require some entanglement with the loader code, so the buffers can be decompressed on load.
Using WASM is a possible solution, I guess you're referring to the WasmTime project.
In the meantime, it could be reasonably easy to allow the library to load gltf files with draco by completely skipping validation. Of course that would produce an invalid and unusable model, but then, an external code could run an additional post load step over the model, and decompress and fix the draco buffers to make the model usable again.
In the long run, I guess it could be possible to include some interfaces that could be called by extensions on load, to allow this kind of post processing steps to be run after load, but before validation, so compression extensions could have the right hook to work.
For images, there's also a hook to redirect what you want to do with them on load
My time is a bit limited but count on me if you need some help!
Our team would also be interested in this functionality, as we use Draco compressed models primarily as well.
Hi, whats the status of using Draco compression? I see 5-8 times size reduction when using Draco, so ideally would like to enable it when saving to glb file.