Tag Archives: Gameplay3D

Regular followers of our blog and forums will know that over the last few months we have done a lot of work integrating PolyVox with the Gameplay3D engine. We’ve also mentioned Unity3D and talked about creating a higher level framework to integrate PolyVox with such external game engines. Today we are pleased to officially introduce this technology as ‘Cubiquity’, and provide a very early demonstration of where we are going with it.Cubiquity is a C++ library which is currently dependant only on PolyVox and which provides higher-level features such as a scene graph, level-of-detail, mesh management, and tools for manipulating volume data. Additionally we have developed ‘Cubiquity for Gameplay3D’ which basically connects Cubiquity to a Gameplay3D scene node so that volumes can be treated as first-class citizens in Gameplay3D. We also have Lua bindings so that Gameplay3D scripts can create and manipulate volume data.

The video below shows some of the features which are present in the tech demo. Cubiquity supports both cubic (hence the name!) and smooth voxel terrain but only the cubic terrain is being shown at the moment. The terrain in the video has a resolution of 512x512x256 voxels which are displayed as coloured cubes. A LOD system allows these cubes to be grouped together into larger cubes as they move into the distance. The terrain is fully dynamic and can be edited in real time (but note that lighting is baked in to this data set).

As mentioned, we have bindings to Lua which have allowed the whole tech demo to be driven by a simple script. This handles input, drives the rendering loop, and also exposes the entire Gameplay3D API meaning that (in theory) you can take this tech demo and build a game on it. In practice you might want to wait for a more mature version 😉

You can download the tech demo at the link below. Please remember this is a very early version and, amoung other problems, whole system is currently running on a single thread. This causes pauses/hiccups when the terrain is being modified. The initial loading of the terrain is also slow and may take a minute of so.

We do not currently expect Cubiquity to be free, and will probably be targeting the professional indie market with it. Hopefully this will provide a way to support the development of PolyVox (which is also directly benefiting from the development of Cubiquity). That said, it is likely that we will continue to provide free tech demos which can be scripted to make your own games. We’re really still working out the details here.

I think there will probably be a lot of questions about all this, so ask away in the comments. Eventually we’ll get some proper information available on the website.

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.

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 😉

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 🙂

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 🙂