search

javagl / JglTF

Java libraries related to glTF
MIT License
209 stars 61 forks source link

Draco compression #81

Open ebeaufay opened 1 year ago

ebeaufay commented 1 year ago

Hi,

I'm using your library to produce gltf files followed by a javascript library to draco compress them. It works but it's a bit slow.

Do you have any plan to add draco compression and perhaps even some modern texture compression support in the decoder and encoder?

Emeric

javagl commented 1 year ago

That would be nice.

But Draco, KTX, and most other (more sophisticated) compression libraries are usually not available in Java.

I could just try to compile the C/C++ versions of these libraries and see whether they can be intergrated with java-cpp (and in doubt, I do have some experience with JNI). I once even considered to just "port" Draco to Java. But "it would be nice" is not a strong enough reason for me to tackle that right now.

"Pull requests welcome", as they say...

ebeaufay commented 1 year ago

😅 I see, I was thinking of doing the jni bridge too but it's also kind of a nice to have. My workaround could be blocking in the future so I'll consider the PR here.

javagl commented 1 year ago

More broadly speaking: There are many extensions that are not really "supported" by JglTF. There are some experiments in jgltf-impl-v2-ext-... projects, but these are only drafts and not part of a release. And by "supported" I mean that you can obtain the extensions["FOO"] objects and operate on them. But there are no "convenience layers" (in form of ...Model classes) on top of that.

Some extensions could be relatively easy to support. But it's a certain burden to design a sensible abstraction layer on some of them, and for others (like Draco) the abstraction layer could be thin (nearly non-existent), but the the implementation of the actual functionality can be non-trivial.

I mentioned some options (1. using JNI in some form, and 2. porting the existing Draco code to Java). But the most desirable would actually be option 3: To look at the actual Draco bistream spec, and implement it from scratch, only based on the specification. This is the most effort, but I think that it would be "good" in many ways: Having multiple independent implementations is crucial for having a standard that does not turn into a "one-vendor-monoculture"...

ebeaufay commented 1 year ago

The Draco spec isn't small and I think a deep understanding of the spec would be needed to implement this from scratch.

Porting the code to java however seems fairly straightforward and it could be the first step towards a good understanding of the library and a re-implementation.

I would love to have a java draco compression lib but I'm still going to wait until my workaround becomes blocking before I really consider this.