We’ve been hard at work on Voxeliens for about a year now, and since starting this blog it’s almost all we’ve been talking about. Our PolyVox library has basically been on the back-burner, but with development on Voxeliens very nearly complete, we are starting to get time to work on it again.

Readers not familiar with PolyVox should have a read of this page, but in a nutshell it is the voxel engine which underpins Voxeliens. It’s firmly aimed at programmers rather than gamers, and has had some success in being used for a number of different projects (link). In the future we’d like to use this blog to talk about our technology as well as our games, and I’m going to kick that off with a quick discussion of what’s coming next for PolyVox.

• One idea we have been working on is to separate the properties of a voxel from the algorithm. Voxels are no longer required to have a ‘getDensity()’ and/or ‘getMaterial()’ functions, and can instead provide whatever properties they wish (or none at all, as primitive types can now be used as voxels). Algorithms can then make use of function objects which explain how a particular voxel type should be interpreted. This is similar in concept to how the std::sort function takes a comparison object to define how types are sorted.
• The same concept can be applied at a higher level. For example, the Cubic SurfaceExtractor used to use getMaterial() to determine when to generate quads for the output mesh. In the new version the user instead provides an ‘IsQuadNeeded()’ function object which is called for pairs of voxels. Instead of just using material, the user’s implementation of this function could also consider the transparency of the voxels when generating the mesh.
• Meanwhile, Matt has started reviving the SWIG bindings, and there is some chance we will be making use of these ourselves in the future (which will provide some incentive for us to keep them in working order). He’s also started setting up nightly tests for them so hopefully we can notice more quickly if something breaks.
• Lastly, we want to try and add some polish to the next release. This means introducing real version numbers rather than just snapshots, creating a branch in Git for the release, removing/fixing some broken stuff, and getting some documentation written.

These changes might not seem too revolutionary, but this is because we’ve mostly been focused on Voxeliens. Hopefully we can lay the groundwork for future developments and get PolyVox into a position where we can accept contributions from members of our community. After all this work on game development we’re quite looking forward to getting back to the technology 🙂

I’ve just uploaded a new snapshot of PolyVox. It’s been a while since the last one, and we’ve had a couple of cases recently of bugs being reported which have already been fixed in the Git version. So it seemed to be time to bring everyone up to date. Also we should be announcing our game in the next few days, and if this generates any more PolyVox users then we would like them to be up to date as well.

This snapshot does contain some new features but be aware that most of them are work-in-progress. The most interesting changes are:

• VolumeResampler (WIP): This provides the ability to copy data from one volume to another, where the source and destination do not have to be the same size. That is, you can use this class to change the resolution of your volume data, and interpolation is performed where necessary. There is an example in PolyVox (SmoothLODExample) showing how this can be used to perform level of detail by changing the resolution of the volume rather than by decimating the resulting mesh. Another application would be to reduce the size of your volume before performing ambient occlusion calculations.
• LowPassFilter (WIP): This essentially performs a blurring operation on the volume data. I’m currently using this as an approximation to ambient occlusion (to be presented in another blog post), and another application may be to smooth your volume data. Along with the VolumeResampler above, I believe we have the start of an image-processing pipeline for volume data and I expect more will be added to this in the future.
• RawVolume: This is a new volume type which stores all its data as continuous memory rather than breaking it up into blocks. As such it should only be used for small volumes. I am using it as the output of ambient occlusion calculations as it can be copied directly to the GPU, and it may also be useful to people implementing their own paging system.
• Volume Refactor (WIP): All volumes now derive from a common class called BaseVolume. This holds some common functionality  but there is no use of virtual functions. There is also some refactoring of the way the volume samplers are implemented. I hope these changes will be transparent to most users but they may affect those users who have defined their own volume type. If you fall into this category then have a look at the other volume classes and ‘VolumeSubclass’ in ‘TestVolumeSubclass.cpp’ for examples of how the volumes should now look.

You can download the snapshot from here. If you have any problems with this release then feel free to ask in the forums.

With the launch of this new website I promised to post updates more often… and I have no excuse given that WordPress makes blogging so easy. So what’s the latest news?

Well, I’m excited to say that I’ve recently landed a new job in the Netherlands. In a couple of weeks time I’ll be starting work at the University of Groningen, doing post-doctorate research in OpenCL/CUDA. I’ll be moving from the UK so I have a lot of organising to do, but I’m really looking forward to working with this state-of-the-art technology.

Of course, there have been requests in the past for some kind of OpenCL/CUDA support within PolyVox. It seems that I will now be gaining the expertise and experience to decide whether this is a good idea, and to implement it if desired. It won’t be for several months as I have a lot to do in the mean time, but it is definitely a step in the right direction.

We are also getting very close to announcing our first game. The only reason it isn’t being announced right now is that I want to complete the move first, so that I have time to respond to any interest which the game generates. That puts an announcement about three weeks away… so watch this space!

Groningen, The Netherlands