Cubiquity - A fast and powerful voxel plugin for Unity3D

Over the weekend I got a little distracted from the terrain LOD work, as I was working on the heightmap importer and ended up tidying some of the other import code as well. This led to the setting up of some more tests and the Magica Voxel import test is kind of interesting:

​

This is the classic Menger sponge fractal, and it serves as a nice performance/stress-test because it contains a lot of detail and makes the greedy meshing difficult. Magica Voxel comes with a sample model of a level-4 Menger sponge which is 81x81x81 voxels. The image above shows 20 of these being instantiated into a single scene, and placed adjacent to each other to give the impression of a single level-5 Menger sponge of 243x243x243 voxels.

Of course, we can also view the Menger sponge(s) from inside:

​

One of the bottlenecks in Unity voxel engines is the time taken to build a collision mesh (rendering is easy by comparison!). Now, in practice you would not build a collision mesh for a shape this complex and would instead test against the raw voxel data (or some other game-specific approach), but again it serves as a nice stress-test. We find that it is indeed possible to destroy parts of the sponge and have the detached voxels bounce around the scene:

​

I wonder what kind of game environment you could make from a Menger sponge? Something Sci-Fi I think, like a Borg cube. Anyway it's fun to play with with fractals!

 

Hey there,

I was wondering, is there a public script on the tank video? Or maybe a pointer to how to achieve it?

 

The tank demo made use of a model purchased from the asset store, which meant I could not redistribute the whole project. I can dig out any of the code you are interested in but Cubiquity has also evolved a bit since then. Can you elaborate on what you are trying to achive and I'll point you in the right direction?

For the explosions there is a 'ClickToDestroy' script in the Cubiquity examples, and I used this in conjuction with the free 'Detonator' package for Unity. The map itself was imported from the game 'Build and Shoot' using Cubiquity's command-line importer.

 

Honestly, I just want to use UFPS and blow up cubes

 

Well then you are not far off You can start with 'Assets\Cubiquity\Examples\CubicTerrainExampleScene' which loads a simple map with the 'ClickToDestroy.cs' script already attached, so when you press play you can just click around the map. This script is just an example, so you'll want to understand how it works and modify it for your purposes.

Just ask if you have any questions.

 

I've read through it... it's intimidating man. Pretty much i need to ray cast the bullets and run DestroyVoxels?

EDIT*

Nope, that wont work, cause UFPS does not use any actual real bullet. It's just a hitscan. It detects what it hits, applies the decal, sound, and damage lol.

I read that unity's physics are just not good enough for that too?

 

The important part is the DestroyVoxels() function, which just takes the position of the voxels to destroy and a value for how big the damage radius should be. In the demo we get the position by doing a raycast when the mouse is clicked, but you can get the position a different way if you wish.

Does UFPS provide you with the hit-point, and/or is there a callback you can make use of? Focus on being able to just print out the hit point and then you should be able to add destruction once that is working?

The demo scene also has a 'VolumeCollider' component attached which just creates a standard Unity collision mesh, so I'd expect UFPS to be able to detect collisions with that.

 

Hey guys, just a quick heads-up that I've merged some more stuff into the develop branch

Firstly, there is now *experimental* support for LOD in the smooth voxel terrains. There are a number of issues regarding cracks and performance but we'll refine this in due time. You can configure LOD in the VolumeRenderer component by setting the lowest usable LOD level (defaults to zero - no LOD available) and the theshold for how far away chunks need to be for LOD to apply. Probably best to try it on the 'TerrainExampleScene'.

Although it has some issues I think it is quite promising. It doesn't only LOD each chunk, but also combines adjacent chunks at lower LOD levels to reduce the batch count (there is an octree behind the scenes). I intend this LOD feature to be in the next official release though it will still be flagged as experimental.

Secondly, we're replaced the command-line 'ConvertToVDB.exe' and 'ConvertToImageSlices.exe' with a single general purpose 'ProcessVDB.exe'. This can do import and export of volume data from external sources, and in the future it will have other functionality as well (resampling volumes maybe?). You can see the updated-but-horribly-formatted Doxygen input here. We'll obviously recompile the docs for the next release.

Let us know how it works out for you!

 

Playing with it here. Looks good so far. Performance seems much better. The Simple Terrain example has an issue where the game object already has the terrain components and it adds another set. Switching the script from AddComponent to GetComponent corrects that, which allows the carve component to work properly when added.

If possible, I would add a link to the develop gz to the asset store description? It took a bit of digging to find and was the reason I decided to focus more on Cubiquity.

 

Thanks, I've now fixed that. I wanted the script to demonstrate how to create a volume completely at runtime, so I've left AddComponent() in place and removed the components which were already in the scene.

I can't do this from the asset store page as Unity didn't allow it (I wanted to link to the non-commercial version). Maybe I can restructure the forum thread though. Over time the release process should become more streamlined anyway, and the master branch and asset store should follow the develop branch more closely.

 

So, I got it to print It's a hit sarg! lol

Code (CSharp):

1. f (Physics.Raycast(ray, out hit, Range, (IgnoreLocalPlayer ? vp_Layer.Mask.BulletBlockers : vp_Layer.Mask.IgnoreWalkThru)))
2.             {
3.  
4.             //ClickToDestroy desSc = new ClickToDestroy();
5.  
6.             //desSc.DestroyVoxels(no idea what to put);
7.             Debug.LogWarning ("Its a hit there sarg!");

Having trouble getting it to destroy the voxels though... Does the range variable detail how big the explosion will be?

 

Currently investigating an issue in the ClickToCarve where the carve bounds are being affected by blur? even though the radius/sphere/brush is small? The editor tools are working fine.

 

Yes, for the range you can just put 5 or 10, something like that. You will need to know where the hit occurs... now that you can print out when one occurs can you also print out the position? You can then just pass the x, y, and z components of the hit position as the first three parameters of the DestroyVoxels() method, and the range as the fourth.

I assume you are doing all this inside the 'ClickToDestroy' script?

I think I am aware of an issue here. Does it look like a crater, so the hole gets made but then the edges get raised?

I believe there is an issue related to precision and/or wrap-around. Cubiquity uses 8-bit uints to store voxel values and this might not be enough, I think it would be useful to switch it over to floats internally. This probably won't happen for a while though.

I think the issue only occurs sometimes, for example I haven't seen it much on the smooth terrain example scenes. I believe it is related to how sudden the density transition is. The example scenes go from full density to empty over a few voxels (maybe 10 or so) and I think this helps.

 

Hey guys,

I previously showed off the heightmap import I was working on, and I've now got color maps working as well. This means you will be able to make a terrain in an external application (World Machine, etc) and then import it into Cubiquity. The texture detail is low so it would probably be most appropriate for a game where you are flying or something, but overall I think it will be a useful addition:

​

Also, I've got a trial of Unity Pro at the moment which is allowing me to test out some of the nice effects. As you can see the Unity Pro water effect works great with Cubiquity

​

 

Hi, i have a big problem in Unity 4.6.1:

i want to use your asset for a test project but after import of your asset, i cant save any scene in my project. Is this a common bug?

Thanks

 

What happens when you try to save? Your scene should save properly, but if you have a Cubiquity volume then you may find it is immediately marked as unsaved again (i.e. the '*' appears in the title bar).

Cubiquity does not save the actual mesh data (this is generated when you open the scene) so it is discarded during the save process. After the save is completed it regenerates the mesh so Unity thinks the scene is modified again. I'm aware that the 'HideFlags.DontSave' should be used for this purpose but that leads to it's own problems: http://answers.unity3d.com/questions/609621/hideflagsdontsave-causes-checkconsistency-transfor.html

I'm also aware that the 'ISerializationCallbackReceiver' might help but I haven't upgraded to Unity 4.5 yet to test it.

For now you just have to live with the scene being marked as dirty even if it is not, but do let me know if I am misunderstanding your problem and if save really is failing in some way.

 

Thanks for your fast response.
I did a lot of tests. It simply dont save any changes i made in the whole scene. I hadn't even created a volume - i just imported the unity package and saveing stopps working. It stays *-marked and after a reload all my changes are gone.

Sorry for bad english

Edit: its seems to be a problem with dll includeing. If i delete all scripts from cubiquity except the scripts folder and delete the impl/installation.cs saveing starts to work(after a unity restart - i guess the awake function loads the dll in volumedata). Maybe it helps you.

 

Sounds very strange... I wonder if anyone else has experienced this problem?

You're running Unity Unity 4.6.1 but can you say which version of Cubiquity you are using? I guess 1.1.3 from the .unitypackage file? I also assume you are on Windows?

If you are feeling brave you could try the version of Cubiquity which is in development - lots has changed so there is some chance it has been fixed. You can get a .zip file of the latest version here:

• https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/get/develop.zip

That zip file contains an 'Assets' folder. Try creating a new project and then copying the contents of 'Assets' from the zip file into the 'Assets' folder of your new project. Does this make any difference?

 

Hi David,

Do you happens to have a release notes of what has changed since the latest package? I am watching this thread intently and currently having fun playing with voxels.. I created a 'voxel photo' of my son using the maze sample and the result is quite hilarious...

 

exactly. I've also tried older versions (preview 6/5 and preview 4.) Preview 6 and 5 had the same Problem - Preview 4 saveing worked again. But i cant use preview 4 because it seems to has a shader problem with the newest Unity version - all Volumes stay dark - no matter what kind of light im using.

I've tried this as you mentioned. The Problem still occurs. All Changes are gone after a reload of the scene.

Now i've tried a different way: I've loaded one of your example scene "CubicTerrainExampleScene" - changed some Voxel on the example and saved. This seems to work. I only can save Volume Changes, but no other Object changes i did in my scene. Like toggleing light or something.

 

I have updated to Unity 4.6 and can now reproduce this problem It works correctly in Unity 4.5 so something in Unity has changed. Thanks a lot for bringing it to my attention! It's a significant issue which will need to be fixed before the next release, but I'm not sure quite when I'll look at it. Should be in the next couple of weeks.

Logged here: https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/issue/71/saving-broken-in-unity-46

The most visible change is the addition of LOD for TerrainVolumes, though many other changes are going on behind the scenes in both the C# scripts and the core library. I just updated the changelog for ver 1.2.0 (unreleased) here:

• Changelog

 

Thanks for your response and support. I hope you can fix and update this - good luck. I really like cubiquity - its exactly what im looking for to create cube/voxel terrain in-editor and not just generate them randomly.

Hope to hear again from you soon .

 

I'm pleased to say the broken saving on Unity 4.6 has now been fixed. If you are using Unity 4.6 then you will need to apply this patch to get saving to work again:

• Unity 4.6 broken save patch

Alternatively you can pull it straight from Git (switch to develop branch!), or download a zip of the develop branch. It's a pretty serious issue, but with Christmas coming up I won't be able to push a new release to the Asset Store until January.

@HockeyMarv - Thanks a lot for reporting this!

 

It works - good job! Thank you so much for your fast support. Wish you a happy holiday season

 

will there be round/sphere voxels in the future?

 

I'm afraid not - the cubic voxels are not actually drawn as individual cubes, but instead a single mesh is constructed which simply looks like cubes. It would be quite difficult to make these look like spheres instead.

 

Any progress regarding mobile support? Might be more usable now that we have LODs and the recent performance improvements feel substantial.

 

Unfortunately don't think mobile support will come anytime soon. The performance might be good enough but it's a big commitment in terms of support. We don't have access to iOS at the moment, and only have a couple of Android devices. So I think we'll be focused on improving and refining the desktop version for the foreseeable future.

 

Why volume sizes are limited? I get that it might be out of performance reasons, but can't Cubiquity split it automagically into chunks once it's too big?

Also could you add support for textured cubes, so Minecraft-like landscapes will be possibly and not only CubeWorld? Plus, could smooth voxels algorithm be improved so it could do sharp edges? Regular Marching Cubes can't do that, but I've seen voxel games that can (Blockscape and Landmark comes to mind).

 

Cubiquity is currently similar to the standard Unity terrain in that it always renders the whole volume (though not all the data is kept in memory at all times). This is because our focus has been on hand-crafted or imported volumes rather than procedurally generated ones. I expect that in the future we will indeed move towards only rendering the area near the player, and eventually to infinite volumes as well.

There is no real plan for this at the moment, as there are just too many other features to work on.

Eventually we might add support for Dual Contouring but this is quite a long way off. The algorithm itself is straight-forward but the editing tools will be quite complex. In the shorter term I expect we will add displacement mapping which should help the smooth terrain to look more realistic.

 

Hey, I just bough Cubiquity and quite happy with the performance. However I had to manually copy the libraries to Plugins/x86 . Doing this I realized that there seem to be no x64 version of the library included (which is mainly an issue for Linux). I guess the MacOS library is already a universal binary? Regards, Felix

UPDATE
I created two issues:
https://bitbucket.org/volumesoffun/...e/72/unity-pro-libraries-not-put-into-plugins
https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/issue/73/provide-x86_64-builds-of-libraries

 

Thanks for the purchase!

To be honest I did not realize that Unity 4 supported 64-bit builds, as I thought that this was to be a feature of Unity 5. But it seems that Unity 5 introduces a 64-bit editor, and that standalone builds can already be 64-bit with Unity 4. So my apologies for this oversight.

However, in principle we can make a 64-bit build and a user on our forum already confirmed that it works (for Windows at least). But to integrate this properly we need to disambiguate the names and make sure that the correct library is copied. I'll try to take a look at it in the coming week.

Note that Cubiquity is not actually a plugin in that it does not make use of the Unity plugin API. Instead it is simply a native code library which we call using the standard .NET P/Invoke methods. Therefore we don't place it in the plugins folder but instead copy it to the root of the project. Using the plugins folder is possibly ok on Pro (as it will also be in the path), but this approach doesn't work with Unity Free.

 

Thanks for the quick reply!

Right now we're quite happy with Cubiquity and even got it working smothly with the A* asset:

Code (CSharp):

1. [RequireComponent(typeof(AstarPath))]
2. public class TerrainVolumeAstarGridUpdater : MonoBehaviour
3. {
4.     private AstarPath _graph;
5.  
6.     public TerrainVolume Terrain;
7.  
8.     public void OnEnable()
9.     {
10.         _graph = this.gameObject.GetComponent<AstarPath>();
11.  
12.         if (this.Terrain == null)
13.             throw new Exception("missing terrain");
14.     }
15.  
16.     public void Start()
17.     {
18.         this.Terrain.OnMeshSyncComplete += OnMeshSyncComplete;
19.     }
20.  
21.     private void OnMeshSyncComplete()
22.     {
23.         _graph.Scan();
24.     }
25. }
26.  

Currently the issue left for me is that I can't find a way to disable the debug window. I already did look throughout the documentation. Can you help here?

 

Great, I'm glad to hear it's working for you

You mean the overlay which states whether the mesh is syncronized? You must be running the develop branch where I added this for my own testing purposes. I didn't add a way to disable it yet but you can just comment it out the whole of Volume.OnGUI():

Code (CSharp):

1. public void OnGUI()
2. {          
3.     GUILayout.BeginArea(new Rect(10, 10, 300, 300));
4.     GUI.skin.label.alignment = TextAnchor.MiddleLeft;
5.     string debugPanelMessage = "Cubiquity Debug Panel\n";
6.     if(isMeshSyncronized)
7.     {
8.         debugPanelMessage += "Mesh sync: Completed";
9.     }
10.     else
11.     {
12.         debugPanelMessage += "Mesh sync: In progress...";
13.     }
14.     GUILayout.Box(debugPanelMessage);
15.     GUILayout.EndArea();
16. }

 

Thanks! I actually ran in a more problematic issue. We're using Perforce and when editing a terrain the .vdb file does not get checked out and all changes will be lost!

From my POV editting should either be disabled, or the file should get checked-out. I created a ticket including a link to the unity source provider documentation:

https://bitbucket.org/volumesoffun/...e/74/terrain-volume-database-vdb-does-not-get

We'll be checking in those files as writable, for now.

Regards, Felix

 

I can see that it is somewhat unexpected that you are able to edit a 'read-only' volume, even though the changes cannot be saved. This behaviour is actually useful at runtime when you want players to edit the terrain without modifying your original assets (or even when running from a read-only filesystem), but in editor mode I agree that at least a warning/error should be given and the editing controls could also be disabled.

I'm reluctant to hook in the Unity VCS stuff though because I don't have access to either Perforce or Unity Pro, so I'm unable to actually test it. It sounds like you at least have a work around by checking the files in as 'writable', or by manually checking out the files you want to work on?

 

Hey mate, Any potential for unity 5 port?

Currently getting this error (even though the DLL is in the root):

 

I can't support Unity 5 properly until it is officially released, as I don't have access to the beta. However, at least two users have told me that Cubiquity does work with Unity 5, except that the smooth terrain shader is broken.

My best guess would be that you are using the 64-bit editor, and that it can't load the 32-bit DLL? Just a couple of days ago I started adding 64-bit binaries to a Git branch called 'feature/x86-64_support'. I've only done windows so far but you can find the new 64-bit DLL here:

• https://bitbucket.org/volumesoffun/...SDK/Windows/x86-64/?at=feature/x86-64_support

Edit: You can download and use that branch or just grab the DLL and overwrite the version in your streaming assets folder. But don't just copy it straight to the root, as cubiquity wil notice that it doesn't match the version in streaming assets and will 'update' it for you (with the 32-bit version which you don't want).

 

Hi all,

There have been several questions recently regarding a 64-bit build of Cubiquity. I'm happy to say that 64-bit versions of Cubiquity are now available for all desktop platforms in the Git 'develop' branch, and will be part of the next official asset store release.

Note that we still only support Unity 4, but this is also a step towards supporting the 64-bit editor of Unity 5 once it is released.

 

Hey, I continue to get the message that Cubiquity is not using the unsafe version of the library. The 'unsafe' directory contains a readme pointing to the 'Installation' chapter of the manual. However, that chapter does not say anything about the unsafe version (both pdf and online). Could you please elaborate on this? Regards, Felix

 

The Terrain Volume Collider does not seem to work in the scene view. I can't figure out why as the component itself seems to be running/executing at design-time. (At runtime this works just fine.)

https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/issue/75/design-time-collider

This is required for tools like Quick Brush to work as they rely on a working collider.

Regards, Felix

 

Support for using unsafe code was added fairly recently and only exists in the develop branch - it hasn't been released to the asset store. This is why you couldn't find it in the documentation (it exists in Installation.cs but the docs won't get rebuilt until release). Here's the relevant snippet for you:

"Cubiquity for Unity3D is built on top of a native code (C++) library which handles most of the heavy-lifting behind the scenes. In particular, it is responsible for generating the mesh representations of the voxels which are used for rendering and collision. These meshes need to be passed from the unmanaged native-code world of Cubiquity into the managed-code world of C# and Unity.

The C# language provides (at least) two ways to perform this communication. The first is is via Marshalling, in which the .NET runtime takes care of copying the arrays of indices and vertices into its own managed memory. From here we can perform some required decompression and then pass the data on to Unity. The second approach is to make use of the 'unsafe' keyword to enable pointers and direct memory access in our C# code, so that we can directly read from the memory owned by the native code library.

The second approach is faster, cleaner, and is what we recommend. The Cubiquity library is already native-code and so managed-only targets such as the webplayer are already unsupported. However, there is a catch. Using unsafe code requires a special '-unsafe' flag to be passed to the C# compiler, and in Unity this requires editing some project files. We don't want to tamper with users projects and so by default this feature is switched off unless you enable it.

Passing custom compile flags is done by placing them in '.rsp' files in the Assets folder. The exact name of the .rsp file depends on the compiler being used as described at the bottom of the Platform Dependent Compilation section of the Unity manual. In our case we are only concerned with the C# compilers used by the editor and standalone player. If you do not already have .rsp files in your Assets folder then the easiest approach is to copy the sample files which we provide in the Assets/Cubiquity/Unsafe folder (only copy the .rsp files - corresponding .meta files will be generated automatically). If you do already have conflicting .rsp files then you will need to manually add the required compiler switches to them. These switches are:

-unsafe -define:CUBIQUITY_USE_UNSAFE

The first of these enables unsafe code for the compiler, and the second tells Cubiquity for Unity3D that this mode is available so that it can use the correct code path.

Note: You will need to trigger a rebuild for these changes to take effect. The easiest way to do this is to modify (or touch) one of your .cs files."

I'll have to look into this properly tongight, but it looks like I disabled it on purpose in at least OctreeNode.cs:

Code (csharp):

1. if ((volumeCollider != null) && (Application.isPlaying))

I didn't think there was any reason to have colliders in edit mode but it seems I was mistaken. Colliders are slow to build so I didn't want them if they weren't needed. But I guess this can just become an option on the VolumeCollider component.

In the mean time you might just be able to comment out the second condition in the line above?

 

Hi, thanks for both the unsafe manual and the design-time collider fix. Both worked like charm! Thanks for the awesome support!! From my POV we got all the features we need covered for production . Regards, Felix

 

@flxk - No problem, I'm really glad it's working out for you. And thanks for our first review on the asset store!

 

Hi guys, I recently posted some new screenshots on Twitter and realised I forgot to post them here. I've been experimenting with a new test map which was imported from the game 'Build and Shoot'. This particular map is under a Creative Commons license so we'll be including it as an example in the next release (it's already in the develop branch):

​

The original is by William Rigby and can be found here:

• http://buildandshoot.com/viewtopic.php?f=8&t=913

This map is pretty complex and much larger than the 'Voxeliens Terrain' map we were using before. It's 512x512x64 voxels and the interiors of all the buildings are fully modelled. It works with dynamic lighting/shodows and you can destroy the map in real-time as well

 

Hi David,

Any chance we can get a webplayer for this build?

 

Hi,

Just tried to install the demo from the website and I'm getting this error when I start up any of the example projects.

DllNotFoundException: CubiquityC
Cubiquity.Impl.CubiquityDLL..cctor () (at Assets/Cubiquity/Scripts/Impl/CubiquityDLL.cs:32)
Rethrow as TypeInitializationException: An exception was thrown by the type initializer for Cubiquity.Impl.CubiquityDLL
Cubiquity.ColoredCubesVolumeData.InitializeExistingCubiquityVolume () (at Assets/Cubiquity/Scripts/ColoredCubesVolumeData.cs:126)
Cubiquity.VolumeData.get_volumeHandle () (at Assets/Cubiquity/Scripts/VolumeData.cs:174)
Cubiquity.ColoredCubesVolume.Synchronize () (at Assets/Cubiquity/Scripts/ColoredCubesVolume.cs:114)
Cubiquity.Volume.EditModeUpdate () (at Assets/Cubiquity/Scripts/Volume.cs:216)
UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorApplication.gen.cs:268)

Any ideas? I'm using Unity 5b18.

 

Unfortunatly not, Cubiquity does not support the webplayer because it is based on a C++ native code library. It is only possible to target desktop platforms (Windows, OS X, Linux) at the moment.

I'm afraid we haven't added support for Unity 5 yet though we will do so once it is released (wish I knew when that will be!). Until then you can only use it with Unity 4.

 

Doh! Sorry, completely forgot.

 

Hey guys,

I've decided that I should really try to get a new release out in the next couple of weeks. Since the last release I've been working on heightmap import and LOD support as large features, but I've also added lots of small features such as bug fixes, optimizations, examples, 64-bit support, 'unsafe' mode, etc. I'd like to get these improvements pushed to the asset store even though the larger features are still work-in-progress.

So, I'm going to spend a few days getting things in a sane state in the develop branch and will then *temporaily* disable the LOD support. Although it kind of works I don't feel it's ready for release. I'll then reenable it in the develop branch after the release is done.

I'll leave the new heightmap import in place because it's fairly harmless even though it's not quite polished yet. I'll keep you all updated as this progresses.