Cubiquity - A fast and powerful voxel plugin for Unity3D

lol oops

Well at least you know its being well tested !!!

 

Yep, and ultimately every user is going to want t push the system until it breaks... that's part of the nature of game development. You identified some interesting issues here but nothing I'm too concerned about - I think it should be possible to get the volume transforms behaving the way you expect for the next snapshot.

 

Hi guys, it's been a quiet couple of months (unless you've been following our 'Works in Progress' thread) but we've made some more great improvements to Cubiquity. The focus has been on tidying up the system and implementing support for volume transformations, such that volumes can now be translated, scaled and rotated, as well as participating in transform hierarchies. Our latest video shows how this can be used to create a simple 'solar system' scene with the Earth and Moon both orbiting and still being editable in real time:

[video=youtube_share;NLQozqoPMho]http://youtu.be/NLQozqoPMho​

This is something which was discussed a lot in the last few posts in this thread so I'm pleased it's working quite well now. The video also shows off a new texturing approach in which planet textures are pulled from a cubemap.

Anyway, you can watch the video above and also download the snapshot to play with it yourself:

• Download snapshot (currently Windows only)

You can stay up-to-date with the latest developments on our 'Work in Progress' thread or by following one of the links below:

• Our blog: http://www.volumesoffun.com/blog/
• Twitter: http://twitter.com/volumesoffun
• YouTube: http://www.youtube.com/user/VolumesOfFun
• Google+: http://plus.google.com/115713574213289812029
• Facebook: http://www.facebook.com/pages/Volumes-Of-Fun/290520264304213
• Bitbucket: http://bitbucket.org/volumesoffun/cubiquity-for-unity3d

Do try it out and let us know what you think

 

Very Nice Work!!your work Looks great though I just downloaded it and is preparing to have a try .Really hope it can create photo-like scences like the " Atomontage Engine" . But after I imported the preview package to editor ,there comes some compiling errors like "Shader error in"arse error at line 1 " "Shader error in'ColoredCubesVolume': Syntax error at line 26" , how to sovle this problem??I'm using Unity 3.5,can it be vertion problem ??

 

Thanks! I suspect the problem is indeed the version of Unity you are using. The system is only tested with 4.2 at the moment, and I think there are some significant differences compared to the 3.5 series. We could back-port to 3.5 is there is enough demand for it but currently there are no plans for this.

 

just for 4.2 is all right,I'll change to 4.2 and have a try

 

AWESOME mate, i will try this , a question: is it possible to put a heightmap to the voxels here? so i can make a "premade" land, and after can edit it?

 

Hey, glad you like it There is no automatic way to import a heightmap (though I intend to add this in the future) but you can implement this yourself if you can do some programming. There is an API to let you set individual voxel values, and a couple of relevant examples showing procedural generation of terrain and also converting a 2D image of a maze into a volume.

The basic idea is that you iterate over each voxel in the volume and set it's density based on whether it is above or below the corresponding position in the heightmap. This gives you the terrain shape, but assigning materials would be an additional step. I can give you more tips if needed.

 

Hey guys, I'm excited to say that our latest snapshot of Cubiquity now fully supports OS X and Linux (in addition to Windows)! I know there's been some demand for this so it feels great to finally have all the desktop platforms covered.

​

It should work just as well as the Windows version so please download it and give it a go. You can get the snapshot here:

• Download Cubiquity for Unity Preview 06 (All Platforms)

As always, you can also get the latest developement version of the code from our Git repository:

• Cubiquity for Unity on BitBucket

We've been hard at work on Cubiquity for almost a year now and we're very close to making the first official release on the asset store (hopefully by the end of April). The commercial license is expected to be $200 per-seat, but the system will remain free for non-commercial and evaluation use.

Use the links below to stay up-to-date with the latest developments:

• Our blog: http://www.volumesoffun.com/blog/
• Twitter: http://twitter.com/volumesoffun
• YouTube: http://www.youtube.com/user/VolumesOfFun
• Google+: http://plus.google.com/115713574213289812029
• Facebook: http://www.facebook.com/pages/Volumes-Of-Fun/290520264304213
• Bitbucket: http://bitbucket.org/volumesoffun/cubiquity-for-unity3d

Let us know how it works for you

 

Superb! Thanks for supporting OSX, will deffo check this out now!

 

We're really happy to support it - sorry it took longer than expected but we came through in the end

 

Is there a way to undo carve/destroy in-game?

 

At the moment there is no built-in solution for this. For small changes you could simply record which voxels you have changed - just a list of (x,y,z) positions and their old values would suffice. This is probably OK for up to a few hundred voxels, and then you could revert the changes just writing the old values back into the volume. For larger changes you would want a more elegant solution.

You've probably noticed that changes get reverted when leaving play mode. This functionality is built into Cubiquity and it would be nice to extend it in the future into a more general-purpose undo system. There is a little more information about that here: http://forum.unity3d.com/threads/18...lyVox/page14?p=1543349&viewfull=1#post1543349

 

how can i remimplement the voxel cubes like your old versions cause thats what struck me with the asset?

 

Thanks for posting here - I understand from your PM that you are looking to create this kind of voxel data:

​

Cubiquity no longer includes that as an example, but it is still possible to create such a terrain by simply writing the appropriate values into the voxels. A Cubiquity volume is basically just a 3D array of colors, and you can set any voxel to any color with the 'SetVoxel()' method of ColoredCubesVolume.

To be more specific, you should start by looking at the 'Maze' example. This takes a 2D black-and-white image (the maze) and sets the height of the maze floor based on whether the pixel in the image is black or white. You should be able to adapt this code to use a greyscale heightmap as input and then set the height of the 'floor' based on the greyscale value.

After that you can replace your 2D heightmap by the output of Mathf.PerlinNoise() in order to generate a random terrain. But we'll come to that once you have the heightmap working.

 

Hi David,

I thought you might be interested that I'm working on a water simulator for your engine, with the intention of releasing after your engine is out. Ideally i'd like to release at the same time but I'm a while away from releasing yet and by judging your bitbucket updates lately it looks like you are getting close!

Here's the WIP for the project: Liquid Voxels for Cubiquity

 

Fantastic stuff! I'll post my questions and comments on your thread, but I'd like to embed a screenshot here for people who didn't follow your link yet (check it out!):

Yes, the first official release of Cubiquity is getting close now. Actually I don't intend to modify the code any further, except for serious issues found during testing. Most work is now going on documentation and then preparing for release!

 

It went really smoothly! Worked straight out of the box, no modification required.

[video=youtube_share;15LV56nFsJg]http://youtu.be/15LV56nFsJg

-Ell


Edit: Sorry, wrong thread. May as well leave it here, activity is good .

 

This is it! Cubiquity for Unity3D is now available for purchase on the asset store, while also remaining free for non-commercial and evaluation use. Please give it a try and let us know what you think!

• Download fully-functional non-commercial and evaluation version
• Read online user manual and API documentation
• Purchase commercial version on the Unity Asset Store

​

Many thanks to everyone who has shown us support so far - although we are now on the asset store the journey is really just beginning. We've got lots of cool plans for the coming months!

 

Hi David,

Congrats on the release! I'm very happy for you.
Well done on all the work you've put in to make this happen too, I hope the release goes well!

 

Wow! This looks totally awesome including the supplementary water asset. It's definitely on my to-buy list once I've finished with my current project

 

i just ran this up and looks fast and excellent frame rate.. will have to experiment more...

i have tried loading a heightmap using the ColoredCubeMazeFromImage.cs but i dont get the heights... may need to edit the script.

i believe this will be able to support multiple heightmaps? if so, how do we stitch the terrains to make it seemless?

will it be able to support rtp shaders? splat/color maps?

 

Thanks guys!

The example doesn't load the image as a heightmap (though with the benefit of hindsight that would make a lot of sense), instead it applies a threshold to decide whether a pixel represents the floor or a wall (see this line of code). You can adjust the example as you suggest - see my comment here: http://forum.unity3d.com/threads/18...nity3D/page4?p=1606047&viewfull=1#post1606047

Sure, as long as you can decide how the multiple heightmap should be interpreted and so write the correct values into the volume. Are you looking to stack the heightmaps up to make multi-layer terrain, or to break down your map into a set of tiles?

In general you don't, you should create a single large terrain instead (you could still read data from multiple heightmaps). This is more efficient and internally Cubiquity will break it up into chunks anyway.

Cubiquity does support multiple volumes but they are intended more for when you want to apply a separate transformations to each one, e.g. to have planets orbiting each other.

I'm not exactly sure. The smooth terrain material does need improving and I'd like to provide our own versions with normal/relief mapping, but I don't know if it will work with external texturing systems such as RTP. Probably it can be made to work as the material blend weights are just passed as vertex colors, but I think some refactoring of our material system might be needed first.

 

The example smooth terrain scene seems to be very slow to update terrain changes. I realize the mesh collider update is slow, but there is a great deal of garbage collection happening simultaneously. I am not sure I am convinced of the benefits of smoothed cube terrain vs optimized march against chunk, other than grid vs point alignment (which a gutter should let you work around?) -- perhaps you could go into a bit more detail into the smoothed terrain process/algorithm? Is it just a simple tessellation + lagrangian/linear interpolation? What might the advantages be over something like a dual contour octree (where the dual grid is essentially offsetting the point-based grid back to the cube centers)?

UPDATE: Maybe this is OS X related somehow? Terrain deformation seems real-time here: https://www.youtube.com/watch?v=auKomEGDNwA

 

So basically terrain volume and cube volume are completely different voxel world solution? There's really no connection between the two? I was hoping something like using terrain volume for realistic terrain and cubes for buildings etc. I've seen few voxel terrain engines but I always have hard time imagining building buildings using them, and also making realistic terrain using cubes too.

 

Volume rendering typically has the following characteristics:

Input

A voxel grid -- voxels are either cubic cells, which have a single value covering their entire cubic region (Minecraft) or density data points at the corners of cubic cells, where the value inside the point is interpolated from the edges of the cube.

Rendering

Indirect Volume Rendering (IVR) - Surface tracking, Isosurfacing (Marching Cubes, Dual Contouring)

This runs your voxel grid through an algorithm that steps through each point in a grid and finds a 'surface.' Voxel grids are generally flattened 3D arrays representing floats of greater or less than 0, depending on their distance to the surface (0). If a voxel of air has a density of -3 and the voxel beneath it has a density of 2, then these two voxels together will be represented as one vertex of a triangle at the 0 point that is calculated in space between these two voxels. Then once all of these points are identified, the algorithm plays connect-the-dots to create faces (triis/quads depending on the algorithm) between these points.

There are various techniques that use lookup tables (marching cubes) of primitive shapes to speed-up or make shortcuts around this process, and then there are functions that use quadratic formulas (QEF, i.e. in Contouring) to implicitly interpolate faces at calculated locations.

The "Dual" you hear about in isosurfacing is a conversion/calculation process that creates a 'shadow' grid that basically generates a Minecraft-like grid (but of smooth floats, not boxy integers) of the cell corners and faces. This can create a more stable/shape-fitting (and less generally rounded) shape. For example, with generic Marching Cubes, you can never have a perfectly square square -- the edges will always be beveled by the privatives used in the lookup tables. Think of this affect as aliasing. Contouring, skeleton climbing, surface nets are instead trying to calculate these hard edges to avoid this. The algorithms spend more time calculating, but create smarter meshes that use fewer polygons to achieve higher details.

When you modify the volume (terrain), you are adjusting/recalculating the density values of the grid instead of 'deleting' or 'creating' something. A terrain is usually made up of a pool of volume chunks. When you modify the terrain, you are generally modifying one chunk and its neighbors and then re-meshing and re-colliding the chunk.

Ruaumoko, TerraVol, TerrainEngine and Cubiquity in "smooth" mode all use variations of this technique.

Direct Volume Rendering (DVR)

The simplest example of direct volume rendering is with ray casting. From your camera's perspective, for each pixel being rendered to screen, shoot a ray outward from the camera and find all of the points/nodes/entities in your volume that are alongside the path of the ray. Stop the ray depth search at the point where a voxel would be less than 1 pixel in size on the screen OR you hit something beyond a transparency threshold (solid). These become a 'stack' of density that you render from back-to-front. The benefit of this is that LOD is built-in to the algorithm because the rendering energy is mostly spent only on things that would map to pixels on the screen.

With this process, instead of rendering and generating an approximation of a surface from a coarse grid (1m blocks in Minecraft), you ideally want a grid that is high-resolution enough that there is always a voxel smaller than 1 pixel at the camera's nearest clipping point (1cm/1mm blocks). Then you don't really care about the material or texture of that voxel -- it is only one pixel on the screen. A single color at one point. You just need to calculate the color of the pixel based on the lighting and its transparency (and thus any pixels behind it/in the water).

There are plane/cone-casting variations that slice and minimize the number of true rays needed.

I believe this is basically what the Atomontage engine is doing.

Data/Memory Management

Here's where things get tricky. Accessing the entirety of any reasonably sized voxel grid in real-time is slow, and anything you do to speed up the process balloons your memory usage by requiring you to store additional copies/variations of that grid (pointers to neighbors, etc) -- the data itself should be "LOD aware" also, or you are iterating through large parts of a grid that will have no visual effect on the rendering of this frame from the camera.

That's where concepts like BSP trees, KD-trees and Octrees come into play. Octrees, for example, creates multiple grids for each "level" of LOD that are interpreted from the level beneath it. At a certain distance from the camera, you can decide to stop looking deeper because this one vertex that you are about to render is small enough on the screen that you do not need it to be represented by 4 more detailed vertices instead, so you don't even need to look at the data for the deeper level. Stop and move on to the next chunk (IVR) or pixel/ray (DVR).

Then you have data compression techniques that can be applied to combat the ballooning memory requirements of these data access crutches -- generally, run-length encoding (RLE) is used to average an area or strip of the same value. 16 voxels in a row with the value "-10" could be stored as a single larger virtual voxel with the value "-10x16" -- so now you are regaining some of that memory but paying more CPU time.

But now that you are accessing your data in completely abstract ways, your caches are missing, so you need another virtual (pre-sorted/"supersorted") array so when you access data, the data surrounding it is near that data physically in some way.

And then when any change happens to a volume, all of these 'shadow' grids need to be rebuilt in some way.

- I am sure I messed up/forgot several key details above .. please feel free to correct and fill in.



Basically, volume rendering is a game of trade-offs. Both IVR and DVR have been basically fully ported to the GPU by now in some form or another. I believe TerrainEngine has a GPU-based IVR implementation and are hesitant to release their product cheaply (or with demos) because of their investment in that piece (and the ease of extracting it?).

The others for Unity are CPU-based IVR implementations.

Cubiquity is interesting not necessarily because of where it is at today, but because of its direction. In cube mode, it is basically DVR with primitives instead of ("screen space") pixels. In smooth mode, it is IVR isosurfacing.

What this gets you is the ability to scale the size of the cubes smaller to get more detailed smoothed data that is alway 'stable' because you are always rendering something with substance vs an interpolation of points. The cubes in Cubiquity are relatively large today by default in their CPU implementation, but if the direction their heading is "toward" Atomontage, then to me that means they are focusing on the biggest elephant in the room -- the data access/memory management algorithms needed for quick shallow dives into deep trees.

Back to your original question -- you can make building-like shapes in any voxel/volume-rendering engine. The differences are mainly in how sharp edges are handled vs extra polygons needed to represent hard-enough edges. I would recommend defining functions that return "brushes" of shapes. i.e. what would the data array look like for a wall? Then you are basically imposing that brush into the terrain and its neighbors appropriately when it is placed.

Cubiquity lets you add multiple 'volumes' to a scene. This means that you could have one volume represent the terrain, and another sitting on it that represents a building, and transform those volumes independently from each other. Or you could add a wall material block-type and operate the main volume by placing wall blocks (add that block-type to the appropriate location in the voxel data grid).

With point-data voxels, you generally are not operating on a single cube or point/vertex at a time, but using a brush that selects all of the points that fit within a shape. If you want to delete something, you have to adjust the density of the volume and basically subtract from the right density value, which will lower the height of the vertex for that point. Do this to the right points and you have subtracted/added your shape. The disadvantage is the density recalculating/resurfacing necessary. The advantage is that you can reproduce smoother shapes with fewer, larger voxels.

With cubic voxels (like Cubiquity/Minecraft/Atomontage?), you are actually removing a cube-shaped object (of ?? size) from a grid. The advantage is that working with the data can be more straightforward. The disadvantage is that you are generally removing a fixed-sized shape, or a series of fixed-sized shapes. If you can get the voxels small enough to not need smoothing (1 pixel), this is ideal.

 

This plug-in looks very nice, for what i have seen so far!

Is there any chance that you add hexagon shaped voxels in addition to the standard cubes ones?

 

Hi all, sorry for the slow reply but I was travelling yesterday. While offline I wrote jason.fisher a reply to his first post, and will get back to the rest of you soon.

I haven't found the performance to be too bad, though I'm also sure it can be improved significantly. Certainly the MeshCollider is a bottleneck but I expect we can improve that in the future by using a lower level-of-detail for the collider compared to the renderer. I expect we'll see higher performance and scalability over the coming months as we polish some of the internals.

Regarding the video, that was recorded on my fairly powerful desktop PC which is about a year old. If the performance on OS X is worse than Windows then this needs to be fixed. Note that there are different performance characteristics between edit and play mode (edit mode has sculpting but doesn't maintain mesh colliders).

I'm not sure what you mean by 'smoothed cube terrain vs optimized march against chunk'. Cubiquity uses the Marching Cubes algorithm for generating the terrain, which operates on a density field. There's no need to worry about alignment - internally the volume is broken down into chunks, but this is an implementation detail as the algorithms just see it as a single large volume.

The density field is linearly interpolated between voxel positions, and the vertices are then placed at the point where this interpolated density crosses a threshold.

Dual contouring in a more flexible and generally superior solution, though it does require additional information to be stored per-voxel. Actually we do have an implementation of this inside PolyVox (the library which Cubiqity uses) but we haven't exposed it to Cubiquity yet. Perhaps in the future, though I think we want to further develop the system that we have first.

 

OK -- thanks for clarifying. That makes sense.

Just four more questions:

It looks like you are using octrees, but I am not seeing a way to use that to affect LOD yet. I believe I am after a solution with a depth stop that creates an array using the averaged QEF density value in the parent nodes for the march of the lower LOD rather than reaching into leaf nodes. I believe this also means I need to use a dual grid with a calculated vertex from the center of the node chosen for that vertex for visual stability as the LOD changes and the parent mesh gets hidden and its children displayed?

I have a very specific use case with a high top-down tilted camera angle. I would like to use octree-based LODs to render the perimeter of a terrain scene at low detail and the area near the camera at high. The high detail area is limited, the low LOD area is vast. Is there any chunk/paging/tiling support?

This makes me think that I should be using octree surface nets for the right balance between scale and triangles? Is there a way to interact at a lower level with Polyvox or Marching Cubes? Feed a custom marching algorithm a subset of an Octree? Or call into the Octree with a depth-stop and receive a density that I could process? Or maintain my own octree structure that I am feeding to your march? I would like to leverage your asset where I can.. I can write anything/any language, but I know it will save me time, I am just not certain of the right approach.

 

The two volumes types are separate and intended for different purposes - they simply build on the same underlying idea of representing the world by a 3d grid of voxels. They can co-exist in the same scene but I don't think the art style would really match.

You can use the terrain to create buildings as well, though generally it's hard to get the sharp edges that you would need. Perhaps we will add an example in the future.

Enhancing the system so that it can be used to build anything is interesting, but it will be a while (a year?) before we really look at that.

This isn't supported, and actually you are the first person to have asked. It could be considered but only if we feel there is enough demand for it.

Correct - some of the LOD infrastructure is in place but it isn't actually used or exposed yet.

This is basically what we will do, except we are working with densities (Marching Cubes) not QEF.

I can't give a clear answer here as we're not working with a dual grid method, but generally there is indeed some care needed to line up the LOD levels.

This is basically what we are working towards. We do have chunk/paging system in place, though we haven't made much use of it yet as it's currently the vertex data which is having the biggest memory impact. This is an area for future development

Generally speaking you can't interact much with the lower-level aspects of the system - e.g. you can't add a new type of surface extractor. PolyVox is a complex and highly-tempatised C++ library, whereas Cubiquity tries to simplify the interface and expose the most commonly needed functionality. We will be exposing more parameters in the future, e.g. to control the distance as which LOD transition occurs.

 

Thanks for your insight! I'm sure others will also find it useful.

After reading your post, I simply tried copy&pasting terrain volume into cube volume in another demo scene and it was very impressive. Well...I'm not sure if that was what you intended and it's a bit waste of CPU/memory but it looked just like what I wanted, cubes below and above realistic surface.

Then I found out cubes can only be colored x_x Do you have any plan on adding texture renderer for colored cubes?

 

Not at the moment - we were trying to avoid being accused of jumping on the 'Minecraft' bandwagon and so deliberately did something a little different, plus I really liked the retro art style of the colored cubes (we used this for our game Voxeliens). But textured voxels is quite a popular request. All I can say is that there are no plans at the moment but it could potentially happen in the future.

 

Understood, thanks for the answer!

 

Hi Noanoa,

There's a neat trick you can do with Cubiquity, which I implemented a few months ago that worked unexpectedly well for my game.
Create a smooth terrain of a certain size and make it look how you want.
Create an empty voxel terrain of the same size of the smooth one, and place it in exactly the same world location as the smooth.

I then created an interface that allowed my units to select which terrain they interacted with.
If they did a series of terrain based actions:
Dig,
Place Dirt,
Mine,
etc.
Then the interaction would be with the smooth terrain.

If they did any of the build/destroy actions:

place block
remove block
then the interaction would be with the cubic terrain.

There are a couple of things you need to take care of. One is when manipulating the smooth terrain, you could dig out from under a cubic block which would make the item float in the air. All I did there to fix that problem was a couple of simple checks that occur before changing the smooth terrain, and if it would cause something to float, then I did one of two things (depending on conditions in the game):
1. scaffolding would appear to 'support' the structure.
2. The unit would get a thought bubble saying "I shouldn't do that, my <object name> (house usually) will fall on my head!"

So anyways, the final result was cubic objects/houses/concrete slabs etc on a smooth deformable terrain. So much win there

Cubiquity seems to allow a lot of tricky stuff

Picture is worth more than a thousand words in my case, because I'm so unclear!



- Ell

 

As a follow-up comment.

You can also spawn individual cubic terrains for each of your cubic items you wish to implement.

For example, You could use my previous method to generate large scale items, like walls, buildings, floors etc. Then spawn more cubiquity terrains for each object you want to put in the building, make the scale .25 or something like that and you will get a better resolution for creating smaller objects.

David created a terrain tool, but I'm sure he wouldn't mind if you stretched/poked/prodded/squeezed/bashed it into a form that makes it work for you.


- Ell

 

I just imported the latest evaluation version and I am getting this error:
InvalidOperationException: Nullable object must have a value.
System.Nullable`1[System.UInt32].get_Value () (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System/Nullable.cs:108)
VolumeData.get_enclosingRegion () (at Assets/Cubiquity/Scripts/VolumeData.cs:46)
Cubiquity.TerrainVolume.OnDrawGizmos () (at Assets/Cubiquity/Scripts/TerrainVolume.cs:86)

Is there any quick fix?

 

I downloaded the evaluation version of Cubiquity and I'm going through the quickguide here http://www.cubiquity.net/cubiquity-for-unity3d/1.0/docs/page_quick_start.html. On the step: "Creating your first colored cubes volume", after I select the new volume (it displays correctly) i get the following error when I press play:

CubiquityException: An exception has occured inside the Cubiquity native code library.
Error code 'CU_SQLITE_ERROR' with message "database is locked".
Please see the log file 'Cubiquity.log' for more details.

Cubiquity.Impl.CubiquityDLL.Validate (Int32 returnCode) (at Assets/Cubiquity/Scripts/Impl/CubiquityDLL.cs:51)
Cubiquity.Impl.CubiquityDLL.AcceptOverrideBlocks (UInt32 volumeHandle) (at Assets/Cubiquity/Scripts/Impl/CubiquityDLL.cs:178)
ColoredCubesVolumeData.ShutdownCubiquityVolume () (at Assets/Cubiquity/Scripts/ColoredCubesVolumeData.cs:107)
VolumeData.OnDisable () (at Assets/Cubiquity/Scripts/VolumeData.cs:205)

Here's a pastebin of the Cubiquity.log file: http://pastebin.com/2Xz1SQtN

Restarting Unity doesn't help, neither does making a new scene.

Edit:
However when I created a new project the issue was resolved.

I attempted to retrace some of my steps, but I was unable to reproduce the issue.

 

@Ellander - Yes, this approach is interesting. It would be pretty cool if Cubiquity could handle some of that for you - e.g. I imagine it would be possible to have a surface extractor which works with multiple voxel types. The first few bits could represent the type of the voxel and then the normal voxel data would follow. If a surface extractor was aware that this mechanism was being used then it could be more intelligent about hiding internal faces.

I'm not planning to work on the above at the moment but it could be an interesting future direction

Can you elaborate on what you did to make this error occur? Did you add a volume, edit it, press play, etc? What happens if you create a new scene, new project, or restart Unity?

I'm not clear exactly what happened here, but the interface to the voxel databases can be a little tricky. Each Cubiquity volume asset is basically just a link to the underlying voxel database (in the streaming assets folder) and it can be difficult to keep these properly synced up. For example, if you duplicate an asset then you end up with two assets both linked to the same database. I'm not saying this was exactly your problem but something similar can occur given a complex enough series of operations. I'll try to look at ways of making this a little more robust.

 

Hi David,
in regards to that CU_SQLITE_ERROR, I recall seeing something similar quite a few months ago when duplicating a vdb using ctrl-d.
At the time we were having discussions about things like undo and capabilities like that as at the time unity editor functions weren't supported; so I didn't report this error as it wasn't a supported operation.

Give me 2 min, i'll just go confirm this one for ya.

--- Back after testing ---
Yeap, that's it.

Reproduction:
create a new volume, assign it to a terrain, click play: all is good.
click stop, select the new volume data asset in the project and press ctrl-D.
click play, you should now be looking at that error.

Hope that helps.

-- Back after really reading your response properly --
Ok, this was nothing new, you already mentioned this possibility in your previous post..

Pretend I was never here <slides quietly off, sneaky like>.

- Ell

 

only terrains with old database get that error, creating new terrain works fine
adding the old data to new terrain gives error too
restarting/play doesnt help

 

Don't worry, I only suggested this because you had previously tipped me off that it could be a problem ;-) It's tricky to fix because I don't see any obvious way that Unity lets you hook into an asset being duplicated, but I can probably add a consistency check and warn the users if two assets are found to be pointing at the same database.

Can you clarify which platform you are on (Windows/OS X) and which volume type you are working with?

So, you are able to create a new volume, and then you are trying to replace the default volume data with another one. You have obtained a .vdb file from somewhere (one of the examples?), converted it into an asset, and then you try to set that asset on the current volume? This is when you get the error?

I'm away from my development machine for a few days but will try to reproduce this later in the week.

 

I used the old asset on current volume but now that i have converted the old .vdb into new assets the error is gone

 

Right, sorry for the slow reply, I'm now back at my dev machine and have reproduced the issue. I've logged a bug report here: https://bitbucket.org/volumesoffun/.../56/invalidoperationexception-nullable-object

I'll try to get this fixed for the next version - thanks for the feedback!

 

Thanks, I have reproduced this myself and can confirm it is a bug in the example. Basically the required material is not being copied into the standalone build so it isn't being found at runtime. I've logged the issue here:

• https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/issue/57/missing-shader-on-fading-cubes

Actually your timing is quite good - over the next few days I was planning to improve the colored cubes material so I'll make sure this gets fixed at the same time.

 

Can you elaborate on the approaches you have tried? I should point out that the 'Click to Destroy' script is really just an example of something you can do with Cubiquity, and is not a core part of the engine. Therefore you should feel free to split/edit/refactor the code in a way which makes sense from a networking perspective.

To give an explicit example, the Update() function handles mouse input and currently directly calls DestroyVoxels(x, y, z, range) when a click occurs. I can imagine you would want to separate this, so that when a mouse click occurs you simply broadcast the click position to the other clients. Those clients would receive the clicked position and call DestroyVoxels(...) on their own volume. Note that no voxel data is actually communicated in this scenario - you are simply synchronizing the actions which take place.

You can see something similar in this Unity Answer about regular terrain (not Cubiquity). Note how they just communicate 'raiseTerrain' and 'lowerTerrain' messages rather sending the actual terrain data.

 

Hey guys, I just wanted to provide a quick update on what we've been up to since the initial release. The main focus of our work is currently on performance and robustness - e.g. improving the backend to resolve the database-locking issues and to increase the size of the voxel environments which we can support. We expect this will be ongoing work for the next few weeks/months, but we'll probably release the next version of Cubiquity in mid-July with some of the enhancements in place.

But from time-to-time it's nice to take a break from that and work on more 'visible' enhancements, which is what I've been doing this past weekend. I've added normal mapping to the voxels in the 'colored cubes' volume and this really lets them stand out as individual tiles. Of course, it responds to the light source moving in the scene and continues to work after voxels are separated from their volume and are bouncing around the scene.

​

This is work-in-progress so you can only use it if you are brave enough the get the development code from Git (but note that it's only built for Windows at the moment). The rest of you will get it for all platforms when we make the next official release.

@duder5495 - This will also fix the missing material bug which you reported.

 

G'day David,

Work has kept me away from Unity for 2 weeks now; but now i'm dying checkout your latest git commit, that looks seriously good!

Haven't wanted to get home to try something this badly for a long time

-Ell

 

Thanks! I've also now added a very subtle diffuse map to the voxels as well, so each voxel is no longer completely uniform in color. you have to look hard to see it though:



Anyway, it's all checked into the develop branch of Git now, so I'll look forward to seeing how it looks when animated with water

 

Hello David, we spoke in a conversation about how editing the values of the voxel carve script. What I meant when scaling everything down was reducing the size of the terrain and the size of a carve range. Because setting the range from 1 to 3 was still too much for me. If I were able to set the scale to 1.5 or 1.7 I would have a much more pleasant time. The range variable is an integer of course so there's no luck in having that. When scale everything up, so that using ranges like 2 is a small increase from the range of 1, but then I have trouble with rendering a large terrain and the script still working.

 

There are basically two ways in which you can measure the size of the terrain. Firstly you can define it in terms of the number of voxels - e.g. a terrain volume might have a base of 128x128 and a height of 32. Secondly, you can consider the scaling factor which is applied on the terrain's transform. This lets you control how large each voxel is in terms of Unity's coordinate system, so that you can say each voxel is 0.5 meters, or 3 meters, etc.

Now, the 'ClickToCarveTerrainVolume' script is quite basic and operates directly on the voxels without considering the scaling factor. For each voxel it either deletes it (if it is within range) or leaves it alone. This script cannot partially delete a voxel, and so the range is always an integer value. If you apply a scaling factor to the transform of the terrain then this will affect the size of the carving as well as the size of the terrain.

However, partially deleting voxels is possible in principle (even though the 'ClickToCarveTerrainVolume' script does not do it) if you understand how voxel density fields work. We use this in the editor for smoother editing of the terrain. But you probably need to wait for us to expose it (and add an example) before you can use it in play mode.