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!

This entry was posted in Uncategorized by David Williams. Bookmark the permalink.

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.

9 thoughts on “More progress with the Unity3D integration

    • Hi Ian,

      There is no real timescale for a finished version of the library. Instead, we intend to make an alpha version publicly available in the coming few weeks, and then continue to develop it in public view. People can simply purchase a license once they feel it is becoming useful to them.

      There will always be a free version with limited terrain size. Support for larger terrain will cost about a few hundred USD, though the exact available sizes and price points are not finalised yet.

    • Hi Ian, the initial version of the code should be in BitBucket later on this week. The C++ source code to the Cubiquity dll will not be publicly available, but all the C# and shader code for Unity will be included, as well as a copy of the compiled Cubiquity dll. The dll is limited to a maximum volume size of 256x256x256 (larger volumes will be available in the future with a license).

  1. Really cool project… thanks for sharing this. I tinkered with it this weekend and tried to simulate water but it doesn’t seem to like algorithms that add new voxels much. If I add a voxel to an empty space the color value gets corrupted unless it’s 255, and if I add a lot of new voxels then Unity crashes with memory errors. Any thoughts?

    • Thanks for the feedback!

      When you say the color has to be 255, do you mean the alpha? The system does not (currently) support transparency so alpha value must be zero or 255. The alpha channel is present in case we support transparency in the future, but we should add a warning to stop people using it now.

      There are known memory leaks when modifying the terrain, so if you are modifying every frame (for water simulation) then there may be memory errors. We have to fix these leaks before making a proper release.

      For water simulation could you consider particle-based fluids (e.g. using Fluvio for Unity) and then drawing each particle as a cube snapped to the nearest integer position in the vertex shader? This might be an interesting alternative to cellular automata based approaches (though I haven’t tried it).

      Glad you like the project anyway 🙂

  2. Thanks that’s interesting… I will have to look into Fluvio.

    I’m setting the alpha value correctly (to 255) and I tried to use the blue value to indicate water content of a cell. So 0 is no water and 255 is full of water.

    The bug seems to be that setting the blue content to a byte value less than 255 does not work correctly. Often it seems to set the value to a lower number… is there some compression or something going on with the color values that could cause this? It’s hard to tell without having access to the engine code. I tried cellular automata approaches on existing voxels and setting new ones, and found the same problem either way. In the end I literally wrote code that set the color value and immediately read it back, discovering that it had changed and was not set correctly hence my suspicion that this is an engine problem.

    I notice in your code you add all the particles you want to remove to a list and then remove them later and I wondered if that was too avoid an issue like this? I assume your plan is for the engine to allow users to write cellular automata code for simulations like Minecraft lava?

    I ran into the memory problems too (Unity crashed a few times).

    Any idea when you plan to make a proper release?

    Keep up the great work! 🙂

    • Ah, sorry, I should have said (and documented…) that colors are quantized to 16 bits per voxel. This mean the color you read back can be slightly different to the color you wrote. We do this to make adjacent blocks more likely to be identical, which helps RLE compression and polygon reduction.

      Also, some per-voxel noise is added to cover up this effect (and make it look nicer I think). You can disable this in the fragment shader.

      The two-pass removing of voxels is because each voxel checks its neighbours to decide whether to spawn a cube when it is destroyed. That is, we only spawn cubes for surface voxels. But deleting voxels may make previously hidden voxels now become surface voxels. so the first pass identifies all surface voxels in range of the explosion, and the second pass deletes all voxels in range of the explosion and spawns cubes for the previously-identified surface voxels. I hope that is clear?

      I think cellular automata approaches should be possible but the memory leaks will have to be fixed first. I hope to get the free version in the asset store by the end of the year (hopefully sooner, depends how much polish we add!).

  3. Ah that explains it. I would consider making that optional in the release version or supporting a method to add additional data to each voxel. Thanks!

Leave a Reply

Your email address will not be published.