The last few weeks have seen some more work on integrating Cubiquity with Unity3D. The screenshot in the last blog post was actually a single large mesh which made it difficult to modify, but it’s now being properly broken down into a number of small meshes which can be updated individually when their voxels change. So everything is a lot more dynamic now.

Physics objects bouncing around a voxel terrain.

The meshes are also now fed into Unity’s physics system so that they can be used as colliders. Also raycasting functionality has been exposed and these capabilities have been combined in the extremely simple ‘game’ you can see in the screenshot below. The tank can be controlled by the keyboard while the mouse aims and shoots.

The tank is a physics object so you can shoot holes in the ground and then fall into them.

So a lot of stuff is starting to come together, though I must emphasise that it’s still very much a proof-of-concept. The main issue is that we are still new to Unity, and so not exactly sure how it should be integrated. Currently there is only an interface for programmers as we need to think how this gets integrated with Unity’s edit mode.

Anyway, we’re thinking about releasing a ‘preview’ version (for free) in the next couple of weeks to get some initial feedback. I just need to look at how this stuff is supposed to be packaged up, as well as polishing a few bits of the system. Stay tuned!

We’ve been talking about Unity integration for months, but today I can finally prove that we’re working on it 🙂 The screenshot below shows a simple terrain loaded by Cubiquity, with the data then passed through the plugin interface and rendered by Unity:

I had never worked with Unity before attempting this so there has been a lot to learn. I knew that Unity used .NET for scripting and that ‘C++ support’ was only available in the Pro version, but I had assumed that once you had this you could write your games in C++ using Unity as a library. But as anyone who has actually used it knows, that’s not how it works at all.

The way it works instead is that C++ code can be complied to plugins which can then be loaded at runtime. One limitation here is that you have to provide a C API (or at least avoid name-mangling issues) whereas Cubiquity is written in nice templatised C++. So some time has had to be spent creating a C interface to this. Actually there are other options such as C++/CLR, but the C API seemed like it would have the most value in other scenarios.

On the plus side, it turns out that loading plugins does actually work in the free version of Unity (with limitations) so those users will still be able to try out the system when we produce a test version.

Anyway, it’s very much a proof of concept at the moment but it does look like it’s going to work. I can see now that it will take a little longer than we originally thought but I still hope we’ll have a lot more to show off in the coming months.