Interesting... makes alot more sense than what I said.

In practice it's more like 512*512*64 bits for the geometry or "is this air" array, then a hash map for the colors.

Even if you were to just naively dump the uncompressed map data you wouldn't save the coordinates, as they are implied in the format (x=1 comes after x=0, y=1 comes after x=512, etc)

Thanks Hompy! Wow, imagine the possibilities for that unused alpha channel (variable block toughness, partial transparency, etc)

So on a 512x512x64 map without compression that should be

-6 bits for the z coordinate
-9 bits each for the x and y coordinates
-1 bit for "air" or "not air"
-32 extra bits for surface blocks

=25 bits per hidden/air voxel, 57 bits per surface voxel

Is that about right?

Surface voxel color is 32 bit ARGB, so there's an unused alpha channel in the map format. The server however discards the alpha and only sends RGB to clients.

Each z column in a vxl file is RLE compressed, but this isn't very efficient in cases like the Garage map where there's air in between each floor.

What do you mean? Like, are the skins stored like Minecraft in a png? If so, it's not, they're stored in a kv6 file, editable in Slab6.

All the information for a voxel would need is, position on xyz axis, and colour.

How are the voxel files used in AoS stored? Are the file formats like 3D bitmaps, or do they use some sort of lossless compression technique (like a 3D png)?

-If it's like a 3D bitmap, how many bits are used per voxel? I know that 16 bit color data is stored in .vxl files (for surface voxels at least), but maybe there's some sort of transparency channel?

-Do the "bits per voxel" rates go up for files with very large dimensions?

-Is anyone working on a 4-dimensional voxel format yet??