Just saw this on twitter:
I don’t know what it would take to apply it to JME meshes for a smaller storage format or anything. I just thought it looked interesting.
2 Likes
Dude, is that comparison chart for realz? That’s like 3500% file size reduction over the uncompressed one.
That looks awesome.
Cool, but it looks like it’s only for C++ and JS out of the box.
Though the main interest to compress a mesh is basically when you have to send it over the network… you have to uncompress it anyway when rendering.
Ok it would make smaller j3o files… could be nice, but is it worth the hassle to translate from C++ to java?
From what I could understand we do not need to translate it to java. It has a encoder/decoder in C++ which
draco_encoder will read OBJ or PLY files as input, and output Draco-encoded files. We have included Stanford’s Bunny mesh for testing. The basic command line looks like this:
./draco_encoder -i testdata/bun_zipper.ply -o out.drc
draco_decoder will read Draco files as input, and output OBJ or PLY files. The basic command line looks like this:
./draco_decoder -i in.drc -o out.obj
It might be that we just need a thin JNI wrapper for calling decoder from java ??
And anyway, if I were to write it in Java then I think I’d start from the JS version and not the C version, personally.
…then contribute it back to their project.
Edit: note, I’m not saying I am going to do it… just that’s the way I’d do it if I did. My main game doesn’t have much use for it, anyway, though perhaps some of the techniques might be transferable.
yeah but only the decode is in javascript from what I get. I guess it’s easy to reverse. Or… maybe it’s not needed and we could just have the decode and use the encode in command line with gradle…
Another interesting paper for fellow ‘voxel-heads’… didn’t think it was worth a whole different thread for, though…
High Resolution Sparse Voxel DAGs:
http://www.cse.chalmers.se/~uffe/HighResolutionSparseVoxelDAGs.pdf
1 Like
If it only supports OBJ and PLY files, then animations are not supported.
This is a huge limitation.
I think that’s a little bit of an over-statement. Static objects make up a huge quantity of most scenes, and wind for example in the case of vegetation is done in the shader. It’s still a huge saving.
Yes, I think.
In this discussion Support for other 3D file formats? on github page some peoples were suggesting for supporting other 3d formats like FBX , DAE and assimp and some others were against to mess it with other formats and suggesting to concentrate on only mesh compression rather than handling scene graphs.
We will see what they will come up with in the future.
I am looking forward to this though, this can be a very helpful tool for me because I am exporting my LOD meshes along with the main mesh from blender and this cause my final j3os go double or triple in size and consequently big download size and more load time.
Yes, you are right. I just have to remember one of my early project with a few million-vertex-trees.
I think, it might even be possible to compress animation as well: encode the bone weights as extra texture coordinates and store the skeleton+animation in a separate file.