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.

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);
raycast.execute();

if(result.foundIntersection)
{
...
}

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?