A quick update and some new screenshots

I thought I’d write a quick update on where we stand with our various projects as I feel like we’re juggling a dozen things at a time here 🙂 I’ve thrown in some pictures to spice it up a bit, but if you want to see these when they are fresh then be sure to follow us on Twitter.


Since the first tech demo we have implemented threading in Cubiquity so that surface extraction can be performed in the background. This improves loading times and responsiveness but currently it only works with PolyVox’s SimpleVolume, which limits the amount of volume data we can load at a time. I’ve also done some work overhauling the shaders so that normal mapping is now supported, and hopefully this will get improved further in the future.

Normal mapping the voxels in Cubiquity


The most significant addition to PolyVox is that the LargeVolume class now supports plugable compression code. We’ve also provided an implementation based on the miniz library. This works well for smooth terrain while the existing RLE compressor can be used for cubic ‘Minecraft style’ terrain.

Next up we need to improve the thread safety of the LargeVolume as this has been requested many times, and we’re starting to need it for Cubiquity (as mentioned above).


We’ve received some feedback about the format and will do a proper post about this soon. The main issues raised are paging for very large volumes (probably beyond the scope of what we are aiming for here) and also an existing similar format (but it doesn’t make the slice data easy to visualise). We’ve also bee working on some test data sets which we will make available as part of an online archive. A couple of examples are below:

A ‘Build and Shoot’ map loaded into Cubiquity. Source data is here: http://www.buildandshoot.com/viewtopic.php?f=8&t=913

I wrote a program to create a Mandelbulb as these can be very large and still have fine detail. This one is only 512x512x512 though.


I downloaded Unity and had a play with it last weekend. It’s a really cool system, and I can see why it’s got such a big following as it makes development really easy. Integrating Cubiquity is a bit more difficult than I hoped as it turns out that plugin .dlls need to provide a ‘C’ interface (not C++) so we’re having to create a wrapper for Cubiquity. This takes a bit of time but shouldn’t be a big problem over all.

That will do for now – see you next time 🙂


VolDat: A standard format for exchanging volume data

One of the challenges which we face when developing a voxel engine is finding appropriate datasets to test with. For researchers working with mesh data there are a number of standard test models (Sponza, Dragon, etc) which have been used in hundreds of papers over the years, but our options for volume data are a lot more limited. There are some archives containing CT/MRI data but this is not appropriate for all usage scenarios.

Another challenge is the lack of a standard format for volume data, as this impedes our ability to pass data between different voxel applications as well as making the creation of the above mentioned volume data archive more difficult. The only real standard is DICOM, but this is very complex and heavily geared to the medical imaging industry rather than more general scenarios.

Therefore we are taking the initiative to create ‘VolDat’ as a standard format which we hope will be adopted by the various applications which work with volume data, and which will form the basis of our own volume data archive. This is not meant to replace an application’s own format, but instead to be an additional import/export option to promote interoperability.

The format itself is very simple, and is independent of the kind of data your voxels represent (you can use it for coloured cubes, Minecraft-style terrain, density fields for smooth terrain, etc). We basically store each volume as a series of images in a standard format, along with a text file describing some of the volume’s properties. This makes it very easy to understand the data even without reading the specification. For example, the image below shows one of the maps from Voxeliens in VolDat format being viewed in Windows Explorer:

When rendered in 3D it looks as follows (you should all know this having played Voxeliens!):

We’d really appreciate any feedback on this initiative or on the specification itself. The specifiaction is currently hosted on Google Docs which means anyone can add comments, and we can give edit permission if people want to contribute:

You can also provide feedback in the blog comments below or in this forum thread. We’ve also prepared a couple of (small) sample volumes which you can take a look at.

We will try and contact potentially interested parties regarding this initiative, and please do pass this on to anyone who could benefit from it. Thanks!