When we began working on Cubiquity the main idea was to expose our PolyVox library through a higher-level interface and tools. PolyVox is powerful and flexible, but requires a strong knowledge of C++, templates and computer graphics to use effectively. By wrapping this in Cubiquity and integrating it with Unity/Unreal we were hoping to bring (some of) it’s capabilities to a larger audience.
The project has been a reasonable success, with a lot of interest from the Unity and Unreal communities and even a game launched on Steam using the technology. However, it is also clear that the original vision is simply too large to finish as a personal side project, especially with diminishing amounts of free time and a desire to adjust my work/life balance. This led to use recently releasing the system for free, but further steps need to be taken to actually reduce the scope.
In this blog post I want to outline the areas in which I/we will be cutting back on development, and explain how it will affect existing users. I also want to define a direction for a future ‘Cubiquity 2.0’ such that it is both smaller and also more technically interesting to work on. This means shifting the focus to research rather than delivering a drop-in system, open-sourcing the complete technology stack, and reducing (but not eliminating) the level of integration provided for Unity and Unreal.
Open sourcing the core Cubiquity library
The proposed change of direction is likely to cause some concerns for users who are already working with Cubiquity, and so I hope to partially alleviate these by announcing that we will release the core Cubiquity library as open source. This is also expected to reduce our workload in the following ways:
- End users will become responsible for building and testing the library on the platforms which they wish to support. On the plus side, they may also be able to port the library to new platforms (Android, iOS) which we did not have time for.
- We may remove Cubiquity from the Unity Asset Store and handle distribution only through BitBucket and/or Github. A more developer-focused Cubiquity may not be a good fit for the Asset Store where users expect drop-in solutions.
This applies to both the current version of Cubiquity (which may not see much further development) and also to a future ‘Cubiquity 2.0’ code base (which will likely be a complete rewrite).
Shifting the focus back to research
When we first released PolyVox back in 2006 the idea of using voxels to represent worlds in games was fairly novel. There was some interesting work by the likes of Ken Silverman and Sven Forstman but voxel techniques were not widely used . The arrival of Minecraft changed all of that, and overnight voxels became the new ‘hot thing’.
Fast-forward ten years and it now feels like everyone is developing a voxel engine, and the techniques used within PolyVox and Cubiquity are no longer particularly novel. But there is a lot of interesting research to be done as shown by projects like Atomontage and VoxelQuest, and I’ve actually been working on an interesting prototype of a new (to my knowledge) voxel-rendering algorithm.
I’ll talk more about my ideas in the a future post, but the important point for now is that the difference between implementing new algorithms vs. really making them production ready is at least an order of magnitude. I therefore expect future versions of Cubiquity to be a little more experimental, a little more developer-focused (rather than artist-friendly), and less like the drop-in solution we currently provide on the Unity asset store.
Reducing the scope
I also have some concrete plans to cut a couple of significant features from Cubiquity. However, note that these changes will not directly affect the current codebase. Instead, Cubiquity 2.0 will most likely be a complete rewrite and will be designed without them in place.
No more Marching Cubes terrain
Cubiquity currently provides both colored-cubes style voxels and smooth (Marching Cubes) terrain. This was made possible because PolyVox supports user defined voxel types and custom surface extractors, but the two voxel systems still require different shaders and editing tools. Developing both systems in parallel is proving to be a rather large task.
We will therefore drop the Marching Cubes terrain and focus entirely on simple colored voxels, with the intention of making them as small as possible. Atomontage has shown that sufficiently small voxels can produce attractive terrains while also modeling buildings and objects, so I hope that a dedicated terrain renderer will not be needed. It is the generality of such a system which makes it interesting, as well as the ability to convert any existing dataset to this format.
Moving editing tools from Unity/Unreal to a separate application
Cubiquity for Unity allows the users to sculpt and paint terrains inside the Unity editor, and there is also basic support for editing the colored cubes volumes. Cubiquity for Unreal offers some similar features though they are not currently as complete. Overall this requires a lot of duplication of code and effort.
The plan for future versions of Cubiquity is to instead have a separate application which can be used for creating, importing and (possibly) editing volumes, and to turn the Unity and Unreal integration layers into much something much thinner. If users wanted to create in-game editors this could still be achieved via the Cubiquity API, as is the case at the moment.
Reduced focus on the Unity integration
We began working on Cubiquity around 2012, and at the time Unity was taking the indie game development world by storm. It was providing a cheap yet powerful platform and was being used by a huge number of indie games. As we were aiming to sell Cubiquity it made sense to provide an integration layer with Unity. However, from a technical standpoint it was quite a poor fit for a few (related) reasons:
No plugin support on Unity Free: Plugin support was a Pro-only feature on Unity 4, so we had to resort to some tricks and hacks to get Cubiquity loading properly. This feature is now free in Unity 5 but we haven’t had time to update our scripts to take advantage of it.
Need to compile libraries: Because Cubiquity was provided as a native-code library we have to compile it for every platform we wish to support. So far we have only supported Windows, Linux and OS X, but with both 32 and 64 bit versions that’s already six libraries to build and test.
Platform support: For the reasons outlined above, it has not been practical for us to support all platforms. Mobile has so far been too much work, and webplayer is simply not possible due to the use of native code. This causes some frustration for users who build their game and then find they cannot export to the platform of their choice.
Some of these problems disappear with Unity 5 and our move towards open source, but we are stuck with the C# vs. C++ issue and the need to compile separately for each platform (though we now defer that problem to the user). By contrast, integration with Unreal should be much more straight-forward, and has mostly been held up by lack of time/resources (see below). In this case we would simply be able to drop our Cubiquity C++ files into an Unreal project.
I’m honestly not sure where I’m going with this. Unity is still a massively popular game development platform, and from what I’ve seen it is probably easier to get into than Unreal. I do expect we will still provide some degree of support for it, but with higher technical requirements on the user and less in the way of Unity-specific examples, documentation, builds, etc. But really we’ll just have to see how the next version of Cubiquity develops, and how well the algorithms match with the architecture of Unity.
Increased focus on the Unreal integration (long term)
Our recent work on ‘The Peasants are Revolting‘ was my first exposure to the new Unreal engine, and I was very impressed. Actually my interest in the engine goes back to the original Unreal which really piqued my interest in game development. However, it was only the arrival of UE4 that the engine became accessible to indies, and by this time I had a good couple of years invested into the Unity integration.
The Cubiquity for Unreal integration was therefore handled exclusively by Matt, who has done an amazing job considering the constraints he was under. But (like me) he has a number of real-life commitments, and the task was made more difficult by Cubiquity being closed source. Furthermore, the motivation for integrating Cubiquity with Unreal is not as clear as for the Unity version, because users have the option of just using PolyVox directly (which offers more flexibility and full source access).
Things look brighter in the future though, as Cubiquity will become open source and so the relevant files can simply be dropped into the project. Also, the core technology behind Cubiquity will (probably) be quite different from PolyVox and so they won’t be competing over the same space. I hope to spend some time in the future either assisting Matt or taking over some aspects myself (depending what he wants), but this won’t happen until the core technology is developed.
This has been a difficult post to write because it so drastically changes the direction of a project which has had a lot of time sunk into it. However, it does seem like the right decision to ensure we stay motivated and work towards something achievable, but exactly what that is remains to be seen.
 90’s-style ‘voxel’ terrain as used in Commanche, Delta Force, etc doesn’t count here as it was not really volumetric (no caves, overhangs, etc). It was just raycasting a heightfield, and as far as I can tell the term ‘voxel’ was just used as a marketing gimmick. If anyone has evidence to the contrary then do let me know!