Level of detail for smooth voxel terrain

Over the last couple of weeks I’ve been continuing my integration efforts between PolyVox and gameplay3d. This is proving to be extremely useful as a way of identifying the problems and limitations within PolyVox, especially as I haven’t worked with smooth voxel terrain for quite a while (since before Voxeliens). In particular I have been focusing on level of detail support, and as you can see below I have had some success:

The MeshDecimator class has recently been deprecated, and I’ve been saying for a while that down-scaling the volume data and running the Marching Cubes algorithm on this smaller data is probably a better way to achieve LOD for smooth terrain. There is even an example in PolyVox which demonstrates this on a sphere. However, doing it on a real world dataset has proved to be a bit more complex, and I can see now that some changes need to be made to the way PolyVox handles sampling outside a volume and to the way the VolumeResampler works. But in principle it does seem like a sound approach.

That said, there’s still an issue with cracks between the mesh patches where the LODs don’t line up exactly (you can’t really see this in the screenshot because it’s wireframe). Some tests have shown that simply overlapping the meshes slightly seems to be a viable solution, but again I need to make some changes to PolyVox to support this more naturally. Of course, the Transvoxel Algorithm is also a more robust solution which may make an appearance in the future.

Next up I’m expecting to look at physics integration for both the smooth and cubic styles of terrain.


Smooth voxel terrain editor in gameplay3d

Over the last couple of weeks I’ve spent some more time on our PolyVox+gameplay3d integration, and have added some basic editor functionality. Here’s how it looks at the moment:

You can paint on the terrain with the various materials, and there is also functionality to edit the shape of the terrain. This can even run on my mobile phone at a slow but useable 10-15fps. I realise the labels say ‘Brush Size’ twice, the second one should actually say ‘Brush Intensity’.

The main reason that I’m doing this is as research into the best way to handle multiple materials within a smooth voxel terrain. These have always presented a problem with  modelling and also with making nice material transitions. I think I’ve made some significant breakthroughs here so I’m hoping to write a research paper on the coming months… so if you want details on how it’s done you’ll have to wait for the that 😉


Where’s the next PolyVox release?

PolyVox users are no doubt aware that it’s been a while (10 months actually) since the last release so I thought it would be worth taking a moment to provide an update to what’s going on. Obviously the main distraction has been Voxeliens (which filled the first 6-8 months and is still in the background), but we’ve also been working on gameplay integration and having a busy couple of months at work. Still, there has been a steady stream of commits to PolyVox so progress is being made.

In a previous post we identified the main areas we wanted to work on before doing another release. I’ve listed these below and colour coded them according to how complete the work is. Green is finished, red is not done yet, and yellow is somewhere in between:

  • Finish voxel refactoring
  • Surface extraction callbacks
  • Unclassing work
  • SWIG bindings
  • Fix A* test
  • Fix warnings
  • Remove redundant code
  • Documentation
  • Release script
  • Switch to Git flow
  • Improved CMake consistency

Note that’s we’ve decided not to pursue the SWIG bindings for the next release. They might still get some improvements but they won’t be in a finished state. Future versions of PolyVox are likely to bring more changes (particularly more unclassing) which might break any bindings we write now but which should also make them easier to implement later.

So when is the next release coming? Well so far we’ve been pretty bad at predicting dates so I’ll just say I hope it’s done by the the end of the year. The plan is still to do smaller and more frequent updates in the future, now that we have the Git flow model and release script.


Smooth terrain in gameplay3d

Over the last couple of weeks I’ve been doing some work to integrate PolyVox’s smooth terrain into RIM’s gameplay3d engine. This follows on from our previous work on cubic terrain. The smooth terrain is no more difficult than cubic terrain, and the main challenge has been designing the code in such a way that the integration elegantly supports both (as internally they have different voxel and vertex types).

The images below are again based on one of the data sets from Voxeliens, but this time we’ve run the data through the LowPassFilter to perform smoothing and basic triplanar texturing is also applied:

These screenshots are taken on PC but the test application does run on my mobile phone as well. It’s a bit slow though (20-30fps) which is probably because there’s no LOD present at the moment. It’s nice to be back to tech development are spending so long working on Voxeliens and we have some big ideas for the next engine 🙂


Unclassing some PolyVox code

I visited Munich a couple of weeks ago and traveling by train was the cheapest and easiest option when coming from the Netherlands. It was still a lot further than I initially expected (at over 10 hours each way) but I was pleasantly suprised to find the trains had power sockets for each seat. This meant I was able to keep my laptop running and crack on with the ‘unclassing’ work which has been mentioned a couple of times in the forums.

So what does this involve? Well, most of the algorithms in PolyVox are used by declaring a class and then calling the ‘execute()’ method, but in many cases it seems that a single function call would provide a better interface. For example, the Raycast class was typically used as follows:

RaycastResult result;
Raycast<SimpleVolume<int8_t>> raycast(
    &volData, start, direction, result, isPassableByRay);


It seems like overkill to have to declare a class (two if you include the RaycastResult) for something as simple as performing a raycast. So I’ve modified the code such that you can now do the following instead:

RaycastResult result = raycastWithDirection(
    &volData, start, direction, raycastTestFunctor);

if(result == RaycastResults::Interupted)

As well as being conceptually cleaner, note that you no longer have to specify the volume/voxel type as it can be deduced from the first parameter which you pass. The old version of the code also needed to store the callback so that it could later be called by execute(). This required the use of std::function, but now that there is no need to store it we can use the regular STL callback approach instead.

I made some other improvements besides simply unclassing this functionality. There’s been confusion in the past over whether the two vectors passed to the raycast should represent a start point and a direction or a start point and an end point. Both are useful, and the naming of ‘raycastWithDirection()’ and ‘raycastWithEndpoints()’ should make it clear which one is being used.

There’s also no longer a separation between a version which uses a callback and a version which doesn’t. A callback must always be provided, and is responsible for determining whether a ray can continue as well as performing any other logic such as changing the state of voxels along the ray.

It is likely that some other PolyVox algorithms will be unclassed in this manner, but as shown on our mindmap we only wanted to do the Raycast for the next release. Actually I also did the AmbientOcclusionCalculator (now calculateAmbientOcclusion()) as it serves as a good test of the raycasting functionality, but in general we want to see whether this process has any drawbacks. So let us know what you think…does it make sense to unclass more PolyVox algorithms?


Updating the PolyVox documentation

Lack of documentation has long been a thorn in the side of PolyVox users, and it’s something we’ve been promising to improve for a while now. In particular we wanted to make a special effort before the next release of the library. I’ve spent some time on this over the last few weeks because I’ve been traveling quite a lot and my laptop isn’t really powerful enough for any real development. We’ve uploaded a preview so you can see the work-in-progress documentation for the following areas:

The API documentation for the CubicSurfaceExtractor has also been updated to include more details and diagrams about how it behaves.

Hopefully it is already useful although it is a long way from being finished. We don’t expect to get it all done before the release but we do want to show that some progress is being made in this area. Getting proper documentation in place will be important to improving the accessibility of the library and allowing people to decide if it is the right choice for their projects.

The index pages for the manual and API docs are below but be aware that some of the entries are just stubs:

We’re interested in feedback on how it’s shaping up (you can ignore typos for the moment as we’ll come back to those later) so do let us know if it makes sense, if it’s the right technical complexity, and whether it covers relevant material. Suggestions for the FAQ are also welcome.


Some PolyVox Updates – Git and CMake

We’ve been very busy here over the last few weeks with Voxeliens related things so I though I should send an update on what’s been going on in the area of PolyVox. There’s been two main changes recently which I hope will help make things easier for people as we move forward.

CMake Folders

The first thing we’ve done is to start using a nice little feature of CMake to make working in Visual Studio a little nicer. Before this change, the Solution Explorer looked like:

Obviously, this is a little hard to work with since all the tests, as well as internal targets like ZERO_CHECK and _PolyVoxCore are included in the list. What would be ideal is if it were possible to organise the targets into a hierarchy which matches how the code is logically organised. I found a blog post showing how CMake can do this. First of all, you must enable a global CMake property to turn on this feature.


Then, for each CMake target, you mush set a property which defines the “folder” in which it will appear. For example, for the PolyVoxCore target, we add the following line to its CMakeLists.txt file:

set_property(TARGET PolyVoxCore PROPERTY FOLDER "library/PolyVoxCore")

Once these are added to all the targets you want to categorise, you will see something more like this in Visual Studio:

Which has put everything in a more logical place. This was added to Git a few weeks ago in this commit.

Git Branching Model

The second “feature” we’ve recently added is a new way of working with our Git repository. Up until now, we’ve simply done all work in the master branch (perhaps with the occasional local topic branch) and so it’s sometimes been the case that the version of the code in the Git repo hasn’t been in a compilable state. As we’re currently working towards making a proper release of PolyVox, we decided that we should be more structured with our usage.

I’d heard good things about Vincent Driessen’s “successful Git branching model” and after reading it through we decided that it would be a good model to follow. Even better, he provides a cross-platform set of Git extensions called git-flow which make the whole process painless.

As of today, we will be using the new branching model. The master branch will now only contain released versions of the code and if you want to get the latest development version, you’ll have to check out the develop branch. When browsing the web interface at Gitorious, you’ll see that you can switch between branches by clicking the name in the grey box at the top or in the right-hand panel when browsing the source tree.

When it comes to release time, it’s simply a few commands to merge the develop branch into the master branch and tag the commit.

What this means for users is that we’ll be making more regular, stable releases and the git repository will be in a much more stable state for you to use.


PolyVox on Android

Following a previous post about PolyVox on iOS, I’ve spent some time over the last few weeks experimenting with RIM’s gameplay engine as a basis for future projects. Naturally this has involved integrating it with PolyVox and today I have some initial results to present. The video below shows gameplay and PolyVox working together on my Samsung Galaxy S Plus:

The voxel world is one of the levels from Voxeliens but this doesn’t necessarily mean we are bringing Voxeliens to mobile (we might, but we’re just experimenting for now). It was basically just the data I had closest to hand, and the volume dimensions are 128x128x32.

To be honest I’m pretty amazed at how well it runs! I’m seeing a steady 40-50 frames per second and this seems to depend on how many pixels are being drawn. I need to do more investigation into the performance bottlenecks though. Also, be aware that this is a debug build as I’m new to Android development and I don’t know how to do release builds yet (it requires some kind of signing I believe).

Getting PolyVox to build on Android was not too difficult. The only problems were complaints about std::function and about throwing exceptions. For now I just cut out the offending pieces of code but we’ll have to come up with a proper solution in the future.

I really like RIMs gameplay engine, and if we do decide to use it for future projects then it opens up a lot of platforms for us. And after all the work we did on Voxeliens it’s great to be getting back to playing with technology again 🙂


PolyVox on iOS

The blog’s pretty lively this week 🙂 Well there’s one more thing I thought might interest our PolyVox users. We were sent this on Twitter yesterday from someone we met at Develop (it was the first time we heard “Hey, you’re the PolyVox guys!”). It’s a video of PolyVox running on an iPad 2:

You can right click to watch the video on Vimeo, but I’ve reproduced the included information below:

“Met @VolumesOfFun at Develop, discovered they hadn’t tried their voxel meshing library on iOS, decided to spend an hour or two hacking something together to see how fast it ran. And then take a pretty shoddy video cap of it!

Mental note: buy an HDMI capture card.

30x20x30 voxels, constantly regenerating all 18k cells and resulting mesh; ran at 25-30hz on iPad2. (the voxel data generator was multithreaded, but PolyVox isn’t)”

Thanks for showing us this, and let us know if you do more PolyVox work in the future!


A mind map of our thoughts

Despite being brothers, Matt and I actually live in different countries and so most communication is done by email or via the forums. But as we were both in the UK last week we took the chance to discuss the various things which were on our minds regarding our projects. We didn’t get as much time as we would have liked, but none-the-less it was very useful and we produced the lovely mind map below:

Of course, it’s more useful in the context of the discussion which we had but we thought it might be interesting anyway. We’re going to update it from time to time and use it as a method of tracking what we’re currently thinking about. Some of the key points:

  • Work on Voxeliens is mostly focused around distribution at the moment. Matt is talking to Good Old Games and we sent off our Steam application at the weekend. So fingers crossed for that! At some point I’m probably going to investigate the possibility of bringing the game to mobile devices.
  • PolyVox has picked up again with a lot of commits recently. We’re focused on trying to get a release out so we can then think about integrating other peoples contributions. On that note, Matt has pointed out that we are not using Git very effectively (I basically treat it like SVN) so we will investigate something like ‘A successful Git branching model‘. This should keep Git head a bit more stable.
  • We’ve vaguely discussed a future game project but with no details yet. We’ll probably look at integrating PolyVox with a complete game engine (rather than separate graphics, physics, sound, etc libraries) so we may do some investigation into the options here.

We’ve decided we should try and be as transparent as possible so do ask if you have questions about our plans.