The simplest 3D format for voxels!

[MajickTek]

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).

A simple file would look like this:

Code: Select all

#this is a comment.
v 0 0 0
v 0 1 0
v 0 2 0
v 0 3 0

This file would be a vertical stack of 4 voxels in the center of the "grid".

How the voxels look is up to the rendering software.

A simple editor for this is here: https://github.com/MajickTek/3d_tile_level_editor (excuse the formatting, im still learning BBCODE)
The editor is CLI and you edit from a top-down perspective.

[hgoel]

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

[MajickTek]

...especially when considering that each voxel also needs a color assigned).

for that you could add 3 more numbers, RBG.

Code: Select all

v 0 0 0 255 255 255

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.

[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').

[MajickTek]

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.

[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:

[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.

Here's a link, if you're using Java.

Cheers,

[MajickTek]

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.

Here's a link, if you're using Java.

Cheers,

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!

[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.

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.