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.
Voxeliens is a retro-style arcade shooter and is essentially a 3D voxel-based version of Space Invaders. We released the game in 2012, showed it off at the Develop Conference and have had it accepted for Steam Greenlight. However, as mentioned in several previous blog posts, time is no longer on our side and we are re-focusing our efforts on the next version of Cubiquity.
Therefore we have decided to release Voxeliens for free under the MIT license. It now lives on BitBucket alongside PolyVox and Cubiquity (our voxel engines) and prebuilt binaries for Windows are also provided. It should also be possible to built it from source (including on Linux) but this has not been well tested on systems other than our own.
We put a lot of work into Voxeliens so we are pleased to now be able to share it with a much larger audience. Note that we do still have the option of selling it on Steam in the future (the Greenlight campaign remains valid) but it is not clear whether we will due to the setup, testing, and support required. At any rate, we hope you enjoy the game!
I made the first public release of PolyVox nearly 10 years ago on the Ogre 3D forums. At the time it was just a simple demo to show how voxels and Marching Cubes could be used to create more dynamic environments, but over the years it evolved into a stand-alone library which has been used by several games and our own Cubiquity voxel engine. It’s been a big part of my life for the last 10 years, but as mentioned in previous blog posts I now have less time and am over-committed with the various projects I’m involved in.
Therefore I have decided to officially cease development on PolyVox, though in practice it has not seen much work for the last couple of years. This follows the wrapping up of the current version of Cubiquity last year, and my plan is still to put the majority of my development time into ‘Cubiquity 2’. This will be completely new voxel engine with more limited scope and a focus on research rather than production use (i.e. for the more adventurous!).
More generally, I have some intention of winding down the rest of ‘Volumes of Fun’ over the coming months and breaking Cubiquity 2 into a standalone organisation and/or project on GitHub. But the details of this aren’t really clear yet, and we also need to work out what to do with Voxeliens. For now the existing support channels (e.g. the forums) will remain open and I expect I’ll just provide email support if/when they disappear.
In our last blog post we laid out a new direction for our Cubiquity voxel engine, including open sourcing the code and shifting the focus towards research for a future Cubiquity version 2. The first part of this is now complete, and the whole technology stack is now available under the MIT license:
PolyVox: Low-level classes for storing and processing voxel data
Cubiquity: A higher-level voxel engine built on PolyVox
The main advantage (as well as freedom!) of this new MIT release is that users can attempt to compile the core Cubiquity library for new platforms whereas we previously only supported Windows, OS X, and Linux. You’ll be own your own here (there are no real build instructions), but we have had reports of it working at least on the iPhone.
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.
Well we’ve got some exciting news today – we’re pleased to announce that Cubiquity for Unity3D is now available for free! It has always been free for non-commercial and evaluation use, but we are removing this restriction so that you can use the system for commercial purposes too. This is effective immediately, and you can download Cubiquity for Unity3D via the asset store or from BitBucket.
Cubiquity let’s you create natural voxel terrains and edit them in real time, or build your worlds from millions of tiny colored cubes.
So what has led to this decision? Well, there are a number of factors at play here:
We’ve recently been doing some work in PolyVox to switch the ordering of voxel data from linear order to Morton order. This work is now complete, and in this relatively technical post I’m going to highlight a couple of the interesting tricks which we came across while doing it. Hopefully these will be beneficial to other people working on the low-level details of voxel engines.
Like many voxel engines, PolyVox allows volume data to be broken down into a number of ‘chunks’. The primary advantage of this approach is that not all the data has to be loaded into memory at the same time, and we can instead load and unload chunks on demand. Note that this is an implementation detail of the our ‘PagedVolume’ class, and algorithms which operate on the data (mesh extractors, raycasting, etc) are not aware that the data is stored in this way.
The size of each chunk can be specified by the user (with the ideal size depending on a number of factors) but typically contain 32³, 64³, or 128³ voxels. The ‘ordering’ of these voxels refers to the way they are laid out in memory, and two possibilities are shown below for the 2D case. The linear ordering is the easiest to understand and can be traversed with a simple nested for loop, but the Morton ordering brings numerous benefits in terms of locality of reference, ease of downsampling, and increased compressibility.
Linear ordering (left) vs. Morton ordering (right)
However, the purpose of this blog post is not to explain the benefits of Morton ordering, nor to describe how (x,y,z) positions are mapped to locations on the Morton curve. For this we refer you to the Wikipedia article and the excellent blog posts by Jeroen Baert and Fabian Giesen. Instead, we wish to highlight a couple of optimizations which were useful in our implementation.
Today we are pleased to announce that a new version of Cubiquity for Unity3D has been released on the asset store. Version 1.2 brings performance and memory gains, adds support for 64-bit architectures, includes faster transfer of mesh data from the native library, and provides experimental heightmap import.
Our new example map shows a city modeled at a resolution of 512x512x64 voxels which can be destroyed in real-time (complete with physics). Data courtesy of William Rigby and the game ‘Build&Shoot’).
We have improved both performance and memory usage by introducing an octree to reduce the number of mesh chunks which are active at an given time. We’ve combined this with a sophisticated time-stamping system, which allows us to minimize the amount of work required to synchronize our internal representation with Unity’s scene hierarchy. The city map shown above loads in just a few seconds and runs smoothly with destruction and physics enabled.
We have also replaced our ‘ConvertToVDB’ and ‘ConvertToImages’ tools with a single general purpose tool called ‘ProcessVDB’. This provides experimental support for importing heightmaps as terrain volumes – experimental in the sense that it seems to work well but needs some refinements to the workflow.
This map was created using the new functionality to import from a heightmap. Once in the editor the usual sculpting tools can be applied to create caves and overhangs, or to apply materials and textures.
The licensing model hasn’t changed – you can use the system free for non-commercial and evaluation use, or for $200 (per-seat) you can buy a commercial license through the Unity asset store:
For those of you who are waiting on the integration with Unreal Engine 4, I spent some time with Matt over Christmas and saw that the system is indeed progressing nicely. Both the smooth terrain and ‘colored cubes’ volumes are largely working though integrating with the editor and blueprint system is a lot of work. We both have only limited time so there’s not currently a set schedule for the initial release, but keep an eye on the forum thread for the latest updates.
It’s been a quiet few months, but we’re happy to say that a new version of Cubiquity has just landed on the asset store. Version 1.1.3 is primarily a bug-fix release but also adds a few new features such as normal mapping of the colored cubes volumes and an example showing how to build and save voxel databases from Unity scripts.
Colored cubes can now have custom diffuse and normal maps applied. Shiny!
We’ve also tidied up a lot of stuff internally, for example all of our PolyVox enhancements have been merged back into the main develop branch and we have overhauled the Cubiquity build system. Perhaps not so exciting for end users but still an important step as development can move a bit more smoothly from here on.
Licensing is the same deal as before – you can use the system free for non-commercial and evaluation use, or for $200 you can buy a commercial license through the Unity asset store:
Looking forwards, the main request has been for larger volume support and better performance with less memory. In other words, we’re going to put some work into optimization and possibly providing some tools (importers, etc.) to help create the larger environments.
We’ll try not to go another three months without posting, and I think the upcoming changes should give us plenty to show off!
Update 3rd Sept 2014: Version 1.1.3 is now out with collision and physics fixes for smooth terrain. The links above have been updated.
Hi all, I’m pleased to announce that we’ve just made the first official release of Cubiquity for Unity3D, and that it’s now available to purchase from the asset store. This is a huge milestone for us and comes just over a year after we first showed our work on Unity3D integration.
The asset has been released at the $200 price point which we’ve been throwing around for a while now, and it remains free for non-commercial and evaluation use. Anyone who has been following our regular snapshots will already have a good idea what the system does, but the uninitiated can get the latest free version below:
This is really just the start of the journey for Cubiquity and we have plenty of ideas for how we want to further develop the system over the coming months. But that can wait for a future post – for now we’d just like to thank everyone who has spent time testing our system, giving feedback, and providing encouragement. You’ve helped get Cubiquity for Unity3D to where it is today!
I’m pleased to announce that today we’re releasing a new snapshot of Cubiquity for Unity. This version finally adds support for both OS X and Linux, and also includes a number of smaller improvements regarding stability, user interface and documentation.
Cubiquity for Unity running on OSX
You can download this latest snapshot using the links below (remember to check our YouTube channel for examples of what Cubiquity for Unity can do):
One of the main appeals of Unity is the ability to target multiple platforms from a single code base, and so we’ve always been keen to bring this functionality to Cubiquity as well. The process is more complex than for other Unity assets because Cubiquity is a native code library written in C++, and so it needs to be compiled (by us) for each platform which we want users to be able to target.
Matt kicked off the work a few weeks ago by compiling Cubiquity for Linux. This involved writing some CMake scripts, testing the process of loading dynamic libraries on Linux, and fixing some OpenGL issues. All of this helped lay the foundations for the OS X version, which then required extra tweaks to the the build process and handling of log files. But eventually it came together 🙂
We haven’t added any significant new features beyond the improved platform support, but there has been more work on polishing the API and particularly on documenting it. The final release will naturally include API docs and a user manual to get you up to speed quickly, but we’re also hoping the API will be simple enough to be intuitive.
We currently expect that this is that last snapshot which we release before we put Cubiquity on the Asset Store! The end is now really in sight and we hope to be live by the end of this month.