I have found the simplest 3D ASCII format for voxel data. It is (fittingly) called ".vxl".
The format works like this:
Every line starts with a v.
The v has 3 numbers following it.
These 3 numbers are x, y, and z. x is width, y is height, and z is depth(respectively).
That's simple, but for something as memory consuming as voxels, not very efficient (about 8 bytes per voxel, so 256x256x256 is 128MiB, not very good, especially when considering that each voxel also needs a color assigned). For any high detail stuff, you ought to look into sparse voxel octrees, run-length encoding and 2d image compression techniques. In fact, you could make a massive improvement by switching to a binary format, working in blocks of 256x256x256 voxels, then tracking voxel positions using 1 byte per coordinate, also adjusting how you order your coordinates in order to optimize for RLE, and using SVOs at the block level.
Voxels are a fun rabbit hole to go down
Re: The simplest 3D format for voxels!
Posted: Fri Aug 25, 2017 8:55 am
by MajickTek
hgoel wrote:...especially when considering that each voxel also needs a color assigned).
Although this might not be very efficient.
But I am new to the world of 3D computer graphics.
Edit: the editor supports QEIKE (QKM) format which is binary. It seems to be way more complicated than necessary though.
Re: The simplest 3D format for voxels!
Posted: Fri Aug 25, 2017 8:59 am
by hgoel
You can do that, but compared to a binary format, where it'd be 1 byte per component, you're now taking 3 bytes per component (0xFF vs '2' '5' '5').
Re: The simplest 3D format for voxels!
Posted: Fri Aug 25, 2017 9:06 am
by MajickTek
hgoel wrote:You can do that, but compared to a binary format, where it'd be 1 byte per component, you're now taking 3 bytes per component (0xFF vs '2' '5' '5').
True.
Re: The simplest 3D format for voxels!
Posted: Sun Aug 27, 2017 2:58 pm
by zesterer
Octrees are pretty much unbeatable for static storage of voxel data (i.e: you don't care about the time required to load and unload the voxels from this format) unless you have very irregular data - it works great for Minecraft-like worlds though.
As a side-note, and if you're interested, I wrote a voxel engine one weekend a few months ago:
Re: The simplest 3D format for voxels!
Posted: Mon Aug 28, 2017 4:36 pm
by WookiePaw
Hi,
I was working on a 2D tile game a while ago, and I though I'd share this. I found that you can efficiently store the structure of a chunk (16/128/16 in this case) by assigning each different material a byte ID, then writing that to a file using an iteration, or 0 (air) if there isn't anything there.
Given this, you can compress the file as you would any binary file, or leave it uncompressed. It's also very simple to read back into the program.
I was working on a 2D tile game a while ago, and I though I'd share this. I found that you can efficiently store the structure of a chunk (16/128/16 in this case) by assigning each different material a byte ID, then writing that to a file using an iteration, or 0 (air) if there isn't anything there.
Given this, you can compress the file as you would any binary file, or leave it uncompressed. It's also very simple to read back into the program.
This is actually really cool!
I love games that use chunk systems because it is simple to create huge worlds by streaming the data.
Looking at your code, i immediately knew how this could be translated to 3D!
Re: The simplest 3D format for voxels!
Posted: Fri Dec 01, 2017 1:45 am
by Wajideus
The memory usage could be improved a bit by defining supervoxels.
Back in the day, I was programming on a machine that only had about 24k of ram, and I managed increase the map size of a 2D game by using bit-packed 6x6 tiles in a tileset and defining 12x12 supertiles that indexed the tileset with flags for mirroring horizontally or vertically.
hgoel wrote:You can do that, but compared to a binary format, where it'd be 1 byte per component, you're now taking 3 bytes per component (0xFF vs '2' '5' '5').
While this is true, a text-based format lends itself better to interchange because it doesn't suffer (as much) from the myriad of issues associated with binary formats like endianness, format changes, version control, and corruptibility.
