FLVC Performance, Conclusions
Examples
In the following section, we will look at three concrete examples of real world performance of the FLVC codec.
Note
All test were performed on the ramdisk of a Debian 11 Desktop.
Processor: Ryzen 9 3900X
Memory: 64 GiB 3200MHz
Spacestation
| Voxels | 923,566 V |
|---|---|
| Raw Size | 14,777,056 B |
| Encoded Size (FLVC-6) | (3.34%) 500,812 B |
| Encoded Size (FLVC-9) | (3.33%) 493,409 B |
| Encoding Duration (FLVC-6) | 1679 ms |
| Encoding Duration (FLVC-9) | 2130 ms |
Scrapyard
| Voxels | 24,423,655 V |
|---|---|
| Raw Size (VL32) | 390,778,480 B |
| Compressed Size (FLVC-6) | (1.71%) 6,682,496 B |
| Compressed Size (FLVC-9) | (1.69%) 6,602,502 B |
| Encoding Duration (FLVC-6) | 38 s |
| Encoding Duration (FLVC-9) | 44 s |
Mars Heightmap
| Voxels | 101,244,604 V |
|---|---|
| Raw Size | 1,619,913,664 B |
| Encoded Size (FLVC-6) | (0.90%) 14,616,607 B |
| Encoded Size (FLVC-9) | (0.86%) 13,914,269 B |
| Encoding Duration (FLVC-6) | 149 s |
| Encoding Duration (FLVC-9) | 163 s |
Conclusions
Compression Ratio
Free Lossless Voxel Compression delivers impressive results.
Even for the smaller and somewhat less redundant models, we need less than one
byte per voxel despite starting with 16 bytes per voxel (x, y, z, argb).
At best, the file size is reduced by over 99%.
It must be emphasized that in related work, the reference point is typically a
voxel array where only a minuscule fraction consists of voxels.
Here, the reference point is a list of voxels with no empty space between.
The level of compression has little impact on the size of the produced filed. At best, a 10% reduction ca be seen, at worst, almost none.
Time
Execution time can be perceived as excessive for very large models. As can be concluded from previous sections, most of this time is spent reading in VL32 data and constructing the SVO. For example, of the 149 seconds to encode the heightmap at level 6, 108 were spent constructing the SVO. This is a problem that can not be easily resolved algorithmically and is inherent to manipulating large quantities of data. Once again, the compression level has comparably little impact: here on the encoding duration.
Further Improvements
Some compression ratio improvements could be achieved by choosing a different entropy coder. For example, Facebook's Zstandard is a more recent and promising technology than zlib. A slight improvement in compression speed is also likely.
However, the biggest bottleneck as of now is the time it takes to construct the SVO while also reading VL32 data. A potential solution would be to use multiple threads: One for reading the VL32 file and one for constructing the SVO. At most, this would reduce the duration of first part of FLVC encoding by 50%.
Another potential approach would be to create multiple, independent volumes, which are all encoded by a separate thread. Potentially, separate zlib streams could be created as well to avoid a bottleneck during entropy coding. However, this would require further modifications of the FLVC standard and is not possible merely by optimizing the reference implementation.