What next for PolyVox?

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 🙂

Share
This entry was posted in Uncategorized and tagged by David Williams. Bookmark the permalink.

About David Williams

David is a post-doctorate researcher at the University of Groningen, The Netherlands, where he is investigating GPU computing. Prior to this he worked in the games industry and wrote graphics/engine code for a number of PC/PS3/XBox titles. As well as making games he occasionally enjoys playing them, and also sometimes gets outside to do some photography.

5 thoughts on “What next for PolyVox?

  1. Hi David,

    Thanks for providing an update. I applaud the renewed focus on PolyVox. I had feared it might be abandoned in the effort on game dev.
    I agree the first thing that needs to be done is clean up PolyVox and move it into Git with proper versioning.

    • Yeah, Voxeliens turned out to be a lot more work than imagined. The last six months have involved very little actual development and have mostly been about packaging, testing, distributing, marketing, promotional artwork, etc. To be honest I’m really looking forward to getting back into PolyVox development again 🙂

      • Obviously you guys are trying to look for ways to make a living off of your work, which is why you side-tracked into game dev for a bit. In my opinion you should consider potentially switching PolyVox to an open-source licence that allows you to sell it to commercial projects. Something cheap and easy like $50.
        I think you might find reasonable commercial success with PolyVox if you made it easy to integrate into some of the more popular engines (Unity, UDK, CryEngine, Leadwerks).

        Polish it up. Once you’re happy with the core I think its very important you consider developing render helpers such as your CubicExtractor, but more advanced. Dual-contouring comes to mind. I hope to contribute to this at point in the near future.

        • Actually PolyVox used to be under the GPL (which would then allow for a seperate commercial license which we never tried) but I don’t think we want to go back to this. We basically work on it for fun, and trying to turn it into a commercial product can take away from that. There are other options though, for example I’ve previously done contract work adding features and helping with integration into other engines. This might be an area which can be expanded further in the future.

          I’ll meet up with Matt at the Develop Conference in the UK and I expect we’ll have a talk about a lot of this stuff. We do have vague plans for a future project built on PolyVox but we’ll need to try a different development and marketing model than what we used for Voxeliens. Perhaps it can run more in parallel with PolyVox, and also serve a promotional purpose. Well, more on this when we’ve had a chance to think about it…

          • Ah great. I mean free is better for me. But I’d also like to see you find a way to continue developing this at a decent speed.

Leave a Reply

Your email address will not be published.