When working with Panda3D, you will mainly encounter two kinds of files for storing models and actors. The one type of file has the extension .egg, while the other ends with a .bam filename suffix.q.
The .egg file format is intended to be a common intermediate and interchange file format. It was designed to be very easy to understand, to facilitate the development of format converters and export plugins for digital content creation tools. Files in .egg format are text-based and human-readable, which makes them easier to inspect and analyze. This also makes it possible for version tracking systems like Subversion, Perforce, or Git to efficiently store and track changes to the model data.
The big downside of the .egg model file format is file size. Storing this kind of data in a plain-text format is not very efficient and takes up a lot of storage space. Not only does this unnecessarily waste disk space, it also increases the time needed for loading geometry into the engine.
To keep file sizes smaller, .egg files can be compressed using pzip, as you will see in this recipe. This works fairly well but does not solve the problem of loading times, which brings us to the .bam file format.
Just like .egg files, .bam files are used for storing model and animation data. The difference between these two is the way the data is stored. While the .egg format is designed to be easily comprehensible for us humans, the .bam format is used to represent this data in a way that is friendlier to a computer and more specifically, to the Panda3D engine.
The .bam format encodes model data in a binary format that is closer to Panda3D's in-memory presentation of that data. This allows the engine to load models faster because fewer preprocessing steps are required for parsing the file format and filling data structures. Additionally, by this way, storing raw binary data is more space efficient, leading to smaller file sizes.
This recipe will show you how to compress .egg files to save disk space, and how to convert models from this intermediate format to the .bam format for efficient storage, loading, and distribution.
In this recipe you will work on an .egg model file. Of course you need such a model file to be able to work through the tasks. The steps of this recipe will assume the filename to be model.egg.
Use the following commands presented to compress and convert model files:
- Open a command prompt and navigate to the directory containing your model file.
- Type and execute the following command:
pzip -9 model.egg
- Convert the model to the
.bamformat using this command line:
egg2bam -noabs -flatten 1 -combine-geoms 1 -txopz -ctex -mipmap -o model.bam model.egg.pz
The pzip tool is used to compress .egg files. When invoking it the way we do in this recipe, the source file is compressed in place, generating the file model.egg.pz out of model.egg. If we want to keep the original file, we need to explicitly specify an output file name using the -o parameter. The pzip tool also takes an optional command line parameter for setting the compression level. While -9 sets the strongest compression, -8, -7, and so on—ranging down to -1—set subsequently weaker levels of compression. Less compression results in bigger file sizes, but less time will be needed for processing a file. Setting a higher compression level on the other hand will increase processing times but decrease file sizes.
When converting to the .bam format, there are a few more options we can pass to the egg2bam tool. With -noabs, we make sure the .egg file does not contain any absolute references to other models or textures. If any absolute file reference is found, the program aborts with an error. It generally is a good idea to use relative file references, because it makes it easier to relocate our model files, for example when we are installing them to a directory chosen by the user.
The next two options, -flatten 1 and -combine-geoms 1 apply some optimizations to the geometry and the hierarchy contained in the source file. While the first one enables simplification of the tree structure, the second of the two parameters instructs egg2bam to look for duplicate geometry groups and combine them into one.
Finally, we pass some options for how egg2bam should handle textures. The -txopz option causes the creation of texture object files. These files with a .txo.pz suffix store texture image data in a format that is already suitable for being loaded efficiently into the engine. Additionally, the file data is compressed to minimize storage requirements.
Using the -ctex flag enables lossy DXT compression to be applied to all of the model's textures. This kind of compression not only saves space, it can be decoded in hardware by most modern graphics cards. This makes it possible for texture data being stored inside the graphics adapter's memory in the compressed form, using up less texture memory. As a downside, this kind of compression will have a negative impact on the quality of our textures. If our textures are in a very high resolution however, the space saved by DXT compression is generally worth a minor loss in image quality.
Mipmapping is a commonly used level of detail technique where a set of textures is used instead of one single texture map. Each texture in the set corresponds to a mipmapping level. With each subsequent level, the texture is sampled down to half the size of the previous level. Depending on an object's distance from the camera, this allows us to choose a lower texture resolution, because it will only take a few pixels to draw a distant object. If objects are closer to the camera, mipmapping uses the higher resolution textures found in the set, as more details will be visible on a close object.
We can calculate the downsampled versions of the original texture using the -mipmap flag. This increases texture file size by 30% because of the additional texture detail levels being stored. But not having to generate them at load time may help to decrease loading times. Additionally, our runtime performance should become better, because mipmapping allows for more efficient rendering. We should however, always rely on profiling data to back our performance claims and check our games' performance metrics using the tools shown in Chapter 10,