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?
