JmeConvert: .glb results in larger .j3o

Troubleshooting import-assets
1

I recently started using the JMEC tool to convert my glTF models to j3o (I was doing it on the SDK but, for some reason, it won’t accept .glb files) and I noticed that, when models are in .glb format, the resulting .j3o is much larger in comparison to those that are generated from a .gltf. I know that when a .j3o is generated from a .glb, all textures are embedded in the file, but I still think its size is larger than it should be.

As a simple test, I created a sphere model on Blender with three textures (basecolor, metallic-roughness and normal maps – material created according to instructions described here) and exported it to both .glb and .gltf formats, converting them to .j3o next. The .glb and .gltf files had similar sizes, but the .j3o file generated from the .glb was 4 times larger than the one generated from the .gltf.

Original files:

$ ls -l
-rw-rw-r-- 1 fba fba 1417375 mar 14 18:23 sphere_basecolor.jpg
-rw-rw-r-- 1 fba fba   23648 mar 14 18:23 sphere.bin
-rw-rw-r-- 1 fba fba 3186788 mar 14 18:22 sphere.glb
-rw-rw-r-- 1 fba fba    4256 mar 14 18:23 sphere.gltf
-rw-rw-r-- 1 fba fba  477614 mar 14 18:23 sphere_metal-rough.jpg
-rw-rw-r-- 1 fba fba 1266180 mar 14 18:23 sphere_normal.jpg

The size of sphere.glb is pretty close to the sum of the other files sizes.

.j3o generated from .gltf using JMEC:

$ ls -l
-rw-rw-r-- 1 fba fba  1417375 mar 14 18:24 sphere_basecolor.jpg
-rw-rw-r-- 1 fba fba    36463 mar 14 18:24 sphere.gltf.j3o
-rw-rw-r-- 1 fba fba   477614 mar 14 18:24 sphere_metal-rough.jpg
-rw-rw-r-- 1 fba fba  1266180 mar 14 18:24 sphere_normal.jpg

                total 3197632 bytes

.j3o generated from .glb using JMEC:

$ ls -l
-rw-rw-r-- 1 fba fba 12619502 mar 14 18:24 sphere.glb.j3o

               total 12619502 bytes --> 3.95 times larger!

I also tried it with a model from The Khronos Group (WaterBottle) just in case there is something wrong with my models, but it resulted on a file 7 times larger!

.j3o generated from WaterBottle.gltf:

$ ls -l
-rw-rw-r-- 1 fba fba  2165850 mar 14 22:09 WaterBottle_baseColor.png
-rw-rw-r-- 1 fba fba    59102 mar 14 22:09 WaterBottle_emissive.png
-rw-rw-r-- 1 fba fba   153229 mar 14 22:09 WaterBottle.gltf.j3o
-rw-rw-r-- 1 fba fba  3007372 mar 14 22:09 WaterBottle_normal.png
-rw-rw-r-- 1 fba fba  3577832 mar 14 22:09 WaterBottle_occlusionRoughnessMetallic.png

                total 8963385 bytes

.j3o generated from WaterBottle.glb:

$ ls -l
-rw-rw-r-- 1 fba fba 63067839 mar 14 22:23 WaterBottle.glb.j3o

               total 63067839 bytes --> 7.04 times larger!

Now, I don’t know exactly how the structure of a .j3o file is like (my fault, I never really looked for it), but it doesn’t seem very reasonable to have such a huge .j3o file when it’s generated from a .glb. Well, I could be wrong tho. Is that correct? Does it really need to be that larger?

2

If the j3o from glb has textures in it then that’s why it’s larger. There is literally no other difference in the loading… the glb is unwrapped and passed directly to the same code that reads the gltf.

Remember when calculating the size that the textures will be uncompressed in the j3o if they are embedded.

3

I still think that it’s a very large size for a file even with all textures embedded, but since there is no difference when loading, it’s okay then. Anyway, maybe we should rethink how a .j3o file is structured internally for a future JME4.

4

It could be something in the gltf itself, too… like either the loader or the file itself is not treating these textures as the same if they are shared across spatials.

Personally, I’d rather have my images external anyway.