After the v1.1.0 release of More Advanced Vehicles I looked into why the project takes up so much space on my hard drive.
On my Linux system (ext4 filesystem with 1KB blocks), a freshly cloned repo takes up 151448 blocks, which seems like a lot for such a simple project.
du|sort -r showed that over half the disk space was taken up by a single 62-MByte file: “src/main/resources/Models/cruiser_wheel/cruiser_wheel.gltf.j3o”, a C-G model in J3O format. I supposed this might be a very complicated model, so I loaded it into Maud and examined it. It contains 2 meshes, 7 textures, and very little else!
The meshes have 231 and 290 vertices respectively, so probably the textures account for most of those 62 MBytes. They’re not abnormally large (2-D, with 1024 to 2048 pixels on each side) but they do take up a lot of space. The reason, it seems, is because they lack keys.
A texture’s key consists of its asset path plus a few other details that allow JME to load the texture from an image asset, typically in PNG or JPEG format. According to Texture.java, JME has 2 ways to serialize a texture to a J3O asset. If the texture lacks a key, JME writes the entire
com.jme3.texture.Image to the J3O. But if it has a key, JME writes that instead, and when the J3O is loaded, the image is read from the (separate) image asset, which should be highly compressed.
Writing images instead of keys is advantageous because it yields a self-contained J3O asset, one that doesn’t depend on any other assets. But it has 2 major drawbacks:
- it defeats JME’s asset cache and
- JME serializes the image as an uncompressed buffer.
Adding keys to the cruiser-wheel textures shrank the J3O file to just 68 KBytes, a 925x reduction! And the 7 images, when written to PNG files, total less than 8 MBytes:
sgold:~/Git/Maud/Written Assets/Textures/w$ ls -l total 7840 -rw-rw-r-- 1 sgold sgold 111305 Dec 15 07:18 0.png -rw-rw-r-- 1 sgold sgold 1100017 Dec 15 07:18 1.png -rw-rw-r-- 1 sgold sgold 1686268 Dec 15 07:18 2.png -rw-rw-r-- 1 sgold sgold 2312010 Dec 15 07:18 3.png -rw-rw-r-- 1 sgold sgold 1099733 Dec 15 07:19 4.png -rw-rw-r-- 1 sgold sgold 1686268 Dec 15 07:19 5.png -rw-rw-r-- 1 sgold sgold 10664 Dec 15 07:19 6.png
PNG does a great job of compressing texture images, especially “6.png”, which appears to be pure white!
Moreover, it turns out that “2.png” and “5.png” are identical; using texture keys, a single copy can be shared between the 2 geometries, saving space both on disk and in RAM. And furthermore, it appears that most of these textures are duplicates (or flipped duplicates) of textures that already exist in the project’s “src/main/resources/Models/GT/textures” folder, which should allow further savings.
Since I didn’t generate the project’s J3Os, I don’t know why some of them have texture keys and some don’t. I’m adding a “create texture key” feature to Maud. And if JMEC and the SDK aren’t aware of keyless textures, perhaps they should be.
The bottom line: if disk space matters to you, make sure all your textures have keys!