Voxels! - Introducing Cubiquity, a voxel plugin built with C++ and PolyVox

Right, it was a little slow coming but our video is now up and shows sculpting and painting of the voxel terrain! Check it out below:

We're on the home run now - most of the features we want for the first release are now implemented so it's largely a matter of polishing, documenting etc. I expect it will still be a couple of months before the official release but there's always the Git version in the mean time, and the snapshots should keep coming.

 

Just a heads-up that we're released a new snapshot including this texturing support. Full details in our 'Assets and Asset Store' post.

 

Is it possible to save out the smooth terrain data while in play mode and load it back in at another time?

 

This will be possible before the first official release. So far we've mostly focused on showing off the editor interaction, but now we will move to tidy up the internal API to be used by programmers. Using this API it will be possible to simply create a volume from an existing file and write the contents back to a file.

 

Awesome, I'll be waiting for a release.

 

On a related note, this seems like a good time to mention that I'm changing the way data is stored. So far we've asked the user to specify a folder, and all the chunks get saved there as separate files. I'm currently experimenting with writing them to an embedded database instead (probably SQLite) so that everything is kept in a single file.

 

Still interested but lack of mac / console compatibility is a deal breaker for us. Any word on expanding the compatibility across commercially viable platforms?

 

We're keen to get the system on the asset store as soon as possible (before the end of the year) so the initial version will be Windows only. After that I think Mac will be fairly high priority, so I'd say early next year.

Consoles are more of a challenge... I'm not sure exactly what Unity supports but we don't have access to dev kits etc. It would probably be a matter of licensing the C++ source and letting users build it themselves, but this is much further out and plans depend a lot on what kind of reception the system gets.

 

I downloaded the snapshot linked in the latest youtube video, but after opening a new project and trying to create an Empty Smooth Terrain Volume, I keep getting the same error. Tried redownloading cubiquity, didn't help, and all I did was make a new project and create the volume.

The error message reads:
NullReferenceException: Object reference not set to an instance of an object
SmoothTerrainVolume.Synchronize () (at Assets/Cubiquity/SmoothTerrainVolume.cs:135)
UpdateAllVolumes.Update () (at Assets/Editor/Cubiquity/UpdateAllVolumes.cs:29)
UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/BuildAgent/work/7535de4ca26c26ac/Editor/MonoGenerated/Editor/EditorApplication.cs:210)

And here's a screenshot: http://i.imgur.com/oCzhSud.png
-When I double click the error, it leads me to the highlighted line in the code
-When I select the volume in the game window, the camera controls stop working. Notice there is no axis reference in the upper right hand of the game window
-The error message loops to 999+, not just once

If you need any more information, let me know! Can't wait to use this program, but I understand it's still a work in progress. Looks great, and keep up the great work!

 

Are there any error messages printed before the NullReferenceException? What is the very first error? It looks like it is not finding the shader and I suspect this is the underlying cause.

Let's get rid of some noise... try commenting out the offending for loop:

Code (csharp):

1. /*for(int i = 0; i < materials.Length; i++)
2. {
3.     material.SetTexture("_Tex" + i, materials[i].diffuseMap);
4.                
5.     Vector3 invScale;
6.     invScale.x = 1.0f / materials[i].scale.x;
7.     invScale.y = 1.0f / materials[i].scale.y;
8.     invScale.z = 1.0f / materials[i].scale.z;
9.     material.SetVector("_TexInvScale" + i, invScale);
10.                
11.     material.SetVector("_TexOffset" + i, materials[i].offset);
12. }*/

With this gone the texture painting will not work but sculpting still should. More importantly, it will let us see any other errors which are occuring.

 

The first error says this:

The file CubiquityC.dll was not found in the project root, and will be copied there automatically. This warning is normal the first time you use Cubiquity in a project but you should be concerned if you continue to see it after that. If for some reason you do not want this automatic fix in the future you can disable it by editing Installation.cs
UnityEngine.Debug:LogWarning(Object)
Installation:ValidateAndFix() (at Assets/Cubiquity/Installation.cs:54)
CreateEmptySmoothTerrainVolumeWizard:CreateWizard() (at Assets/Editor/Cubiquity/CreateEmptySmoothTerrainVolumeWizard.cs:18)


After commenting out the for loop, I tried to smooth the previously (prior to commenting out the loop) created volume, and when I selected a brush type, the whole thing disappeared, I assume from not having a mesh. It was still in the hierarchy, just invisible in the game window.
I deleted that one and made a new one. This one did not disappear, but when I tried to smooth it by holding down the mouse button and moving the cursor, it made a rectangle as if I was trying to select multiple game objects, and the axis reference int he upper right corner showed back up. It didn't do these until I moved the cursor with the mouse held down (meaning the axis reference was still hidden when i clicked the mouse down, before moving the cursor)

 

The warning about the .dll is ok, were there any other errors after that (apart from the NullReference one)?

Is the volume always showing up pink for you (like in your screenshot)? This should never happen and is probably a sign that the shader wasn't found or didn't compile. A new terrain with no textures should just appear white.

Ok, I suggest you create a new project (not just a new scene/volume) and import Cubiquity again. Comment out the for loop as before and then try creating a new volume. If it fails (and I guess it will) then can you send your Unity Log file to david at volumesoffun.com?

You will probably find the log here: C:\Users\username\AppData\Local\Unity\Editor\Editor.log

But see this page for more info: http://docs.unity3d.com/Documentation/Manual/LogFiles.html

If it doesn't work out then probably we have to wait for a more stable snapshot - I'll be sure to put in extra error checking to try and identify the problem as soon as it occurs.

 

Here's a screenshot of the first 9 windows of error messages. It just keeps going like that for another 10 or so, then loops the error we've been talking about:
http://i.imgur.com/dle0J68.png

Yeah, empty smooth is always pink for me

Alright, I made a new project and imported the Cubiquity-for-unity3d-preview03 unity package file, created a new empty smooth volume, and it was pink. Double clicked the error message to pull up the code, commented out the for loop, deleted that volume and created a new empty smooth volume, and this one was also pink. Now when I try to sculpt it, it DOES NOT do the multi-select box like i mentioned above, but I'm pretty sure it's not sculpting either. It's not letting me rotate the camera so I tried to sculpt on the edge and see if it protruded past the edge, but it didn't sculpt at all.

Emailed you the logs

 

Ok, I think see what is going on here, from the logs I think that the shader is failing to compile. The message in the logs says:

I think those 'Unsupported' outputs are the problem. I'm not sure why because it seems you have a decent grphics card, but lets come back to that in a minute. First we can verify the problem by switching my shader for a built in Unity one. Line 185 of SmoothTerrainVolume.cs reads as follows:

Code (csharp):

1. Shader shader = Shader.Find("SmoothTerrainVolume");

Replace the shader with a basic diffuse one by changing it as follows:

Code (csharp):

1. Shader shader = Shader.Find("Diffuse");

It's probably best to try it on a fresh scene. If it is working then the mesh will appear white/grey and will be lit. You should be able to sculpt (you need to select the terrain first) but you won't be able to apply textures. By the way, are you on a laptop? I think your framerate should be ok but the actual sculpting might be too slow to be usable (it is on my laptop) so I'll have to optimize that.

Let me know how it goes and thanks for the help

 

That works Can sculpt (and smooth), can't paint. And yes, I'm on a laptop! HP Pavillion dv6, bout 18 months old but got fairly decent specs for both school and gaming

So now that I can sculpt without amassing a million errors, any idea on how to make painting possible again? Or should I wait for the next version?
Thank you again for all the help, and I'm incredibly excited for this program!

 

After playing around with it, I've noticed:
-Both First Person and Third Person Character Controllers fall straight through the volume
-Sometimes the volume will just completely vanish until I save, in which case it gets re-rendered
-Often, the inspector won't update to what is currently selected in the hierarchy until I save
-At times I had to save, close, and re-open the scene rather than simply save to get things to reappear or use the inspector again
-Ctrl-Z (undo) does nothing for sculpting, and it's very hard to get things back even to its initial level. Rather than undoing, you have to push it back in, judge the height by eye, and smooth it with the ground
-And just as feedback/a suggestion for the future, consider adding the opposite of a smooth tool, to make edges more jagged, spiky, random, rocky, whatever you see fit. Could go for one specific feel or could even design it to be based off a certain pattern on an image or something like that

 

Sorry for the slow reply but I'm glad we're making progress We've at least verified that the shader is the issue but it's not clear why. Unfortunatly the Unity logs don't seem to give details on exactly why it is unsupported.

So, first of all you should make sure you have the latest version of your graphics card drivers. If that doesn't help then I think we need to cut-down the shader until it works, and that might show what's going wrong. I'll try to make a version tonight.

Yeah, at the moment there is no collision mesh for the smooth terrain. It's turned off because it slows down the sculpting and you don't need it in editor mode anyway... but we should turn it on in play mode. Shouldn't be hard to fix - it already works for the 'colored cubes' volume as shown in our tank demo.

These are general stability issues which should be resolved as we move towards a releasable version.

This one is more tricky. I think the first release won't have undo support but we'll try to add something in for a later version. Likewise it would be good to have a tool which flattens the terrain to a given height, for making plateaus and stuff.

I think this is a good idea, at least to have some kind of 'noise' brush. We'll have to see what we can come up with. The built in Unity terrain does something like this and it makes a lot of sense.

 

After updating my driver, I created a new project, manually imported cubiquity (Assets -> import -> custom package -> cubiquity-for-unity3d-preview3), created an empty smooth volume, and it was pink. Was there anything else you wanted me to try now that the driver is updated? Are there any other logs I can send that may help?

 

Ok, so we know the problem is the shader and probably not your graphics card. Next we have to simplify the shader by removing some features until it works. This will mean disabling some features such as texture mapping, the brush marker, etc. Let's start with texture mapping and reduce the number of supported texture from four to one.

Open 'Cubiquity/Resources/SmoothTerrainVolume.shader', delete the entire contents, and replace it with that shown below:

Code (csharp):

1. Shader "SmoothTerrainVolume" {
2.     Properties {
3.         _Tex0 ("Base (RGB)", 2D) = "white" {}
4.         //_Tex1 ("Base (RGB)", 2D) = "white" {}
5.         //_Tex2 ("Base (RGB)", 2D) = "white" {}
6.         //_Tex3 ("Base (RGB)", 2D) = "white" {}
7.     }
8.     SubShader {
9.         Tags { "RenderType"="Opaque" }
10.         LOD 200
11.        
12.         CGPROGRAM
13.         #pragma surface surf Lambert
14.         #pragma target 3.0
15.         #pragma only_renderers d3d9
16.         #pragma multi_compile BRUSH_MARKER_ON BRUSH_MARKER_OFF
17.  
18.         sampler2D _Tex0;
19.         //sampler2D _Tex1;
20.         //sampler2D _Tex2;
21.         //sampler2D _Tex3;
22.        
23.         float3 _TexInvScale0;
24.         //float3 _TexInvScale1;
25.         //float3 _TexInvScale2;
26.         //float3 _TexInvScale3;
27.        
28.         float3 _TexOffset0;
29.         //float3 _TexOffset1;
30.         //float3 _TexOffset2;
31.         //float3 _TexOffset3;
32.        
33. #if BRUSH_MARKER_ON
34.         float4 _BrushCenter;
35.         float4 _BrushSettings;
36.         float4 _BrushColor;
37. #endif
38.  
39.         struct Input
40.         {
41.             float4 color : COLOR;
42.             float3 worldNormal;
43.             float3 worldPos;
44.         };
45.        
46.         half4 texTriplanar(sampler2D tex, float3 coords, float3 dx, float3 dy, float3 triplanarBlendWeights)
47.         {                      
48.             // Used to avoid sampling a texture unless it
49.             // signicantly contributes to the final color.
50.             float blendWeightThreshold = 0.01;
51.            
52.             // Sample the texture three times (once along each axis) and combine the results.
53.             half4 triplanarSample = 0.0;
54.             if(triplanarBlendWeights.z > blendWeightThreshold)
55.             {
56.                 triplanarSample += tex2Dgrad(tex, coords.xy, dx.xy, dy.xy) * triplanarBlendWeights.z;
57.             }
58.             if(triplanarBlendWeights.x > blendWeightThreshold)
59.             {
60.                 triplanarSample += tex2Dgrad(tex, coords.yz, dx.yz, dy.yz) * triplanarBlendWeights.x;
61.             }
62.             if(triplanarBlendWeights.y > blendWeightThreshold)
63.             {
64.                 triplanarSample += tex2Dgrad(tex, coords.xz, dx.xz, dy.xz) * triplanarBlendWeights.y;
65.             }
66.                    
67.             // Return the combined result.
68.             return triplanarSample;
69.         }
70.  
71.         void surf (Input IN, inout SurfaceOutput o)
72.         {
73.             //half texScale = 8.0;
74.             //half invTexScale = 1.0 / texScale;
75.            
76.             // Interpolation can cause the normal vector to become denomalised.
77.             IN.worldNormal = normalize(IN.worldNormal);
78.            
79.             // Vertex colors coming out of Cubiquity don't actually sum to one
80.             // (roughly 0.5 as that's where the isosurface is). Make them sum
81.             // to one, though Cubiquity should probably be changed to do this.
82.             half4 materialStrengths = IN.color;
83.             half materialStrengthsSum = materialStrengths.x + materialStrengths.y + materialStrengths.z + materialStrengths.w;
84.             materialStrengths /= materialStrengthsSum;
85.            
86.             // Texture coordinates are calculated from the world
87.             // space position, scaled by a user-supplied factor.
88.             float3 texCoords = IN.worldPos.xyz; // * invTexScale;
89.            
90.             // Texture coordinate derivatives are explicitly calculated
91.             // so that we can sample textures inside conditional logic.
92.             float3 dx = ddx(texCoords);
93.             float3 dy = ddy(texCoords);
94.            
95.             // Squaring a normalized vector makes the components sum to one. It also seems
96.             // to give nicer transitions than simply dividing each component by the sum.
97.             float3 triplanarBlendWeights = IN.worldNormal * IN.worldNormal;
98.            
99.             // Sample each of the four textures using triplanar texturing, and
100.             // additively blend the results using the factors in materialStrengths.
101.             half4 diffuse = 0.0;
102.             diffuse += texTriplanar(_Tex0, texCoords * _TexInvScale0 + _TexOffset0, dx * _TexInvScale0, dy * _TexInvScale0, triplanarBlendWeights * materialStrengths.r);
103.             //diffuse += texTriplanar(_Tex1, texCoords * _TexInvScale1 + _TexOffset1, dx * _TexInvScale1, dy * _TexInvScale1, triplanarBlendWeights * materialStrengths.g);
104.             //diffuse += texTriplanar(_Tex2, texCoords * _TexInvScale2 + _TexOffset2, dx * _TexInvScale2, dy * _TexInvScale2, triplanarBlendWeights * materialStrengths.b);
105.             //diffuse += texTriplanar(_Tex3, texCoords * _TexInvScale3 + _TexOffset3, dx * _TexInvScale3, dy * _TexInvScale3, triplanarBlendWeights * materialStrengths.a);
106.            
107. #if BRUSH_MARKER_ON
108.             float brushStrength = 0.0f;
109.            
110.             float distToBrushCenter = length(IN.worldPos.xyz - _BrushCenter.xyz);
111.             if(distToBrushCenter < _BrushSettings.x)
112.             {
113.                 brushStrength = 1.0;
114.             }
115.             else if(distToBrushCenter < _BrushSettings.y)
116.             {
117.                 float lerpFactor = (distToBrushCenter - _BrushSettings.x) / (_BrushSettings.y - _BrushSettings.x);
118.                 brushStrength = lerp(1.0f, 0.0f, lerpFactor);
119.        
120.                 brushStrength = min(brushStrength, 1.0f);
121.                 brushStrength = max(brushStrength, 0.0f);
122.                
123.                 //brushStrength = 1.0 - lerpFactor;
124.             }
125.            
126.             _BrushColor.a = _BrushColor.a * brushStrength;
127.            
128.             o.Albedo = diffuse.rgb * (1.0 - _BrushColor.a) + _BrushColor.rgb * _BrushColor.a;
129. #else
130.             o.Albedo = diffuse.rgb;
131. #endif
132.  
133.             o.Alpha = 1.0;
134.         }
135.         ENDCG
136.     }
137.     FallBack "Diffuse"
138. }

Save your changes and go back into Unity. If the volume is still pink then it didn't work and we need to simplify further. If it is not pink then you should be able to apply a single texture by selecting the volume, going to the inspector and clicking the 'paint' button, choosing the first material button (which will be blank) and choosing 'Edit selected material...' to define the texture. Note you'll need to import some textures into your project to do this.

Let me know how it goes...

 

Still pink after changing that file

 

Ok, I will cut some more stuff out of the shader file and post another version tonight (we can put most of this back in once we work out which bit is the problem).

Meanwhile, I also tested the system on another laptop which is about 4 years old and has an NVidia GPU. I don't have the Unity editor on this laptop so I just made a standalone build. It seemed to work correctly. Perhaps you could test this standalone build as well? It could be that the problem is in some way tied to the Unity editor, in which case I could install the editor on the laptop to try and reproduce.

You can download the standalone build here: http://drive.google.com/uc?id=0B7b4UnjhhIiEbHRvZGRFbHQwb0U&e=download

If it works you should see a basic terrain with some textures applied. If it doesn't work I guess it will be pink again.

Thanks again!

 

okay so the standalone looks correct! No pink in it. Perhaps I should uninstall and reinstall unity tonight?

 

Interesting! So it seems the problem is editor specific. Maybe it is related to the blue brush marker which is shown in the editor, as that is hidden in play mode. At any rate I'll install the Unity editor on the NVidia laptop I have access to and see if I can reproduce the problem.

 

I installed the editor in the NVidia laptop and everything seems to work fine. So I think we're back to cutting down the shader to work out what the problem is. Here's a new version of the shader wich has been further simplified by removing the brush marker:

Code (csharp):

1. Shader "SmoothTerrainVolume" {
2.     Properties {
3.         _Tex0 ("Base (RGB)", 2D) = "white" {}
4.     }
5.     SubShader {
6.         Tags { "RenderType"="Opaque" }
7.         LOD 200
8.        
9.         CGPROGRAM
10.         #pragma surface surf Lambert
11.         #pragma target 3.0
12.         #pragma only_renderers d3d9
13.  
14.         sampler2D _Tex0;
15.        
16.         float3 _TexInvScale0;
17.        
18.         float3 _TexOffset0;
19.  
20.         struct Input
21.         {
22.             float4 color : COLOR;
23.             float3 worldNormal;
24.             float3 worldPos;
25.         };
26.        
27.         half4 texTriplanar(sampler2D tex, float3 coords, float3 dx, float3 dy, float3 triplanarBlendWeights)
28.         {                      
29.             // Used to avoid sampling a texture unless it
30.             // signicantly contributes to the final color.
31.             float blendWeightThreshold = 0.01;
32.            
33.             // Sample the texture three times (once along each axis) and combine the results.
34.             half4 triplanarSample = 0.0;
35.             if(triplanarBlendWeights.z > blendWeightThreshold)
36.             {
37.                 triplanarSample += tex2Dgrad(tex, coords.xy, dx.xy, dy.xy) * triplanarBlendWeights.z;
38.             }
39.             if(triplanarBlendWeights.x > blendWeightThreshold)
40.             {
41.                 triplanarSample += tex2Dgrad(tex, coords.yz, dx.yz, dy.yz) * triplanarBlendWeights.x;
42.             }
43.             if(triplanarBlendWeights.y > blendWeightThreshold)
44.             {
45.                 triplanarSample += tex2Dgrad(tex, coords.xz, dx.xz, dy.xz) * triplanarBlendWeights.y;
46.             }
47.                    
48.             // Return the combined result.
49.             return triplanarSample;
50.         }
51.  
52.         void surf (Input IN, inout SurfaceOutput o)
53.         {
54.             //half texScale = 8.0;
55.             //half invTexScale = 1.0 / texScale;
56.            
57.             // Interpolation can cause the normal vector to become denomalised.
58.             IN.worldNormal = normalize(IN.worldNormal);
59.            
60.             // Vertex colors coming out of Cubiquity don't actually sum to one
61.             // (roughly 0.5 as that's where the isosurface is). Make them sum
62.             // to one, though Cubiquity should probably be changed to do this.
63.             half4 materialStrengths = IN.color;
64.             half materialStrengthsSum = materialStrengths.x + materialStrengths.y + materialStrengths.z + materialStrengths.w;
65.             materialStrengths /= materialStrengthsSum;
66.            
67.             // Texture coordinates are calculated from the world
68.             // space position, scaled by a user-supplied factor.
69.             float3 texCoords = IN.worldPos.xyz; // * invTexScale;
70.            
71.             // Texture coordinate derivatives are explicitly calculated
72.             // so that we can sample textures inside conditional logic.
73.             float3 dx = ddx(texCoords);
74.             float3 dy = ddy(texCoords);
75.            
76.             // Squaring a normalized vector makes the components sum to one. It also seems
77.             // to give nicer transitions than simply dividing each component by the sum.
78.             float3 triplanarBlendWeights = IN.worldNormal * IN.worldNormal;
79.            
80.             // Sample each of the four textures using triplanar texturing, and
81.             // additively blend the results using the factors in materialStrengths.
82.             half4 diffuse = 0.0;
83.             diffuse += texTriplanar(_Tex0, texCoords * _TexInvScale0 + _TexOffset0, dx * _TexInvScale0, dy * _TexInvScale0, triplanarBlendWeights * materialStrengths.r);
84.  
85.             o.Albedo = diffuse.rgb;
86.  
87.             o.Alpha = 1.0;
88.         }
89.         ENDCG
90.     }
91.     FallBack "Diffuse"
92. }

As before you should replace your copy of the shader with the code above and see if it is still pink.

 

looking good

 

Good news! The snapshot now works 100%! Apparently I missed some updated versions of Unity. When I opened it today to try the new file you posted, it prompted me to update to the newest version. After doing so, everything works fine (BEFORE changing that shader file or anything else -- just the snapshot by itself works)

EDIT: Found a really useful program for a fly camera. Just make a new JAVASCRIPT file, copy/paste this in, and drag&drop it on your main camera. I also edited it to go straight-up and straight-down
http://pastebin.com/c4VbLJEs

EDIT 2: Do yall plan to include a Smooth HEIGHT feature? It's a massive pain to try and push/pull then smooth everything to make it more or less the same height, and it looks pretty bad too

 

Great, I'm glad it's now working for you

I think this is indeed a useful tool (and the standard Unity terrain has something like this). I'll give some thought as to how to implement it but it might not make it into the first release.

 

disappointed to hear it'll take so long for the Smooth Height feature. That and Collision Mesh are definitely the 2 remaining features I'm looking forward to

Also, is there any other way I can help yall? Just let me know

 

Yeah, sorry it takes time but we need to focus on getting the existing features polished and getting the first release on the asset store. We'll try and prepare an other snapshot in the next couple of weeks though, and this one should have collision meshes available so you'll be able to play with that

 

Just came across this interesting use of Cubiquity to build a side-on Worms-style game with destrutible terrain. Really nice to see people coming up with some creative ways to use the technology

There's some more details here if you read French: http://www.unity3d-france.com/unity/phpBB3/viewtopic.php?t=7000&p=51387

 

I just thought I'd provide a quick update as to what we're working on at the moment. The next few weeks will not show much outside progress but be assured there is a lot happening behind the scenes

• The last snapshot stored the volume data as a collection of files in a user specified folder. We've now replaced this with an embedded database which is much tidier and will probably be faster to access as well.
• We're working on the user interface and want to give you a working voxel terrain in a single click (like the built in Unity terrain does). No messing around with volume size, textures, etc - these things can all be configured later. You should click 'New Terrain Volume' and it should be there straight away.
• We're refactoring the classes and functions which make up Cubiquity, to give it a nice clean API. This lets you create volumes from code (including procedural generation) and modify them at runtime. You'll also be able to implement your own tools through direct access to the volume data.

It's all important stuff, but largely non-visual. So we'll try to add an extra feature as well (maybe the collisions meshes) and make a new video in the next couple of weeks.

 

"including procedural generation" << Sounds great! Thanks for the update David

 

Loving Cubiquity so far
Curious for the box voxel generation set
Is there a way to set the colours of the procedural generated rather than the blue,gray,white ?
which i presume are height generated and is there a way to select what colours appear at what height ?

 

Great

Yes, the interface to Cubiquity's ColoredCubesVolume is very simple. Essentially it is just a 3D grid of colors. Assuming you are using the last snapshot you can set the color at any location as follows:

Code (csharp):

1. Color32 someColor = ...
2. myVolume.SetVoxel(x, y, z, someColor);

That's basically it! Cubiquity will automatically take care of tracking which voxels you change and will rebuild the mesh as required.

The blue/grey/white landscape which you refer to is actually just an example, and you are free to modify it for your needs. You will find the code in Assets/Cubiquity/Editor/CreateProceduralColoredCubesVolumeWizard.cs in the 'OnCreatePressed()' method. It generates a 2D heightmap with Perlin noise, and then compares each voxel to the heightmap to decide what color it should be. The relevant code snippet looks like this:

Code (csharp):

1. int terrainHeight = (int)(perlinValue * height);                   
2. int seaLevel = (int)(height * 0.4f);
3. int snowLevel = (int)(height * 0.6f);
4.  
5. for(int y = 0; y <= height-1; y++)
6. {
7.     if(y < terrainHeight)
8.     {
9.         if(y < snowLevel)
10.         {
11.             coloredCubesVolume.SetVoxel(x, y, z, grey);
12.         }
13.         else
14.         {
15.             coloredCubesVolume.SetVoxel(x, y, z, white);
16.         }
17.     }
18.     else if(y < seaLevel)
19.     {
20.         coloredCubesVolume.SetVoxel(x, y, z, blue);
21.     }
22. }

For the benefit of anyone else reading this thread, the code snippet above generates the following terrain:



You can modify those colors and variables to make basic changes to the terrain. But if you want to get creative you could write code to generate mazes, dungeons, planets... or pretty much anything else!

 

I've realized there's one addition point I should mention here, which is that the color you write to the ColoredCubesVolume is not exactly the color which gets displayed, nor is it exactly the color which you get back if you later call GetVoxel(...). There's a couple of reasons for this:

• Cubiquity colors are stored with only 4-bits of precision per color channel. This means your colors get quantized slightly, and if you read them back they might have a slightly different value.
• Some random noise is added by Cubiquity when it renders the voxels. If you look at the previous picture you will see that adjacent voxels are not exactly the same color. Generally this looks nice, but you can disable it in the shader if you want.

The next Cubiquity snapshot will include its own Color class, and the explicit casting will make it clear when this color quantization is occurring.

 

I was just wondering, when creating a volume from code, how do I make it use the saved data instead of just overwriting the old? Other then that, its really nice I must say

 

Thank you for talking about my project.
For the moment it's just a preview, but I would like to make a game based on the old Amiga Game "Artillerus", with a Steampunk style.

I have finished the prototype, and I'll work on the graphics and game design.

So I have a problem with Cubiquity, may be you'll could help me.
When I make a build the voxel landscape don't appear on some computers without any reason. It's work on mine, but when I've posted a build on the French Forum, some users said that they didn't saw the landscape. I've tried to make a Linux Build too, and the voxels don't appear.

When I open the cubiqy.log, the voxels path looks like strange with some "\" and "/".
like this:"I:/unity_projects/artillerus3/build/Win/artillerus_Data/StreamingAssets\Cubiquity\Volumes\Terrain\"

I didn't find any solution for this problem, so if you have an idea it will be welcome

Anyway, thank you for your library, it's a very good work.


PS: Sorry for my English

 

It's really nice to see people are starting to make use of this

Are you working with the terrain volume or the colored cubes volume? Also, are you using the last snapshot or the version that is in the Git repository?

Basically this is one of the main areas I've been working on since the last snapshot was released, but the work is not finished yet. Since the last snapshot I have renamed the 'SmoothTerrainVolume' class and split it into 'TerrainVolume' and 'TerrainVolumeData'. The idea is that it should be possible to create a TerrainVolumeData and then attach it to a TerrainVolume for rendering (like how Unity has the standard Terrain and TerrainData classes). TerrainVolumeData instances should probably then be serialized as assets but I don't think I implemented this yet.

In other words, what you want might not yet be possible but it's being actively worked on. The same design principles should also be applied to the colored cubes volume but I haven't started that yet.

At the moment Cubiquity only works on Windows machines because it requires 'CubiquityC.dll'. To make it work on Linux I will have to create a 'CubiquityC.so', and something similar for MacOS. I will do this eventually but there is still lots of work to do on the Windows version first. Perhaps some of your users are not using Windows?

The '\' vs. '/' could be part of the problem, or it could also be related to permissions. But actually the next version of Cubiquity does not use files in the same way, as it uses an SQLite database instead. So maybe your problem will just disappear in the future as Cubiquity becomes a bit more stable.

 

Ok, thank you for your answers, I'm waiting for the new version of Cubiquity :wink:

Do you think in the future it will be possible to add some personnal parameters to each voxels, like life point for example?

 

Yes, but not soon. I think that user data will not be stored with the colors but instead in a seperate array. I imagine we could create a 'BigArray' class for this purpose, and it could also be backed by a database.

For now I would just use a regular C# array. Your volume is quite small, and even a 256x256x256 volume would only need 16mb for storing a single byte per voxel. This should not be a problem for a desktop game.

One more point in addition to my previous answer - actually Cubqiuity does not save changes made to the volume in play mode. So if you are creating your volume in play mode then it might be that it doesn't get saved, rather than it isn't loading properly.

The TerrainVolumeData.OnDisable() method has the following logic:

Code (csharp):

1. // We only save if we are in editor mode, not if we are playing.
2. bool saveChanges = !Application.isPlaying;
3.                
4. if(saveChanges)
5. {
6.     CubiquityDLL.AcceptOverrideBlocksMC(volumeHandle.Value);
7. }
8. CubiquityDLL.DiscardOverrideBlocksMC(volumeHandle.Value);

It will eventually be changed to use a user-provided flag, rather than just checking if the system is in play mode

 

Ok, thank you.

 

Couldn't you do with array of structs? Like voxel array would be defined as

Code (csharp):

1. public VoxelStruct[][][] voxelArray;

and VoxelStruct would be defined in same file like this:

Code (csharp):

1. public struct VoxelStruct {
2. Color32 voxelColor; //do not change it, otherwise won't work
3. //add here your own definitions if you want, should be primitive types for performance reasons
4. int exampleInt;
5. bool exampleFloat;
6. //...
7. }

Then to change voxel color (or any data), you'd call:

Code (csharp):

1. voxelterrain.voxelArray[x][y][z].voxelColor = new Color32(Random.nextInt(255),Random.nextInt(255),Random.nextInt(255),Random.nextInt(255));
2. voxelterrain.voxelArray[x][y][z].someInt = 16;
3. //etc.

IMO this would be easier (for Cubiquity's user) method of accessing. And saving/loading aside of internal purposes of Cubiquity itself (when editing level directly in Unity) should be left to programmer anyway, with example code.

 

It is often more efficient to use a struct of arrays rather than an array of structs because the cache coherency is usually better. Some Cubiquity operations (such as raycasting or editing the environment) may involve touching a lot of different voxels, and this is more cache efficient if the relevant data is close together in memory. However, the approach you describe actually interleaves user data (which Cubiquity doesn't need) with the color data and so actually spreads everything out in memory.

I would therefore expect something like this to perform better:

Code (csharp):

1. // Pseudocode...
2. public struct MyVolume
3. {
4.     ColoredCubesVolume voxelColor;
5.     BigArray<int>[][][] exampleInt;
6.     ...
7. }

Which you then access as:

Code (csharp):

1. myVolume.voxelColor[x][y][z] = new Color32(Random.nextInt(255),Random.nextInt(255),Random.nextInt(255),Random.nextInt(255));
2. myVolume.exampleInt[x][y][z] = 16;
3. //etc.

Note that the access is actually pretty similar, it's just that the indexes are in a different place.

Actually Cubiquity does handle saving to disk because it also uses the disk for paging data to/from main memory. But you have direct access to the voxel data, so you can implement your own import/export if you prefer.

 

Ah, thanks. Also I've got 2 questions and a suggestion.

Question 1: What is reason of using 4 bits/channel for "colored cubes" volume? If it is just for using 2 bytes instead of 4/voxel, I'd say that anything powerful enough to run Unity game would have enough ram to store voxels in full RGB range and it would allow for smoother color transitions on surfaces if someone wants voxels but don't want them to be "pixelated" (by "pixelated" I mean sudden transitions between colors, not lack of thing like Marching Cubes which is provided anyway). Colored voxels have less memory usage than textured anyway, even with full RGB range, memory usage would be negligible. I mean, Minecraft has reasonable memory usage giving that it used textured voxels, was first voxel game that implements "infinite" world and is written in less than optimal (at least for games, I have nothing against "normal", non-game apps written in it) language that is Java.

Question 2: What with license? At this point I don't know if I can implement it in my game (which is my first commercial gig and thus budget is exactly $0) or stick with what I have.

Suggestion: How about removing "dithering" of cubes (noise-like pattern) from the shader and do dither tool in editor instead that would change cubes color directly? Reason for this is that some surfaces needs another kind of dithering than simple noise-like pattern and while it suits things like grass, it may not suit things like wood (esp. bark). Turning "autodither" in shader and coloring each single voxel isn't easy, so dither tool would be cool for that.

 

Actually we've just switched it to 565 color format which gives a bit more precision, but your question is still valid...

We deliberately try to discourage smooth transitions between colors for two main reasons. Firstly smooth transitions make it much harder to perform mesh decimation (i.e. merging adjacent triangles) which has performance and memory impacts. Secondly, smooth transitions are harder to compress because you are less likely to have runs of the same value.

That said, it would be interesting to have a smooth mode (kind of like Cube World) but we haven't looked at it very hard yet.

This isn't generally true, Minecraft doesn't store the texture for every voxel. Instead it just stores an ID (e.g. an 8-bit value) which provides the look up into a texture atlas. Minecraft also tends to have large areas of exactly the same material, which also compresses down well.

You already saw the PM, but for the benefit of anybody else reading this thread we'll really try to post proper license news in the next day or two.

It's certainly possible to turn off the dithering in the shader (you can just comment it out, but we should add a proper option) but if you dither the raw voxel data then you will again prevent the mesh decimation from taking place. You can already do it though, and maybe the performance is fine for some applications.

 

New licensing scheme for Cubiquity for Unity3D

Hi all, I want to let everyone know that we are making an important change to the license of Cubiquity for Unity3D. Because it is important that everyone sees this I am taking the liberty of copy-and-pasting the post from our blog. You can still reply here on the forums if you have any questions or comments.

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!

 

I use Qubicle to make voxel models, would i be able to use the models i make using the software? what export format is needed? (vox, obj, etc.)

 

Are you modelling characters or environments?

Cubiquity is only for representing environments, and we don't currently have a Qubicle importer. If you know how to read th Quibcle file format then you can implement this yourself quite easily, otherwise we will probably do it ourselves at some point in the future. In this case you would would want to be importing the real voxel data.

For characters you can probably just export them from Qubicle as regular meshes (even animated) and drop then straight into the scene. In a scene you can mix Cubiquity voxel object with regular Unity meshes so there should be no problems here.

 

For the last few days I've been working on a basic procedural generation example for the Cubiquity terrain volumes. This is not a feature of Cubiquity as such, instead it is something which you can build on top of Cubiquity by using your favourite noise library and writing the output into a volume.

​

In this case I used a Simplex noise implementation to generate the rocks and then just a flat plane for the soil and grass. Obviously you can plug in a more advanced noise library if you want some fancier effects.

The code is provided as a MonoBehaviour which you can just add to an empty game object, and it will then create and fill the volume in it's start function. Again, it's just an example so you could do this differently in real-world code if you wanted.

Here's an image of the whole 256x256x32 terrain. I guess it took a few seconds to generate though I didn't really time it. Notice how you can see the different material layers at the nearest edge of the volume - i.e. you can see there is a base layer of rock, some soil on top of it, and then a layer of grass which is one voxel thick. This use of multiple materials is quite common in Minecraft-style games but I haven't seen it done much with smooth voxel terrain.

​

In other news we now have working collision meshes for the smooth terrain, and we also added an example script to let you dig away in play mode. We'll really try to get a new snapshot out soon!

 

Chiming in here, been following this thread since you posted about it on reddit, so about 2 months now. This plugin is really interesting, and I'm looking forward to the next snapshot!

Like other people in here, I'm also interested in the possibility of adding structures on the smooth terrain.

Keep up the good work, I'm already working on a game that's going to utilize this plugin