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.

New Cubiquity for Unity snapshot with OS X and Linux support

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.


Cubiquity progress update – volume transformations and materials

Time for another Cubiquity update! Over the last two months we’ve put a lot of work into polishing and refining Cubiquity in order to make it fit more naturally with the Unity way of doing things. In particular, voxel terrains now behave much more like other Unity objects in that they can be translated, scaled and rotated, and can also participate in transformation hierarchies. See the video below for an example (the moon orbits the Earth while the Earth orbits the sun):

As you can see this adds a lot of flexibility to the system, and it’s really starting to feel like things are being done ‘the right way’. I can imagine the solar system example above could be ‘gamified’ quite nicely, e.g. you could defend a voxel-based Earth from a barrage of voxel-based meteorites. And I’m sure there are plenty of more interesting game concepts which you guys can think up 🙂

As well as transforms, the video also shows that the material system is much more flexible now. You can still use the TriplanarTexturing material but it’s really just an example. The ‘planet’ material (used for the Earth in the video above) shows how textures can be applied from a cube map, and we have ideas for other approaches too.

Actually setting the material is also more natural now. We’ve introduced ‘VolumeRenderer’ and ‘VolumeCollider’ components which are conceptually similar to their mesh-based cousins, and so the material can be set just by changing the ‘material’ property of the ‘VolumeRenderer’ component. There’s still some work to do with these but it’s starting to take shape.

Sounds great, but when is the release?!
We were originally hoping to be on the asset store by the end of last year, and we’re clearly behind in that regard. This isn’t due to any particular problem or road block – it’s just a case of everything taking a bit longer than expected. But that’s why we put out these snapshots, so that you guys can see the progress and start playing with the system.

As it currently stands, we expect to put out one more snapshot in about a month, and then release at least the free version of Cubiquity on the asset store about a month after that. It’s not clear if the paid version will go live at the same time – we may have a testing period with just the free version available. At any rate the paid version won’t be very far behind.

Of course, being on the Asset Store is really just the start… we have many interesting plans for the future of this system 🙂


Plans for PolyVox in 2014

The last year has seen a heavy focus on Cubiquity-related news but PolyVox has also been moving along in the background. Here’s a few examples of things we have added over the last year:

  • Volume wrap modes (out-of-bounds voxel access can now clamp, repeat, border, etc).
  • Improved error handling and logging system, and also timers for performance analysis.
  • Pluggable compression and paging support for the LargeVolume class.

None the less, with Cubiquity in the foreground we want to ensure PolyVox does not stagnate, and this Christmas has provided chance for Matt and I to sit down and discuss how to achieve this.

It has become increasingly clear to me that the effort involved in developing a mature open source project is significantly greater than developing a young private project. For example, within Cubiquity I will routinely add, delete, rename, or refactor large swathes of code, safe in the knowledge that I am the only person affected, and that I can roll back large architectural changes without having to justify it to anybody.

In principle PolyVox should be the same – the license clearly states that it’s provided ‘as is’. But in practice there is at least some degree of moral obligation to consider backwards compatibility, communicate significant changes, update the documentation, update the language bindings, test on multiple compilers, etc. This adds a degree of inertia to the project which reduces enthusiasm for making changes, especially in light of having less free time than was previously available.

So, how are we going to fix this? Basically we are planning a few things:

Stop worrying (too much) about API stability: I recently added support for wrap modes and bounds checks when accessing voxels outside of the volume, but this would have changed the interface to the ‘getVoxelAt()’ functions. Therefore I left these functions as they were and added new ‘getVoxel()’ functions. It’s technically backwards compatible, but is also confusing, error-prone, and adds more code to test. In the future we’ll just change things when we feel they need to change.

Embrace C++11 and drop support for older compilers: Matt has long been an advocate of embracing C++11 within PolyVox, and previously we said it would be used after the next stable release. Instead we will start using it now wherever we feel it makes sense. This will result in older versions of Visual Studio being unsupported, and I would guess that VS2012 would become the required version of Windows.

Cut down the amount of code in PolyVox: Some of this will come from the C++11 support – for example we can remove the Boost fallbacks and compiler detection from CMake, replace PolyVox::Array with std::array, etc. Also, the numerous volume, block, and array classes overlap too much in terms of functionality, so we will make some reductions here. We may also strip out the built-in compression code and just let users implement this with an external library.

Simplify build system: We’ll probably drop support for building PolyVox as a dynamic (shared) library, as it’s really not clear that it makes sense when PolyVox is almost entirely header files. We may go header only if we decide it makes sense, as this would then remove the need for people to build PolyVox at all.

Note that we are no longer planning to release a new stable version before commencing work on the above. This may have some impact on users who are trying to keep up with the latest version in Git, but practically speaking the changes are going to be spread out over many months. We’ll also try to keep the develop branch in a relatively stable state and continue to run nightly tests, etc.

PolyVox is still a key piece of software for us as it provides the foundation for Cubiquity, so we do hope these changes help keep it moving forward and allow us to add some of the new features we’ve been thinking about.


Cubiquity for Unity3D progress update (Nov 2013)

Here’s the latest update and snapshot showing our progress on Cubiquity. Since the last release a lot of our work has been internal (API, file format, etc), but we’ve also added collision meshes for the (smooth) terrain volumes, added an example of generating procedural terrain, and added an example of creating colored cubes mazes from bitmaps. See the video below:

The download link is at the bottom of this post. Overall the system has changed quite a lot, so if you were using a previous version then you should take care when upgrading. Be sure to back up all your files so you can revert the upgrade if need be. You will have to make significant changes to your code and any old volumes you have will not be compatible with this new version.

New file format
Previously Cubiquity would store all the data for a given volume in a user-specified folder, with each chunk being stored as a separate file which could be paged into or out of memory on demand. The new version instead makes use of an SQLite database to store the voxel data. It’s a lot tidier as everything is in a single file, and it should also bring performance and robustness improvements. However, the file format is not finalized yet so please don’t depend on it. Future versions of Cubiquity may not be able to load these files!

New licensing model
This is the first snapshot to be released under our new licensing model. It’s free for non-commercial and evaluation use (see LICENSE.txt for full details) and hard-coded limitations on volume size have been removed. Practically speaking there are still technical limitations, but those will lift in the future as we optimize the system. Please note: there is currently no way to create large volumes through the user interface but you can do so through code.

API improvements
The ColoredCubesVolume class has been split into ColoredCubesVolume and ColoredCubesVolumeData, and a similar split has been made for the TerrainVolume. The idea is to correctly separate responsibilities. ColoredCubesVolume is a component which handles rendering, interaction, etc while ColoredCubesVolumeData is just the data it operates on and can be serialized to an asset (probably… not really tested). More splitting of responsibilities will probably occur in the future. Please look at the code for the examples discussed in the video to see how you should now construct volumes from code.

Things that are missing
Some functionality may have got lost in the refactor, in particular it is no longer possible to import a colored cubes volume from a stack of images. We plan to bring this back in the future as a separate command line tool so that we can also demonstrate the Cubiqity C API. So if you really need this functionality you might want to hold off upgrading for a while.

Download the snapshot
You can download the snapshot corresponding to the video with the link below. Just extract the zip file and import the .unitypackage file into Unity. Be aware that it’s still Windows only at the moment.

You can also get the latest version of the code directly from our BitBucket page (may be unstable):

We hope you enjoy the new system! As always you can ask any questions on our own forum or on our ‘Works in Progress‘ or ‘Assets and Asset Store‘ threads on the Unity3D forums. Do let us know if you have any feedback 🙂


New licensing scheme for Cubiquity for Unity3D

Today we have some very important news regarding the future licensing of Cubiquity for Unity3D, and in particular there is a change to the way that the free version can be used. Please read the information below carefully!

Free and paid licenses

So far we have said that there will be both free and paid versions of the system, with the free version allowing both commercial and non-commercial use but being limited in terms of features and volume size. As of today we are changing this – the free version will be for non-commercial use only but we will remove all feature and size limitations.

In other words, you will now be able to get the full and unrestricted version of Cubiquity at no cost, providing that you are using it for non-commercial purposes. Even if you are using it commercially you will still be able to use the free version for evaluation purposes – i.e. you can make sure that Cubiquity is right for you before you commit to buying it on the asset store.

The exact terms and conditions are available in LICENSE.txt in the Git repository.

Why is this changing?

The free version of Cubiquity is intended to serve a number of purposes and should benefit both users and ourselves as follows:

  • It puts the system into the hands of those who otherwise could not afford it.
  • It generates publicity and helps promote the system.
  • It allows users to evaluate the capabilities of the system before they commit to a purchase.
  • It allows testing and feedback from a larger user-base which results in a better product.

Basically, we feel that all of the above points are better served by the new licensing model rather than the old one.

How and when does it take effect?

The license file has been added to the Git repository and takes immediate effect. Over the next few days we will take steps to make sure that the new license is clearly visible, and will then raise the size restrictions which are currently in place (though technical constraints still remain). Lastly we will produce a new snapshot in the next week or two.

But I preferred the old license! I’ve already started using it on a commercial project!

Don’t panic, we’re not looking to catch anyone out here. If you have already started a project with Cubiquity and you were intending to commercialize it then just send us an email (support@volumesoffun.com) with a brief description of what you have done so far. We’ll acknowledge that you are working on it and you can continue to be bound by the old conditions. However, you’ll also be bound by the old limitations so do consider whether you’d rather switch to the new license for better features and bigger volumes.

Ok, great, but what’s the plan for the commercial licenses?

Well, we’re still working hard. Most of the features for the initial version are implemented but there is a lot of polishing to do. I think we’re still hoping to get it on the asset store by the end of the year, where the plan is to sell it as an editor extension for $200 per seat under the standard asset store license.

That’s not the end of the road though, we’re still only scratching the surface of where we want to go with this system. We’re also really pleased with the feedback we have received so far so please keep spreading the word!


Working with terrain textures in Cubiquity for Unity3D

Over that last month we’ve been improving the user interface and editing capabilities of our Cubiquity voxel terrain system. In our last video we demonstrated sculpting the shape of the terrain, and the video below shows how you can now paint materials onto the terrain as well.

As you can see, we’ve significantly improved the interface such that it is now quite similar to the one which comes with Unity’s built-in terrain. It offers many of the same features in terms of being able to select brush size and shape, and choosing from a variety of materials which can be painted onto the terrain. You get a similar marker on the terrain showing where operations will be applied and you can change texture settings such as scale and offset.

As always, you can get the latest version of the code from our BitBucket repository.

Overall we’ve very happy with the way this is coming together. At this point I think we’ve implemented most of the features which we want in place for the first release, and so we will now focus on tidying up the code and documenting the system. Then we’ll talk to those nice people at Unity about getting on the Asset Store 🙂


Sculpting smooth voxel terrains in Unity3D

Several months ago we demonstrated that Cubiquity supports smooth voxel terrain (based on Marching Cubes) in addition to the ‘colored cubes’ style voxels which we’ve been showing off more recently. Both of these styles are first-class citizens in the Cubiquity system, and so over the last couple of weeks we’ve started exposing this smooth voxel terrain to Unity3D as well. Here’s a video of real-time voxel terrain sculpting in action:

At the moment it is only possible to sculpt the shape of the terrain and not yet paint textures onto it. We do already support textures in Cubiquity (as seen here) so this will be the next thing which we expose to Unity3D. At that point the system will have most of the features which we want in place before releasing the free version on the Asset Store. We’ll spend a couple of months polishing the user interface and code and then submit it to Unity Technologies for approval.

For those users who are feeling more brave and don’t want to wait for the official Asset Store release, the functionality in the video is already available for testing in our BitBucket repository. You might also want to watch our previous ‘Introduction to Cubiqity for Unity3D‘ video first, and then follow up with the smooth terrain video above.

Hope you like it – feedback is welcome as always!


Cubiquity for Unity3D is now hosted on BitBucket

I’m pleased to announce that today we are bringing Cubiquity for Unity3D even closer to reality, as an early version of the code is now available on BitBucket. This means you are able to download and play with the system immediately, as well as follow progress and get access to new features as soon as they are implemented. You can use the system with both the Free and Pro versions of Unity3D.

To start playing with it you should clone the BitBucket repository or download the snapshot as a ZIP file:

The repository contains all the C# and shader code required to work with Cubiquity, and it also contains a copy of the Cubiquity native code DLL. However, it does not contain the the source code used to build the DLL as we are not making this publicly available. You can use the provided DLL for free for both commercial and non-commercial purposes, but the size of the volume is restricted to 256x256x256 voxels. In the future it will be possible to buy a license to raise this limit.

We’ve created a video which gives an overview of the system and shows how to perform basic tasks such as creating a volume, modifying it in the Unity editor, and interacting with it at runtime. The documentation is rather thin at the moment so the video is worth a watch:

Feel free to play around with it, though be aware that APIs and file formats are still subject to change as the project evolves.

What next?

The system is a little rough round the edges and needs some polish to bring it to a production ready state. However, before we get to this we intend to spend some time exposing the smooth terrain capability of Cubiquity as we have not yet tested this within Unity3D. We want to ensure that both terrain types (cubic and smooth) work with any patterns and paradigms we introduce.

Roughly speaking we would like to get the smooth terrain working by the end of September (we have an ulterior motive here which I’ll talk about in a later post), and then we’ll get to work on bringing it to a production ready state. We’re developing it in public so that users can test the system at any time, and can consider buying a license when ever they feel it has the features and capabilities they need.


More progress with the Unity3D integration

I’m pleased to say that we’re still making good progress on Cubiquity and it’s integration with the Unity3D game engine. Over the last few weeks we’ve imported a new map from the game Build & Shoot, integrated explosions from Unity’s Detonator package, and a got a new tank model (one that actually looks like a tank!) from the asset store. The results can be seen below 🙂

We’ve had loads of fun blowing stuff up so we thought you might like to try it for yourselves. You can download the standalone demo below (you don’t need Unity to run this):

Anyway, this project is really starting to take shape. We’re keen to get something in the hands of users as soon as we can, but we feel it’s still to early to put it on the asset store. Therefore we are currently planning to open up the code for this integration package and put it on BitBucket alongside PolyVox. This will let you download and play with early versions of the code, but it will still be dependant on the closed source Cubiquity.dll.

The Cubiquity.dll itself will also be free, but functionality will be limited unless you purchase a license. The primary restriction will be on the size of the volumes which can be loaded but the exact details haven’t been decided yet. We hope that this will encourage people to download and test the system, and then purchase a license if they feel it meets their needs.

Hopefully we can get the code out in the next few weeks so stay tuned!


Integrating Cubiquity with Unity3D physics

Time for another update on the Unity3D integration 🙂 Over the last couple of weeks we’ve been mostly focused on getting Unity’s collision and physics system working with the data which comes out of PolyVox/Cubiquity. You can see in this video it has come together quite nicely:

As you can imagine, it is spawning cube meshes to replace the destroyed voxels and then applyng forces to them to simulate the explosion. Unity’s physics system then takes over to handle the collision response and bounce the cubes around the terrain. The current implementation is not optimal as it just uses the rendered mesh as a collision mesh (there exist more efficient approaches) but for now we’re just trying to get the various pieces of the system in place.

If you want to play with this yourself then you can download the latest test build below:

Note that this is a Unity project so you’ll need Unity installed to run it. You then need to open the project, open the only scene, go to ‘Cubiquity->Import Colored Cubes Volume from VolDat’ from the main menu and then press Play.

I’ll try to provide a stand-alone test in the future but I need to work out some stuff about packaging resources first. In the mean time let us know if you have any questions or feedback.