Cubiquity - A fast and powerful voxel plugin for Unity3D

I do not seem to have this file in that location or anywhere in my Cubiquities folders. Is there anywhere else I can get it?

I think I may have found it in a super old version of Cubiquity but a up to date one would be nice. Also what format does it expect? I cant seem to get it to work.

 

It's now called 'ProcessVDB' and you should find it in one of the platform-specific subfolders (e.g. Cubiquity For Unity3D/Assets/StreamingAssets/Cubiquity/SDK/Windows/x86-64/ProcessVDB.exe)

This page should answer most of your questions: http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/page_obtaining_vol_dat.html

 

Does this voxel engine support procedural infinite generation? Thanks.

 

No, Cubiquity focuses on loading maps from a database file. These are usually user designed (though they can be generated procedurally) and are of relatively limited size. I think 512x512x64 is the biggest I've worked with so far.

 

So downloaded the Cubiquity for Unity in the asset store and every time I try to run my game in editor it works perfect! No issues at all! I love it!

Problem is inside the built version of the game. When I build/run the game, I get the following debug log...

Spoiler: Debug Isues

Updating CubiquityC.dll in the project root folder as it doesn't match the version in the Cubiquity SDK.
UnityEngine.Debug:Internal_Log(Int32, String, Object)
UnityEngine.Debug:Log(Object)
Cubiquity.Impl.Installation:ValidateAndFix() (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\Impl\Installation.cs:79)
Cubiquity.VolumeData:Awake() (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\VolumeData.cs:315)
UnityEngine.ScriptableObject:CreateInstanceFromType(Type)
UnityEngine.ScriptableObject:CreateInstance(Type) (at C:\buildslave\unity\build\artifacts\generated\common\runtime\BaseClassBindings.gen.cs:589)
UnityEngine.ScriptableObject:CreateInstance() (at C:\buildslave\unity\build\artifacts\generated\common\runtime\BaseClassBindings.gen.cs:599)
Cubiquity.VolumeData:CreateEmptyVolumeData(Region, String) (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\VolumeData.cs:261)
<generate>c__Iterator5:MoveNext() (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:291)
UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator)
UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) (at C:\buildslave\unity\build\artifacts\generated\common\runtime\UnityEngineMonoBehaviourBindings.gen.cs:62)
GenerationHandler:generateChunk(Chunk, Int32, Boolean) (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:245)
Chunk:.ctor(GenerationHandler, Int32, Int32) (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:469)
<makeRealm>c__Iterator2:MoveNext() (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:150)

(Filename: E:/Unity/Quest for Cube/Assets/Cubiquity/Scripts/Impl/Installation.cs Line: 79)

IOException: Sharing violation on path E:/Unity/Quest for Cube/Start_Data/StreamingAssets/Cubiquity/SDK\Windows\x86\CubiquityC.dll" or "E:\Unity\Quest for Cube\CubiquityC.dll
at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, Boolean overwrite) [0x001bd] in /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.IO/File.cs:124

at Cubiquity.Impl.Installation.ValidateAndFix () [0x00184] in E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\Impl\Installation.cs:84
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
Cubiquity.Impl.Installation:ValidateAndFix() (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\Impl\Installation.cs:88)
Cubiquity.VolumeData:Awake() (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\VolumeData.cs:315)
UnityEngine.ScriptableObject:CreateInstanceFromType(Type)
UnityEngine.ScriptableObject:CreateInstance(Type) (at C:\buildslave\unity\build\artifacts\generated\common\runtime\BaseClassBindings.gen.cs:589)
UnityEngine.ScriptableObject:CreateInstance() (at C:\buildslave\unity\build\artifacts\generated\common\runtime\BaseClassBindings.gen.cs:599)
Cubiquity.VolumeData:CreateEmptyVolumeData(Region, String) (at E:\Unity\Quest for Cube\Assets\Cubiquity\Scripts\VolumeData.cs:261)
<generate>c__Iterator5:MoveNext() (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:291)
UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator)
UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) (at C:\buildslave\unity\build\artifacts\generated\common\runtime\UnityEngineMonoBehaviourBindings.gen.cs:62)
GenerationHandler:generateChunk(Chunk, Int32, Boolean) (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:245)
Chunk:.ctor(GenerationHandler, Int32, Int32) (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:469)
<makeRealm>c__Iterator2:MoveNext() (at E:\Unity\Quest for Cube\Assets\CubeWorld\Scripts\GenerationHandler.cs:150)

The Sharing Violation repeats a few times. The last line(in my code), that this debug points to is my GenerationHandler, and all that line contains is

ColoredCubesVolumeData data = VolumeData.CreateEmptyVolumeData<ColoredCubesVolumeData> (new Region (0, 0, 0, width - 1, height - 1, width - 1));

Where width = 256, and height = 64. I also execute this a singular time for a single chunk. But in the editor it does work with multiple chunks(when I know you guys prefer large singular chunks, hence me testing one large chunk as opposed to 9 smaller)

Hopefully you can help with this, I've been going nuts over this bug and would like to send a test build to a few friends!

 

Do the Cubiquity examples work correctly when you do a standalone build? If so, can you copy the offending line(s) into the example to see if you can reproduce the problem in a simpler scenario?

 

Performance question....
in the DestroyVoxels() example function... it makes a list of voxels then changes them all at the end... like this...

foreach (Vector3ivoxelinvoxelsToDelete) //LoopthroughListwithforeach
{
coloredCubesVolume.data.SetVoxel(voxel.x, voxel.y, voxel.z, newQuantizedColor(0,0,0,0));
}

question is... does it re-calculate the mesh and collisions, each time a voxel is changed, or does it know than maybe X voxels changed all in the same frame, and recompute all of them at the same time?

I'm considering explodions... but also re-building equally large chunks of the map, and wondering if its best to do it all at once like in the explosion example... or split it across frames (time-splicing) ...usually this might create less hiccups, but I suspect it will be worse in this case to do ?

Cheers

 

Hey everyone. Considering what my best voxel solution is and I came across this one. I want to make a game with basic physics where if a voxel is not supported it will fall straight down. Something along the lines of sand in minecraft. Will this work with this asset and does doing this become more complicated with smoothed voxels?

 

Testing out the build examples now...

Built the ProceduralGeneration example and got the same issue, spamming the Sharing Issue, as well as CubiquityC.dll NotFoundException

Depending on if you're calulcating from generation(no visual), vs the minecraftesque "block-update" where you break a block and updates states on nearby blocks...

If its during generation, I would(not saying this is the best option, this is top of my head), let the chunk generate fully placing the different sand blocks around, storing the positions in an array, then after generating an area, iterating over each location, and moving it down to the next solid block under it. You would also have to consider Y-axis ordering to make sure the top blocks are following the bottom block instead of vice versa.

If its during runtime/visually changes as in minecraft specifically, you could do the same thing except would just need a falling block animation per block type (Called a Falling Block Entity in MC), as well as iterate such as the generation example to find where it lands. I know that cubiquity has better collision/raycast results, but in terms of an iteration aspect this is what I can think of =)

As for smooth vs colored cubes, you could make a textured sphere fall as opposed to a colored cube, would visually transfer well I would think

 

If I recall reading correctly, when you execute the SetVoxel, it simply flags the collider/renderer to update the next frame. So I believe that doing it all immediately would serve better in terms of performance. But David would be the know-how

 

This is done for a different reason than you might expect. When we delete voxels we spawn physics cubes in their place, but we don't actually spawn a cube for every voxel. Instead we only spawn a cube for the voxels which lie on the surface of the object being destroyed. This means many less cubes need to be spawned.

We identify surface voxels by looking at the neighbours as we iterate over the area being affected. However, if we were to delete them as we go then this would affect the decision about which voxels are surface voxels. We might delete a voxel, causing the one underneath to become as surface voxel (when it was not before). Hence we do two passes - one to identify the surface voxels and one to delete all voxels in the explosion.

At least that is what I recall (with out looking at the code...). Does that make sense?

The mesh is not recalculated until next frame, or potentially in several frames time. Hence in a single frame you can modify multiple voxels for the cost of one (except for other minor costs).

I'd be inclined to do it all at once, unless you really find that splitting over multiple frames is better. Otherwise you might modify it a second time which the mesh is being regenerated, which could slow it down more. Hard to say though - try it and see.

Yes, you should be able to do this but you will need to implement the logic yourself. So you will need to check when a voxel is unsupported, delete it, and set the one underneath. Finding an efficient algorithm for this will be the tricky part

Have a look at Liquid Voxels, I guess the logic is similar: http://forum.unity3d.com/threads/liquid-voxels.242821/

Yes, it will be much more complicated Work on the cubic version first.

I've done a build of the procedural generation example and it works on my machine. I built on a 64-bit Win 10 machine using Unity 5.0, and ran the test on the same machine. Does this download work for you?

https://drive.google.com/file/d/0B7b4UnjhhIiEb3FlazdTWkZMR1E/view?usp=sharing

Failing that, can you install the Visual C++ Runtime, in case you are missing some .dlls? You can get it here:

https://support.microsoft.com/en-gb/kb/2977003

I think you need the VS 2013 version. Otherwise, what platform (Windows version, 32 vs. 64 bit, etc) are you running and building on? Maybe you can send me the problematic build of ProceduralGeneration?

 

frist try amazing that's very cool
noob question ! :<) it's free ? where the joke
working on mobile ? compile result white screen

 

@DavidWilliams Interesting proposition! By "hand-drawn", I mean that I created the default cave smooth voxel volume in the unity editor and send that base vdb file to clients when they open the door. They receive the vdb and recreate their own copy locally. Can Cubiquity export heightmaps of it's own terrain volumes? I suppose if I'm understanding you correctly, I can have the server export it's heightmap and send it to the client instead of the vdb, then the client can use that heightmap to create it's terrain locally. I can imagine that would certainly cut down on the information I'm sending to the client.

 

The way I'm sending information is basically a wrapper/conversion from the colored cubes volume to serialized data, then sending the zipped data to the clients.

Overall I got the data size for a 1536x1536 area down to around 1-2MB, which in my opinion is pretty decent.

More specifically, my terrain is "2D" meaning 1 height for every x/z, as well as using block ids to represent colors. So 1 = green(grass), 2 = grey(stone). With my generation I can store 2 block ids per x/z as well as the height of those ids... So for one square its being sent I send height+64,blockid1,blockid2, rinse repeat. This makes an x/z coord = 3 ints, instead of a whole column from the bottom of the volume to the top.

Not sure if its the best way as I read that Cubiquity essentially stores the data in a sqlite type system, which I've been told is serializable, but have not done enough research to utilize this, or even confirm it.

 

Discovered that the issue was in me running the built project in my unity project folder. So unity and the built program were trying to access the same DLL, at least this is my understanding. It is all working now, just wasn't using my brain =)

 

It uses PC libraries, so does not work on mobile. nor web browser I think

 

So.. Is this open source?
I dug around and I could not find any helpful source?
https://bitbucket.org/volumesoffun/...ssets/Cubiquity/SDK/Windows/x86-64/?at=master
Thanks.

 

The core of it is not open source, however a few of the files in the cubiquity package show some source. But you wouldn't want to mess with them too much.

 

Using this engine can you change the colliders on a voxel? I want to make it so cubes of the same type share a collider but a cube of a different type would not. Also is there anywhere in the scripts that a cube looks at the cubes that are surrounding it?(To check if it is surrounded or if there is no cube on one of its sides) There are a lot of scripts so a little guidance would really be appreciated. Finally I am not yet clear on how changing the project is limited by the C++ files not being included and if this will prevent me from making the game that I want so if someone could explain what I can't do I would really appreciate it. Very impressive product regardless

 

from what I understand, you can either have collision on for the whole voxel mesh or off...
If you want certain colors to be off, then you'd need to make your own collision system. Earlier in the thread we were talking about making some kind of new collision system just using unity box colliders, or oct-tree or similar system, in which case it would be possible to set certain colors as non collision.
Check the included demo for how to change the colors. (the colored cubes demos all change color of the voxels) its something simple like SetVoxelColor(x,y,z, color)

 

Hi, I've managed to load .vdb files from script, but can't find a way to save the volume's vdb at runtime.

commitChanges() isn't working for me, even with WritePermissions set to ReadWrite.

This is the message i get:
CubiquityException: An exception has occured inside the Cubiquity native code library.
Error code 'CU_DATABASE_ERROR' with message "Encountered 'database is locked' (error code 5) when executing 'sqlite3_exec(mDatabase, "INSERT OR REPLACE INTO Blocks (Region, Data) SELECT Region, Data from OverrideChunks;", 0, 0, 0)'".

Is it possible?

 

Yep! I was charging for it before, but I don't really have the time to treat it as a proper commercial project at the moment.

Unfortunately not - it only works on desktop platforms. It's a C++ library which needs to be compiled (by us) for each platform we support. Android/iOS is possible in principle but we haven't done it yet (will be a long time coming I think). Webplayer will not be possible.

Do you mean the Unity terrain editor or the Cubiquity one? You are making regular Unity terrains and then converting them into .vdbs?

No, because most volumes can't be converted into heightmap form (e.g. if there are caves, overhangs, etc).

Yes, this is basically what I mean (if it fits with your workflow). The heightmap should be smaller than the VDB I would imagine.

Great!

It is under the standard Unity asset store license. The source is included for the C# and shader code but not for the C++. Real 'open source' is more than just 'source available', but we are trying to move in this direction (slowly - I'm struggling for time these last few months due to moving house).

No, this is not possible. Perhaps you can elaborate on what you are trying to achieve with this?

Yes, the explosion code does exactly this, as it only spawns debris for cubes on the surface. See here: https://bitbucket.org/volumesoffun/...viewer=file-view-default#ClickToDestroy.cs-70

If the C++ code was available I think there are a couple of things people would do with it:

• Port to Android/iOS. This is a popular request and shouldn't be too difficult for someone with good knowledge of (template-heavy) C++ and mobile development.
• Add new voxel types (e.g. Minecraft-style voxels with materials instead of colors). However, this requires really diving into the workings of the C++ code.

However, the Cubiquity interface is already quite low-level so I think you can achieve most tasks by building on the existing framework, or possibly be modifying the C# code.

I only saw you question after I had already written the answers above, so let me do some tests and get back to you.

 

hi david i created a little voxel engine myself , nothing quite as grand as yours but its getting there , ive open sourced it to the community hoping they can help out in the creation and making it better as well as making voxel engines easier to access , i just thought if you get the time you might want to check it out and let me know what you think and possibly if you see any room for improvements , thanks the link is http://forum.unity3d.com/threads/community-driven-voxel-terrain-engine.356552/

 

Yes, it should be possible. I admit I'm a little hazy as to the exact rules but I was able to do the following:

• Open any scene except the ColoredCubesExampleScene (so the .vdb won't be locked)
• Click on Assets/Cubiquity/Examples/Basic/VoxeliensColoredCubes and go to the inspector.
• Uncheck 'Open as read-only'
• Now open the ColoredCubesExampleScene
• Open ColoredCubesVolumeData.cs and comment out '(!Application.isPlaying)' as shown below:

Code (CSharp):

1. bool saveChanges = /*(!Application.isPlaying) &&*/ (writePermissions == WritePermissions.ReadWrite);

• Enter play mode, make some changes, and exit play mode.
• The changes were saved and are now visible in edit mode.

I hope that provides a useful starting point.

@dudester - It looks very interesting, though unfortunately I don't have time to really play with it. But if you have any questions about any tricks or techniques which we use in Cubiquity then don't hesitate to ask.

 

Hi All,

First time here with Cubiquity. First of all, congratulations David, you have an amazing work there.

I was trying to run Ellandar's terrain generation example and got the following weird problem:

The first offending line is this:

Code (CSharp):

1. ColoredCubesVolumeData data = ColoredCubesVolumeData.CreateEmptyVolumeData(new Region(0, 0, 0, (int)mapDimentions.x - 1, (int)mapDimentions.y - 1, (int)mapDimentions.z - 1));

That should be this one:

Code (CSharp):

1. ColoredCubesVolumeData data = ColoredCubesVolumeData.CreateEmptyVolumeData<VolumeDataType>(new Region(0, 0, 0, (int)mapDimentions.x - 1, (int)mapDimentions.y - 1, (int)mapDimentions.z - 1));

Then the error changes to:
CubiquityGenerator.cs(39,84): error CS0246: The type or namespace name `VolumeDataType' could not be found. Are you missing a using directive or an assembly reference?

The point is, VolumeDataType is accessible from VolumeData. I tried including CubiquityGenerator inside Cubiquity and Cubiquity.Impl namespaces but the issue persists.

Am I missing anything?
BTW, where is Cubiquity's DLL located?

Regards,
R.

References:
http://forum.unity3d.com/threads/vo...plugin-built-with-c-and-polyvox.180334/page-5
https://bitbucket.org/Ellandar/ellandarsterrainbuilder/

 

Thank you, it is saving now.

 

Hi @DavidWilliams and thanks again for your reply. I hope your move is going well! In my experience moving is right up there with doing taxes in terms of enjoyment. ;-)

Sorry for the confusion, I think something is getting lost in how I'm communicating. I built the smoothed terrain volume in the Unity editor using Cubiquity as a sculpting tool. From that sculpt, a vdb file is automatically generated from Cubiquity and is replicated and steamed to the client for each "cave" the client explores. Any kind of edits to this cave are sent from the client to the server, where they are then saved and sent to any additional client who tried to access this cave. (So they have the most up-to-date revision of the cave)

That makes sense in theory, but I think the problem is that I can't generate a heightmap from my cave volume and send that over the network (to the best of my knowledge). My clients are going to be editing their caves constantly throughout the life of the game and sending those updates to the server. What would need to happen is the server to be able to export its latest heightmap (since edits would have occurred since the start of the game) and send that over the network to the client when they try to access a cave. To the best of my knowledge, Cubiquity doesn't support this export-to-heightmap functionality, so I've just resolved to sending the large vdb file instead.

Hope that makes sense! I'll be producing a small video of what I've done with Cubiquity soon, maybe that will make what I'm trying to do a little clearer.

 

For those who are interested, I asked Ellandar himself about the issues and he kindly updated his code to the latest version of Cubiquity.

 

How do you smooth a cubiquity terrain?
SetVoxel(x, y, z) has int parameters, so the terrain becomes a little cubic.
The generated TerrainVolumeData has an editor GUI to smooth a terrain's mesh but I couldn't find the corresponding code.

 

Ops, found it:

They are at TerrainVolumeInspector and TerrainVolumeEditor.

 

Right, this is correct, there is no good way to store general voxel data (with caves, etc) as a heightmap. Conceptually you can store it as multiple layers but this will get messy fast, and won't be better than just sending the .vdb.

@Rod Galvao - Glad you found it, it's also possible to write smooth terrain directly into the volume, but it requires a good understanding of density fields and the Marching Cubes algorithm. Smoothing afterwards may be easier depending on exactly what you are trying to achieve.

 

Hi David,

Is it possible to write smooth terrain directly using Cubiquity's most recent version?
Is it possible to create cubic voxels in a terrain volume? (like a wall or a bridge)

Thanks,
R.

 

Yes, though it's fairly complex. Have a look at the ProceduralGeneration example to see this. You will also want to read the MaterialSet documentation

I believe it is possible to set the voxel values so that they form cubes, but I haven't tried it and can imagine some tricky edge cases. However, depending on what you want to achieve you could actually overlap a Cubiquity terrain volume with a colored cubes volume. See this post: http://forum.unity3d.com/threads/cu...plugin-for-unity3d.184599/page-2#post-1630784

You could scale them separately to get more detail.

 

Yes, you documentation has it all!
Sorry for asking then, I should RTFM.

 

I'm trying to understand how Cubiquity works with its weights approach.

So I ran this code:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. using Cubiquity;
5.  
6. [ExecuteInEditMode]
7. public class MaterialSetTest : MonoBehaviour
8. {
9.     void Start()
10.     {
11.         // The size of the volume we will generate
12.         int width = 128;
13.         int height = 32;
14.         int depth = 128;
15.  
16.         //Create an empty TerrainVolumeData with dimensions width * height * depth
17.         TerrainVolumeData data = VolumeData.CreateEmptyVolumeData<TerrainVolumeData>(new Region(0, 0, 0, width-1, height-1, depth-1));
18.        
19.         TerrainVolume volume = GetComponent<TerrainVolume>();
20.         TerrainVolumeRenderer volumeRenderer = GetComponent<TerrainVolumeRenderer>();
21.        
22.         volume.data = data;
23.        
24.         // This example looks better if we adjust the scaling factors on the textures.
25.         volumeRenderer.material.SetTextureScale("_Tex0", new Vector2(1f, 1f));
26.         volumeRenderer.material.SetTextureScale("_Tex1", new Vector2(1f, 1f));  
27.        
28.         // Let's keep the allocation outside of the loop.
29.         MaterialSet materialSet = new MaterialSet();
30.  
31.        
32.         // Iterate over every voxel of our volume
33.         for(int y = 0; y <= 8; y++)
34.         {
35.             for(int x = 0; x <= 8; x++)
36.             {
37.                 byte w0 = (byte)Mathf.Clamp(x*32, 0, 255);
38.                 byte w1 = (byte)Mathf.Clamp(y*32, 0, 255);
39.                 materialSet.weights[0] = w0;
40.                 materialSet.weights[1] = w1;
41.                
42.                 data.SetVoxel(x*2, y*2, 0, materialSet);
43.                
44.                 Debug.LogFormat("@({0}, {1}, 0) -> x={2} y={3} w0={4} w1={5} w0+w1={6}", 2*x, 2*y, x, y, w0, w1, w0+w1);
45.             }
46.         }
47.     }
48. }
49.  

And got this result (orthographic camera):



These are the Debug.Log calls:

I read the material but still don't get it.
So, what is the formula for defining a individual voxel size based on its weights?

 

It's actually a little more complex than that. Firstly I recommend you read through some existing material on the Marching Cubes algorithm. You don't need to understand enough to implement it yourself, but having a general understanding will be useful.

Have a read here: http://paulbourke.net/geometry/polygonise/

The key point is that the algorithm does not process a single voxel at a time, but instead processes them in groups (cubes) of eight voxels at a time. For each edge on this cube the voxel values are compared to a threshold value (in Cubiquity it is 127). If one of the pair of voxel is above the threshold and the other is below, then the surface passes though this edge and so a single vertex is emitted.

The relative values of the two voxels then define how far along the edge the cube is placed.

Overall I really recommend you don't work with multiple materials until you understand the shape of the generated meshes. And don't worry if you are confused - it is complicated and hard to get your head around!

 

anyone had any luck converting a magica file to load in on a mac yet ?

better question.... has anyone managed to run ProcessVDB on a mac ? is this an app/application? or what is it... how can it be run ? it doesn't respond to command line / Terminal.
The mac thinks it is just a document file.

Do I need to do something with the libCubiquityC.dylib file ? install it somewhere special on mac, or setup a 'path' to it , maybe environment variable ?

Or how about making an exporter for Magica.. to export a .vdb directly... looks like it supports exporting a lot of formats. ?

 

Another question, since Cubiquity doesn't support multiple textures for colored cubes volumes, i was thinking maybe i should use multiple colored cubes volumes, each one with a different texture. however, you've made very clear that this could and will affect performance. And that makes sense, because more meshes are being drawn even if you can't see them, and could affect the loading time.

But say im willing to put up with that, what else should i be aware of? how expensive is the operation behind the reconstruction of a volume when you modify it? If i modify say, 4 volumes at the same time, would this affect performance significantly?

 

Unfortunately I'm really not very familiar with OS X, but I do recall that I was able to run the executable myself during testing. Can any other Mac users confirm whether it runs for them?

But yes, it is a command line application. On Linux you need to set a permission bit (chmod) to tell the operating system a file is executable. Perhaps OS X is the same? Can you do an 'ls -l' on the directory containing the application?

I believe it just has to sit in the same folder as ProcessVDB. As part of the build process I take extra steps to strip the path out of the executable (using 'macdylibbundler'). I believe it will give you an explicit error if the library is not found.

I'm not sure I follow... Cubiquty colored cubes volumes are not textured - each voxel is just a single color. You can apply a normal map though (the same normal map is applied to every voxel in the volume).

Or you are talking about modifying the shaders to apply a real texture, and then have a separate volume for each material in your world? A rock volume, sand volume, grass volume, etc?

 

I'm sorry i mean materials, like one volume for bricks another volume for grass...etc. What I would like to know is how expensive would be to have 4-8 volumes each one with it's own material, and being modified at the same time at run-time, like if a grenade goes off next to a house made of bricks, it would be removing some voxels from the house (1 volume) and from the grass (another volume).

 

Thanks David, appreciated on all the answers. I do get a permissions error when trying to run it on mac, even though am the admin. I try using "sudo" to force it to run (that gives temp admin privilege to allow running an app) but that doesn't work either... the permission error goes away, but some other path error appears, have resorted to just doing it on a pc now anyway

 

I don't really have a clear idea how expensive this is I'm afraid. All I can really say is that I would expect the cost to be linear with the number of volume. That is, I would expect two volumes to be twice as expensive as one volume. You might benefit from spreading the changes over a few frames though?

Overall you'll just have to test this and see how it performs on your target system, but it won't be an efficient solution.

 

Important - Reflections on Cubiquity and finding the path forward

Hi guys,

As you may have noticed, Cubiquity development has slowed down over the last few months as I've been increasingly busy in real-life. As such I'm having to make some tough decisions about how and where to focus my time, and Cubiquity is going to see some cuts. I've written a long blog post about this and the opening text is below:

"When we began working on Cubiquity the main idea was to expose our PolyVox library through a higher-level interface and tools. PolyVox is powerful and flexible, but requires a strong knowledge of C++, templates and computer graphics to use effectively. By wrapping this in Cubiquity and integrating it with Unity/Unreal we were able to bring (some of) it’s capabilities to a larger audience.

The project has been a reasonable success, with a lot of interest from the Unity and Unreal communities and even a game launched on Steam using the technology. However, it is also clear that the original vision is simply too large to finish as a personal side project, especially with diminishing amounts of free time and a desire to adjust my work/life balance. This led to use recently releasing the system for free, but further steps need to be taken to actually reduce the scope.

In this blog post I want to outline the areas in which I/we will be cutting back on development, and explain how it will affect existing users. I also want to define a direction for a future ‘Cubiquity 2.0′ such that it is both smaller and also more technically interesting to work on. This means shifting the focus to research rather than delivering a drop-in system, open-sourcing the complete technology stack, and reducing (but not eliminating) the level of integration provided for Unity and Unreal."​

I strongly encourage you to read the whole post as it will have a significant effect on Cubiquity for Unity3D. In particular:

Reduced focus on the Unity integration

"We began working on Cubiquity around 2012, and at the time Unity was taking the indie game development world by storm. It was providing a cheap yet powerful platform and was being used by a huge number of indie games. As we were aiming to sell Cubiquity it made sense to provide an integration layer with Unity. However, from a technical standpoint it was quite a poor fit for a few (related) reasons:

C# .vs C++: Cubiquity is written in C++ but Unity scripts are written in C# (or sometimes a variant of JavaScript). This means we had to write a C interface around Cubiquity and then call that via C#’s P/Invoke magic from Unity.

No plugin support on Unity Free: Plugin support was a Pro-only feature on Unity 4, so we had to resort to some tricks and hacks to get Cubiquity loading properly. This feature is now free in Unity 5 but we haven’t had time to update our scripts to take advantage of it.

Need to compile libraries: Because Cubiquity was provided as a native-code library we have to compile it for every platform we wish to support. So far we have only supported Windows, Linux and OS X, but with both 32 and 64 bit versions that’s already six libraries to build and test.

Platform support: For the reasons outlined above, it has not been practical for us to support all platforms. Mobile has so far been too much work, and webplayer is simply not possible due to the use of native code. This causes some frustration for users who build their game and then find they cannot export to the platform of their choice.

Some of these problems disappear with Unity 5 and our move towards open source, but we are stuck with the C# vs. C++ issue and the need to compile separately for each platform (though we now defer that problem to the user). By contrast, integration with Unreal should be much more straight-forward, and has mostly been held up by lack of time/resources (see below). In this case we would simply be able to drop our Cubiquity C++ files into an Unreal project.

I’m honestly not sure where I’m going with this. Unity is still a massively popular game development platform, and from what I’ve seen it is probably easier to get into than Unreal. I do expect we will still provide some degree of support for it, but with higher technical requirements on the user and less in the way of Unity-specific examples, documentation, builds, etc. But really we’ll just have to see how the next version of Cubiquity develops, and how well the algorithms match with the architecture of Unity."​

Please feel free to ask any questions you have about this change of direction.

 

Hi guys! I need your help, how I can use models from Qubicle editor, as I know ProcessVDB can convert only magicavoxel's files, maybe someone have tool for doing it?
Thanks)

 

Hello...

First thanks for this awesome asset... it really rocks...
Everything works fine... but i have a weird problem... when I do game build nothing shows up in the web player ?
I placed the player 100's of units above the terrain, giving it time to build... i waited about 15 minutes..wellll...
Is there some script i have to add, or is there a setting i miss ??

Kind regards: Youelle

 

Cubiquity doesn't support the web player,
Here, explained by David himself:

----------------------------------------------------------------------------------------------

@DavidWilliams Will this shift in focus affect the support you have given to us through the different forums? for the current version of Cubiquity? I understand if it does because you mention something about research and Cubiquity 2 (cubiquity 2 yay) etc.

Perhaps not the best news for Unity users, but I understand what you're saying, motivation is important.

 

@cpt1985

Thanks for the answer

 

Is Qubicle able to export MagicaVoxel files, or vice-versa? I had a feeling such conversion was possible. Aside from that there is also VoxelShopp, which might have some conversion options?

Unfortunately MagicaVoxel is the only application format which can be imported directly.

I don't think forum support will really suffer - generally I try to check the forums a couple of times a week so that people get a reply in a few days. And the current version of Cubiquity is still the most complete system we have. The biggest impact for existing users is that a large number of planned features now won't happen, or will at least be moved to Cubiquity 2.

 

I've had some problems with basic colors, basically theres no material on the top side of voxels using basic colors.



As you can see the top sides of the cubes on the left have a plain color, whereas the other sides (including bottom) have the material correctly assigned to them.

This behaviour seems to occur only with basic colors:
Black (0,0,0)
White (255,255,255)
Red (255,0,0)
Lime (0,255,0)
Blue (0,0,255)
Yellow (255,255,0)
Cyan (0,255,255)
Magenta (255,0,255)

Everything seems to be working fine with any other variant of these colors (as seen the cubes on the right in the picture above). Am I doing something wrong? or it's a bug perhaps?

 

I see, thanks.
Also I have one more question, I'm using per-vertex ambient occlusion generator for creating per-vertex ambient occlusion baking like this, then I'm using a standard shader modified to support vertex colors of models and this works with default mesh render but not with cubiquity models, is there a way to do this?