Cubiquity - A fast and powerful voxel plugin for Unity3D

There may be a minimum volume size (I forget exactly) as internally the volume is stored as chunks of voxels (perhaps 16x16x16?). What is the use case for such small volumes? Can you simply create a volume of the minimum size and then leave some of it empty?

 

That is what im doing, but just wanted to mention it. Also why a flat surface made of many voxels isnt just 1 face (2 triangles) rather smaller chunks of like 5 voxels are faces?

 

Also in code i noticed you mentioning LOD but saying its not finished and would be updated, yet you say you are working on a new Version rather than an update (will the second version be free?)

 

The faces for adjacent voxels are indeed merged together where possible. The merging may not be perfect but it is pretty good. However, faces can only merge if the two voxels have (almost) the same colour.

Indeed, the plan has changed over time. The current version is no longer being updated and LOD will not get finished. However I am working on a replacement system , it will be free, and it will support much larger volumes (possibly via LOD). I hope to release a prototype of the new system later this year.

 

ADDING smooth terrain in play mode. Hi,
Great plugin by the way.
Could somebody help me with a bit of example code on how to add voxels to the smooth terrain style in realtime in playmode. I wanted to make a little game where you dig with a shovel or fill in or flatten terrain.

 

Any solution to making them rigidbody - fyable? Its giving errors that its a mesh collider so it wont work, maybe make chunks have box colliders or each block have a box colider (that would kill the performance tho).

Also the lighting is just plain wrong. If you add a point light and remove the sun light you can notice how on pressing play the light isnt same as in scene view - its worse (like just the top get lit and such) but that might be the problem with the maze generator scripts (maybe you need to triangulate using mesh.triangulate() after generation) but i cant triangulate it if there is no MeshFilter component! so you might wanna add a mesh filter component and a mesh renderer component and instead of custom rendering , just pass the voxel mesh to the mesh filter component and let unity do the rendering

 

The TerrainExampleScene demonstrates removing chunks from the terrain but to do more complex changes you need to understand the MaterialSet class which is complicated. Alternatively the core library already contains more advanced editing functionality as used in edit mode, but I didn't yet write the Unity scripts to expose this in play mode. I've you are a strong Unity programmer you might be able to do this yourself.

Not really, Cubiquity is intended for representing maps and environments rather than objects within those environments. It might be cool to have whole volumes behave as rigid bodies but I don't think there is an easy way do that at the moment.

You might indeed find that some lighting combinations fail, lighting is a little complex because there are no per-vertex normals as normals are instead generated on the fly in the shader program. I think this will be an issue for deferred shading as well. I'm not going to fix this in the current version though, it will be something to keep in mind for Cubiquity 2.

 

David, I love your work! It seems ideal for what I'm working on. I've got two questions:

1) There's PickSurface, PickFirstSolidVoxel, and PickLastEmptyVoxel. Is there a function like PickLastEmptyVoxel but for a TerrainVolume instead of ColoredCubesVolume?

2) I'm interested in simulating physical stability (long horizontal platforms won't hold and will collapse. Floating structures will fall). What do you imagine is the best way to accomplish this? Is there a way to add custom data to each voxel?

Thanks.

 

Ay david please check out Voxelstein3D , id want to make something simillar so ya better make dat LOD work

 

So like 1 cm sized voxels, lots of them

 

Thanks! Always good to know it is appreciated!

I didn't think these functions made sense for TerrainVolume because the voxels are continuous values rather than just being 'on' or 'off'. Voxels are considered to be points in space and the surface passes between them rather than touching them. I assumed that for the TerrainVolume that finding the surface would be more useful than finding the voxels.

You might get something reasonable by slightly adjusting the returned position (moving slightly away from or towards the player) and then clamping the resulting position to integer values. I'm not sure how well it will work though.

You will need to keep you data in a separate structure as you can't add data to Cubiquity voxels. Just keeping it in a separate 3D array would be the easiest starting point. Perform the simulation on your array, and then set/clear Cubiquity voxels as required.

The hard part will be the actual simulation and I'm afraid you'll have to do some research here! But you probably want to use some kind of breadth-first search or flood fill to determine voxel connectivity? You could also Google for 'connected components labeling' and 'Morphological Image Processing' (particularly 'closing' for breaking off weakly connected components?). It's complex stuff through.

Yep, Voxelstein3D is built on the Voxlap engine which is still amazing today, and it was written over 10 years ago! It's by the Ken Silverman, the same guy who wrote the engine for Duke Nukem 3D back in the 90's.

However it's quite different from Cubiquity in that it doesn't generate meshes and so is more difficult to integrate with a modern game engine like Unity. All modern engines are based on polygons whereas Voxlap uses a technique called raycasting.

None-the-less Voxlap is a huge inspiration to me. If it could be done over 10 years ago then surely it could be done better today? I would say the modern equivalent is something like Atomontage Engine, though there's no demos of that so it's hard to tell what it's limitations really are.

My intention for Cubiquity 2 is to support much larger volumes via a technique known as 'Sparse Voxel Octrees'. There are several research papers and demos of this technique but so far there is not much actual use in games. The tech won't make it back into Cubiquity 1 though so you will have to wait a while.

 

I apologize for what is probably a simple question to some of you, but it has been asked here before and I still cant figure it out!

How do we change the "destroy on click" for the colored cube volume to something that reacts to collision instead?

I know it is possible, but I am just too new to unity to figure out exactly what part of the clicktodestroy.cs code to cut out. If someone could advise me, I would be eternally grateful. (I am trying to use the tank and shell from Tanks! tutorial, if that helps) Thank you!

EDIT: Especially stumped by this line
"bool hit = Picking.PickFirstSolidVoxel(coloredCubesVolume, ray, 1000.0f, out pickResult);" would I need to change the "ray" here to something else if I was working with collisions?

 

The key part is the DestroyVoxels() function:

Code (CSharp):

1. void DestroyVoxels(int xPos, int yPos, int zPos, int range)
2. {
3.     ...
4. }

In my example code I use picking to determine where the user has clicked, and then I call this function with the resulting position:

Code (CSharp):

1. DestroyVoxels(pickResult.volumeSpacePos.x, pickResult.volumeSpacePos.y, pickResult.volumeSpacePos.z, range);

But in general you can get position of the explosion from anywhere. You can even just hard code it, so after loading the volume you could call e.g:

Code (CSharp):

1. DestroyVoxels(5, 5, 5, 20); // Destroy voxels near the lower-left corner of the volume.

In your particular case you need to get the position from the shell. Can you print this position out when the collision occurs? If so you should be able to pass this position to the DestroyVoxels() function.

I'm imagining you probably don't need this at all, as you don't need to do picking. You want to get your position from somewhere else (the shell position).

 

Thank you very much David for this plugin, the PolyVox engine that makes it work, and sticking by it in a support capacity.

I'm a GIS geographer turning "edutainment" game dev, and new to Unity. I got contacted by an old university friend after he "discovered" Minecraft (6 years late) and how people were pulling in real world landscapes. He wanted help building a digital introductory physical geography lab in it. Something students could "play" with their children or young relatives. I kept trying to tell him there were better options, and I finally got a chance to show him with a quick build using Cubiquity and the mangled height map (that 255 vertical limit hurts) we were using as the core of the MC world. He finally got it, and we're moving fully into Unity.

I just wanted to drop a few lines here while I get myself up to speed on Unity and the Cubiquity API. One thing I'm looking to do is see about working on the import process for DEM data. My idea is to pull the position and elevation information out of a GeoTiff and feed it to the VDB by SetVoxel. I could do it with an ASCII Gridded XYZ, but parsing text files was never any fun. The experimental import from the ProcessVDB works well enough for a rough pass, but getting more than 255 height values is where I need to go. It think I can do it with BitMiracle's LibTiff.Net. If I'm understanding things so far, that should also let me assign more than two materials, or set it up as cubes?

Oddly by accident, bring in the height map PNG through ProcessVDB at 25% scale resulted in a rending that's matching up with some recent sampling data for the area being covered by the lab. The blue is where the modern riverbed is. Red actually aligns roughly were the sampling indicates old river cuts used to be, before it got on its modern track. From a VDB stand, it looks like some of the "sub-surface" (soil texture) flagged voxels ended up exposed when the mesh rendered, creating that mixed soil and grass pattern. Just one of those quirky things when going about Geo-visualization.



Once we can get the university to cough up some money, what would be the best way to support you and Matt?

 

Very interesting! But I'm a bit unclear - are you looking to work with the ColoredCubesVolume or the TerrainVolume (you seem to mention both)?

With the ColouredCubesVolume I'd be surprised if a height of 255 was really a problem, as the length and width are likely to be much greater than the height for normal shaped terrains? At any rate I'm not sure this limit is hard-coded anywhere, I think it is just the default height for a new volume (sorry, It's been a while since I worked with my own software!).

If you are looking to work with the TerrainVolume then be warned, importing heightmap data and getting nice results is a surprisingly difficult problem. You can of course just set a voxel to be solid if it is less than the specified height but this results in jagged terrain (which might be fine if you like this art style). But if you want smooth terrain then I don't think moving to 16-bit height is actually the solution. Instead you need a fancy filtering solution to try and set the density of a voxel based on how far it is from the interpolated isosurface. You can see my attempt in the code to the ProcessVDB tool but I was never that satisfied. And as you have observed there can be problems with materials bleeding through.

Still I wish you luck! If you can get the result you want then great, but just be aware that the artefacts you currently see may not be easy to solve. Or if you can add some constraints that might also help - I was caught up in trying to make everything as generic as possible.

We used to sell this plugin as a commercial offering, but receiving such money raises the expectation to provide support and continue development. Right now on more focused on a successor (Cubiquity 2) and this current version is largely abandoned, so I appreciate your offer but will decline financial reward at this point.

 

Also please dude make it work on mobile devices i always wanted to make a game like CortexCommand and i wanted to do 1 block thin but very wide terrain and maybe use the maze generator and adapt the code to generate terrain like in cortex command from a side image, but i really want it to run on android ;-;

 

Any info on making it work on mobile?

 

I'm sorry, but development of this engine really has finished as I am now working on version 2 instead. Adding mobile support is not a simple task as the underlying C++ library would need to be ported. It is technically possible (I believe someone was experimenting with iPhone) but you'll need strong C++ and Android development knowledge.

For version 2 I will aim to keep the C++ part simpler so it can be ported more easily, but it is still a long way off. You best bet for now might be to try one of the other Unity voxel engine which already support mobile but they may lack features compared to Cubiquity.

 

So when should the 2 come out?

 

I hope to release something this year, though the initial release will be more of a tech demo than a finished product. Unfortunately I don't have as much time as I used to, which is why I stopped selling Cubiquity and turned it into a free asset.

 

Why not put it on github and make it open source? I bet people will even port it

 

The current version of Cubiquity is already open source and available on BitBucket. Version 2 will be open source as well (and will probably move to GitHub) but at the moment I'm still researching the algorithms so it's too soon to release it.

 

I just found cubiquity a fews days ago and like it. kind working on the terrain generation but on the cube terrain side. Does anybody already have or maybe have ideas if its possible to change the shader for rendering? I'd love to render the sides of the cubes in a different color than the top. Lets say green for gras on the top and brown as dirt on the the other 5 sides. Is it possible at all? Thanks for any ideas.

 

You can change the shader (all the source code is included) but I don't think you'll get the effect you want. If you change the shader so that the top of the voxels is green then *all* the voxels will be green on top. Cubiquity only stores a single colour per voxel and no other data, so it is not really intended for making a game like MineCraft (it is more suitable for something like Voxatron).

 

The bump shader from the last page gives me an error in 5.5:
"Shader error in 'Triplanar bumpy': undefined variable "texTriplanarNormal" at line 196 (on d3d9)"

I also see some people say it is not recommended to get 8 textures working in the default shader....what are the problems?
The lighting on my terrains looks fine but it's a bit simple. Also some textures appear really bright on it while others do not and there doesn't seem to be any brightness or specular options for the materials I drag in so I am pretty sure it's because of the shader code since I use the Skybox Intensity slider to raise the lighting up.

Here is how my terrain looks now with the Triplaner shader. I believe it's not bad at all, just missing something....


I wonder perhaps on how I would go about replacing these shaders with the default Standard Shader that Unity supports so I can benefit from all the fancy lighting features.

 

I'm sorry, I haven't actually tried this approach, I just saw the NVidia article. I doubt if the code will 'just work' though, it will probably need some porting for the Unity shader system.

Cubiquity is rather heavy with it's texture fetches at the moment. Applying a single triplanar texture requires the same texture to be read three times, and doing this with eight textures is a lot of reads. Plus there is all the overhead of blending. For sure it can be optimised but I didn't get around to it.

I wrote the terrain shader for Unity 4 so it pre-dates most of the fancy 'new' features. I haven't looked at the Unity 5 system in any detail, but I think a lot of it is based around pre-calculating aspects of lighting so it may be complicated to implement with dynamic terrain. Other complications include the lack of texture coordinates (which is why triplanar texturing is used). To be honest I'd have to do quite some research to determine the best path forward, and that will have to wait until Cubiquity 2.

 

No worries then, still without a doubt the editing capabilities of the tool and it's simplicity are amazing.

However I really would like the brush size, power and opacity settings to not be shared but instead unique for all the panels because right now every time I want to smooth, lower or paint they all require me to adjust the sliders because each brush panel requires different settings to work best, so if they had their own individual settings which aren't all shared by each other then it would save a lot of time if you know what I mean?

 

Interesting, that would actually make a lot of sense and I can see it would help usability. It won't get changed in the current version of Cubiquity but I'll keep it in mind for version 2.

 

So when is 2 comming?

 

No change from my previous answer I'm afraid!

 

Hello guys,

I want to create my own cube area from code. This is going to be like mountain, and after that I am going to specify some of this cubes from c# code and when I clicked mouse, this specified cubes are going to fall like ColoredCubes.

If you can help me, I will be really appriciate.

Thank you so much, waiting your reply

 

Any new amazing stuff that wasnt in the original (1.0) ? Or improved rework

 

Do you just mean you want to generate your volume from code rather than loading it from disk? If so this is possible - have a look at the maze example that comes with Cubiquity as this generates the maze volume from code based on an input image. After you have created an empty volume you can use setVoxel() to build whatever you want. If that's not enough help you'll need to be more specific about exactly where you are getting stuck.

The main aim is to switch to using a Sparse Voxel Octree to represent the volume, with the aim of having much larger or more detailed volumes. I'm expecting that the rendering algorithm with also change (probably it won't generate a mesh from the volume but will really render it as a set of cubes) but this isn't really certain yet.

 

I really wish if you could "expose" the components, like when if you try to do rigidbodies on the voxels it gives an error that the mesh collider isnt convex, even tho if you click there is no mesh collider, so why isnt the component showing?

 

Also i just have to point out once more the rendering of the voxels is very incorrect, for example in the "ColoredCubesExampleScene" the direction light isnt even lighting the voxels correctly! Go ahead and look in that scene and try changing the intensity it wont even change the brightness of the model, just the sides even tho the light is pointing from top. This makes it unusable if you want to do for example minecraft and have a point light torch as it wont even light the terrain (it will just light some faces that but not the ones you expect)

I suspect its the fault of the shader, as if you add the standard one it works as expected (more or less)

Well i dont know the F*** happened but after switching back form standard to CCmaterial it works like it should. ??????????????

Welp i found out it works well in editor (looks as it should) but lighting gets messed up after you hit play.

WHY??

 

How to see for yourself: Start the colored cubes example, run, then mess with light and notice how the terrain looks, then try rotating the directional light and notice its still bad

 

Well its quite wierd now, it looks good in game view but bad in scene view (good = correct lighting, bad = incorrect), so it seems it chooses if it wants to work or not -_-

 

When disabling HDR it looks fine, when you enable HDR on the camera it looks incorrect. Now lets hope thats the only reason why its not working otherwise i have no idea what else is causing it

 

So now i cant use any post process effects

 

Hello How do you change the dirt and grass texture in the colored cubes version? I couldn't find anything in the documentation.

 

The system is much more complex internally than what is shown on the surface (don't forget it's actually a C++ library, the Unity/C# stuff is just a wrapper). For example, internally the volume is broken down into chunks, each chunk is rendered with a separate mesh, and each chunk has a separate collider (if required). This means that when a voxel is updated only the relevant parts need to be regenerated.

So although you want to be able to see the collider on the volume, really there isn't one. There are instead many colliders, and the user does not want to have to worry about which voxel belongs to which one. Therefore these kind of details are abstracted from the user.

As for your question about the internal data structure, Cubiquity does not use a C# array. It is a native library which stores it's data in an internal format (actually an SQLite database). Your only way of accessing the voxel data is through the GetVoxel()/SetVoxel() functions. I have never done and network programming, but I expect you need to define a simple data structure (e.g. just a list of changed voxels) which you can pass across the network to apply the same changes on multiple machines. I doubt if you can easy pass the Volume class across the network directly.

There are indeed some problems with the lighting, as mentioned previously it will sometimes calculate normals which point the wrong way (I think that is the cause of the issues you are seeing). I got it working fairly well under Unity 4, but I didn't have time to get it working properly under Unity 5 (which introduced a new lighting system) before I stopped working on the project. The normals seem to depend on a lot of factors including Unity version, platform, render system (Direct3D vs. OpenGL), edit vs play mode, etc. Ultimately the approach used does not seem to be robust, and probably normal data needs to be passed in with the mesh rather than computed in the shader. I think it's a case of doing it again rather than fixing it, so I'll take a different approach for Cubiquity 2.

I'm sorry, I haven't tried any of the post-processes effects (nor related techniques such as deferred rendering). It's quite possible there is some interference, maybe from the lighting system again.

The colored cubes version does not have textures (each voxel is always a single color) so you can not change them.

 

Hi David, great work on Cubiquity, it seems a really good tool for voxel landscapes. I am a beginner with 3D modelling so I have a noob question unfortunately. Is it easy for the coloredcubes shader be reused in imported .obj, fbx files (e.g. a voxel avatar) so that a 3D model avatar style can match the Cubiquity colored cubes volume style with bevel and quantized colors? I have had a play around, and looked around online but I can't seem to find any solution or tutorial to do it. I am using voxelmagica to export baked .ply files into blender so as to use vertex colors and then out as .fbx to be imported into unity. Apologies if this question gets asked a lot. If you can point me to a tutorial or previous response that would be excellent!

 

Hi, I think you should start by looking at the FakeColoredCubes shader. In the example this is applied to the cubes which are spawned and bounce around the terrain as the user destroys it. I'm not sure if it works on other meshes but you can try, and if you have any shader knowledge you might be able to get it to work.

You can see it being applied to the cubes here: https://bitbucket.org/volumesoffun/...iewer=file-view-default#ClickToDestroy.cs-159

Hope that helps!

 

Cubiquity removed from Unity Asstet Store​

Hi guys, just a heads-up that I have removed Cubiquity for Unity3D from the asset store (it remains available on BitBucket). A number of recent questions have highlighted the fact that there are some problems with the more recent versions of Unity and unfortunately I don't have time to investigate these as I am trying to focus on Cubiquity 2 now. I don't want to promote a system which I am not able to support so I decided to remove it.

I think it remains available for those who have downloaded it previously, but even if not it is still available on BitBucket. Hopefully there will be news on the replacement system in the coming months but I expect I will create a new thread for that.

You can also read about this in my latest blog post: http://www.volumesoffun.com/removing-cubiquity-from-the-unity-asset-store/

 

Does the bitbucket (current) version support LOD for marching cubes? (like smooth voxel terrain) , can it be used to make a planet which will decrease / increase in lod?

 

The version on Bitbucket is basically the same as the version that was on the asset store. Unfortunately I didn't get the LOD system into a usable state before I stopped working on the project.

 

removed

 

About ColoredCubesExampleScene of CubiquityForUnity3D.
Did Colored Cubes Volume convert the Terrain Volume in TerrainExampleScene?
Or did you make it from scratch?
I am looking for a way to convert. But I can not find it.

 

I had actually made it previously for the game 'Voxeliens': https://bitbucket.org/volumesoffun/voxeliens

I think that I generated it procedurally (from Perlin noise) but it was a long time ago so I can't remember the details. But this was before Cubiquity really existed. I think the smooth TerrainExampleScene was actually created from the cubic version, by doing a kind of 'blurring' (smoothing) in 3D space (quite complicated!).

Read this page for some ideas about getting cubic data into Cubiquity: http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/page_obtaining_vol_dat.html

You can also generate the volumes though code, as demonstrated by the 'Maze' example.

 

Soo ma man when the 2 commin up :C