Cubiquity - A fast and powerful voxel plugin for Unity3D

Important: This version of Cubiquity is no longer under development and is being removed from the Asset Store (though it remains available in our Git repository). A replacement 'Cubiquity 2' system is under development but not yet publicly available.

About Cubiquity
Cubiquity is a flexible and powerful voxel engine for both the free and pro versions of Unity. It can be used to create terrains with caves and overhangs that can be edited in real time, or to create retro-style environments from millions of colored cubes.

​

Unique features
Cubiquity is far from being the only voxel engine available for Unity, so what sets it apart from the competition? You might be interested in the following (mostly exclusive) features:

• Support for both smooth terrain and colored cubes type environments.
• Built on a C++ native code library (but works with the free version of Unity).
• Support for multiple volumes which can exist in transform hierarchies.
• Unique material blending algorithm on smooth terrain.
• Direct voxel access for implementing procedural generation.
• Publicly accessible Git repository and issue tracker.

You should also find that the volumes behave similar to other Unity3D objects. You can drop them in the scene, transform them, edit them, and apply different materials. It's not simply a voxel terrain system but a general-purpose voxel engine.

​

Download for free!
You can download the fully-functional system for free. No need to wonder whether Cubiquity is right for you - just give it a try and see!

• Read online user manual and API documentation
• Get Cubiquity for Unity from our Git repository

​

Current limitations
The system is under active development, and even though we are already on the asset store we have lots more work to do. Watch out for the points below, but remember the system is free!

• Only desktop platform are supported (Windows, OS X, Linux). You would need to compile the C++ code for other platforms yourself.
• Volumes size is currently limited to a few tens of millions of voxels.
• Not many import/editing options (but you can generate volumes from code)

​

Follow us
You can also stay up to date with the latest developments with the following links:

• Our blog
• Twitter
• Google+
• YouTube

 

Looks very cool. I wonder what texturing options you have, and if you allow for smaller batches of meshes composed of a lot of chunks, as this would probably mean smaller meshes being uploaded to the card and less cpu time. But you're the expert so I'll listen to what you say. Great work btw!

 

Thanks!

The underlying PolyVox library supports many options including Minecraft-style texturing or triplanar texturing for smooth (marching cubes) terrain. Even plain coloured cubes can still have normal maps applied. So really it's a question of what we decide to expose through this plugin.

Initially we are focusing on plain coloured cubes while we get the Unity integration running smoothly. Ideally the voxels will become so small that you don't even need textures anymore. This is the idea behind Atomontage for example, and we're already doing some work in this direction:



Note that the image above is from the Gameplay3D version of the engine, but it will come to Unity soon.

If I understand you correctly then the system already handles this. The volume is divided into a number of pieces so you only need recreate/upload the mesh for those which have changed.

 

I'm really looking forward to seeing this available!

 

Glad to hear it! I think we're probably just a month or two away from have an initial version on the asset store, though development will continue long after that. The API is very simple as it's basically just a 3D version of drawing pixels to a image, except the pixels are cubes and the image is a volume.

So once it's a bit more stable we'll put it on the asset store, and then build higher-level features, tools and optimisations over the coming months.

 

Hi guys, just a quick update - for the last few days I've been hard at work on everybody's favorite feature of voxels engines... destruction! In the previous demo voxels could be deleted from the scene, but now they can be separated from the grid and treated as independent physics objects. Let's take a look...









Admittedly the physics was running a little slow by the time I got to the last image but it was a lot of fun I'll try and make a video and get a new demo out in the next week or two so you can try this for yourselves!

 

I've spent some time polishing the explosion physics a bit a made a new video for you all:

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

I really like the way this is coming together and I had a lot of fun shooting up the environment I'll try to release a new version in the next week or two so that you can all play with this yourselves.

 

*** Update - 21st June 2013 ***
We've just written a blog post about the physics work shown in the video above, and also provided a Unity project so you can try it for yourself. Do read the blog post for instructions on what you should do with the files!

• Read blog post
• Download project files

Hope you have fun - we're open to feedback so do let us know if you like it

 

Over the last couple of weeks we've spent some time improving the support for larger voxel environments and improving the integration of our Cubiquity engine. Here's an entire city modeled with voxels and loaded into Unity. Of course it's fully destructible in real time, as with our last video.



The data is taken from here, and we will eventually provide various ways to get voxel data into our engine.

 

Here's a new video - instead of using the 'city' map from the previous post we decided to use this map of an industrial factory complex, as it has a bit more space for the tank to drive around. Compared to our last video it is showing a larger environment and integration of the Detonator explosion plugin. Check it out!

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

 

*** Update - 18th July 2013 ***

You can now download the standalone demo for the above video: Download demo

Have fun blowing up the environment!

Edit: We've also made a blog post with a few more details of our plans: http://www.volumesoffun.com/more-progress-with-the-unity3d-integration/

 

I have a question for you guys - do you only get your assets from the official Asset Store or are you also comfortable using other sources?

Obviously we would like to be on the Asset Store for publicity reasons, but there is some work to be done before the system is mature enough. Because the basic version of the system is free, we have the option of just providing downloads from our website or even putting the code in a public Git repository.

Would early adopters have any interest in this?

 

I would be very interested in the option! I cannot wait to trial out this solution, I have kinda been holding off on some dev work until this comes out so I can evaluate it!

 

That's good to know

At the moment the main limitation is that we have used some assets which we cannot give away for free (such as the tank model), so we need to replace those assets before we go public with the repository. I think it should happen in the next couple of weeks though.

 

Sure. Just some basic placeholders would be fine for testing out the project.

Looking forward to testing this

 

In your tank demo you say you imported a map from Build and Shoot, does this mean the engine has support for AOS files or, better yet, Qubicle files?

 

Currently the engine is able to import a series of 2D images to make up a volume. On disk the data looks like this:

​

I quite like this approach because file managers give a thumbnail preview of the images, making it easy to get an overview of your data (or to edit it in the tool of your choice). Its also obvious how to read/write them. Once imported the data is stored in a more efficeint format with compression, chunking, etc. The above images create the following volume:

​

For other file formats I think we will most likely provide a converter to generate these images, rather then having a direct import option. But this isn't really set in stone yet.

 

Great news! We've just announced the source code and shaders for our Cubiquity integration package are now available on BitBucket, and work with both the Free and Pro versions of Unity3D. This is still an early version of the system, but we're opening up development in this way so that you guys can start playing with it early and can follow it's development as it evolves over the coming months.

You can clone the code from BitBucket or download the snapshot below:

• Cubiquity for Unity3D on Bitbucket
• Download snapshot as ZIP file

We've also prepared a video to give a quick overview of the system and demonstrate how to use it. The video shows how to create volumes using the built-in editor functionality, how to import a volume from images, and how to generate a volume procedurally. It also demonstrates how to interact with the volume in play mode and make modifications to it from code:

[video=youtube_share;6z0jd-J8QMQ]http://youtu.be/6z0jd-J8QMQ​

The BitBucket repo does not include the source code for the native code DLL, but a copy of the DLL itself is provided. You can use the system for free for both commercial and non-commercial use, though the volume size is limited to 256x256x256 voxels. In the future it will be possible to raise this limit by purchasing a license.

 

Hi,

I am getting errors on OSX that the DLL cannot be found. It has been copied into the root by your Installation script (as indicated by the log) but I cannot get it working.

Any suggestions?

Adam

 

Note: OS X and Linux are now supported. Disregard the comment below.

I'm sorry, there is no OSX version at the moment (I should have made this clear). The .dll is only for Windows as it's native code, not C#. We should improve the error message in this regard.

Creating an OSX version will require building the core C++ library on the OSX platform, which should be possible but we don't have an OSX machine to build and test on at the moment. Unfortunately it won't happen until the Windows version is closer to being finished.

 

Ah, thats a huge shame Was looking forward to testing this out.

I will have to use another library then, and will try revisit this when its available for osx.

 

how and what pathfinding can i use for Cubiquity? isit hard? coz im not that pro in programming

 

Unfortunately Cubiquity does not contain any pathfinding at the moment. It is within the scope of the project (i.e. we should implement it in the future) but it's probably a few months away.

That said, I don't know what Unity and/or other plugins provide automatically. Cubiquity does create collision meshes, so there is some chance you can use these with another pathfinding solution. You will have to do some research here.

 

Hey guys!

We've had the Cubiquity code in BitBucket for a few weeks now, but we realize that most people don't want to be messing around with Git. So we figured it would be worth making fairly regular snapshots of the code in the form of a Unity package, as it will still be a little while before we are on the asset store. This will make it easier for you guys to play around with the system. The latest snapshot is below:

• Download Cubiquity for Unity (preview 02)

The main difference from our initial snapshot is thet we've been doing some work on the sculpting of smooth voxel terrain, which the system will support in addition to the 'cubic' voxel style shown previously. Those of you watching our 'Works In Progress' thread will already have seen this.

Before working with the sytem we'd recommend watching both our 'Introduction to Cubiquity for Unity3D' video and also the new 'Smooth voxel terrain' video shown below. These videos comprise the majority of the documentation for the moment, but feel free to ask if you have any questions!

[video=youtube_share;xybv-aldhtI]http://youtu.be/xybv-aldhtI​

Anyway, hope you like it, we're now in the process of adding support for textures which you can paint onto your voxel terrain. We should be showing that off quite soon

 

This looks great! Will we be able to build cube voxel terrains the same way as the smooth voxel terrains above?

 

This depends on exactly what you mean. The 'colored cubes' volumes (shown originally) have only basic editing features in which you can add and remove individual voxels, but in time we extend this with line drawing, flood fill, etc. I doubt if you'll ever be able to 'sculpt' with cubes though.

If you mean whether it's possible to add cubes into a terrain which is otherwise smooth, then yes, it is possible to a limited degree. It's not really the intention of the system though (it's for modelling smooth terrains) so I'm not sure how much we'll expose here.

 

Hey guys!

I'm pleased to announce another snapshot is available, and includes our new texturing system. The main new features are:

• Textures can be painted directly onto the voxel terrain using an interface which is very similar to the standard Unity one.
• Both soft and hard brushes are supported, giving you control of the blending on material transitions.
• Any texture can be painted onto any surface - there's no need to mess around with 'top' and 'side' textures for triplanar textuing.
• We've also done some work on the sculpting tools which now also support both hard and soft brushes for more control.

You can download the snapshot below:

• Download Cubiquity for Unity (preview 03)

If you want to see the system in action then check out our video. This was posted previously in our 'Works-in-Progress' thread so be sure to follow that if you want the latest news and updates. We keep this thread for snapshots and releases.

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

 

Still following the progress on this
Another quick question. Is it possible to not have the landscape smoothed, and be angular? I'll looking for a low-poly look.

 

Great, we're mostly polishing it at the moment (user interface, class layout, etc). The key features we want for release are already in place so hopefully it will be on the asset store by the end of the year.

The terrain uses the Marching Cubes algorithm so angular landscapes are indeed possible. You have direct access to the voxel data so you simply have to write the appropriate values as you generate your terrain. I don't think we'll provide editing tools for this though (at least not in the first release) as we are more focused on the smooth terrain initially.

 

Since it uses native DLL, it doesn't work with Unity Free, does it? Or do I have to do some special magic ritual in order to enable it in Unity Free (I'm open to suggestions)? Also what is status of usage for this in commercial games? Do I have to pay any fees?

//edit: Also I'd like, if it isn't too much hassle to have "mixed terrain". E.g. having advantages of smoothness of Marching Cubes, but still be able to put objects with hard edges (like houses). There are working implementations of this (see Blockscape, it's the best example currently, but you should watch as recent videos as possible since originally Blockscape didn't have smooth terrain), so it is certainly possible.

This would make possible to create whole destructible worlds including non-dynamic features like trees, lamppots, houses, etc.

 

Actually Unity Free supports native .dlls just fine. There are no hacks or tricks required. There is a lot of confusion in this area because the Unity documentation does not do a good job of differentiating between native code libraries (which work with Free) and native-code plugins (which require Pro). Cubiquity is a library but not a plugin, despite what the title of this thread says (I was confused too!).

Note that the above is true on Windows. Cubiquity does not currently run on other platforms.

Actually we just in the process of changing our licensing conditions. I'm halfway through writing an announcement which I'll try to get out in the next couple of days.

This is not the aim of Cubiquity, but it is still possible to do what you want to some degree. Basically you have full control over what data you write into the volume but Marching Cubes imposes some limits on the kind of structures you can create. Actually I'm working on demonstrating this at the moment... there should be something in the next snapshot.

 

OK, Any idea when it'll come to Linux? I understand you don't have access to Mac ATM, but you should be able to set up Linux vm or something. Also I hope it won't be paid solution, there is exactly 0 free voxel libs for Unity.

 

I have plans to work on the Linux version at some near-future point. The underlying library, PolyVox is already working and well supported on Linux but I haven't even started work on Cubiquity itself yet. Linux support will also be the first step towards potential OS X support as compiling with Clang there is simple enough. I can't put any timeframe on when I'll do a test version but it certainly won't be until the new year.

 

Can wait, my game will be in development for at least another year and given it changes license, not sure if even I'll use it at all (this is my first commercial game and my budget is exactly 0, don't want to go into details, but my financial situation is very delicate and can't afford any bigger budget than that).

 

Awesome work you guys are doing David! I'm glad I found this thread, going to enjoy watching the development of this.

 

@Tethys - Thanks Chris, it's always nice to know people are keeping an eye on it

 

New licensing scheme for Cubiquity for Unity3D

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

Free and paid licenses
So far we have said that there will be both free and paid versions of the system, with the free version allowing both commercial and non-commercial use but being limited in terms of features and volume size. As of today we are changing this – the free version will be for non-commercial use only but we will remove all feature and size limitations.

In other words, you will now be able to get the full and unrestricted version of Cubiquity at no cost, providing that you are using it for non-commercial purposes. Even if you are using it commercially you will still be able to use the free version for evaluation purposes – i.e. you can make sure that Cubiquity is right for you before you commit to buying it on the asset store.

The exact terms and conditions are available in LICENSE.txt in the Git repository.

Why is this changing?
The free version of Cubiquity is intended to serve a number of purposes and should benefit both users and ourselves as follows:

• It puts the system into the hands of those who otherwise could not afford it.
• It generates publicity and helps promote the system.
• It allows users to evaluate the capabilities of the system before they commit to a purchase.
• It allows testing and feedback from a larger user-base which results in a better product.

Basically, we feel that all of the above points are better served by the new licensing model rather than the old one.

How and when does it take effect?
The license file has been added to the Git repository and takes immediate effect. Over the next few days we will take steps to make sure that the new license is clearly visible, and will then raise the size restrictions which are currently in place (though technical constraints still remain). Lastly we will produce a new snapshot in the next week or two.

But I preferred the old license! I’ve already started using it on a commercial project!
Don’t panic, we’re not looking to catch anyone out here. If you have already started a project with Cubiquity and you were intending to commercialize it then just send us an email (support@volumesoffun.com) with a brief description of what you have done so far. We’ll acknowledge that you are working on it and you can continue to be bound by the old conditions. However, you’ll also be bound by the old limitations so do consider whether you’d rather switch to the new license for better features and bigger volumes.

Ok, great, but what’s the plan for the commercial licenses?
Well, we’re still working hard. Most of the features for the initial version are implemented but there is a lot of polishing to do. I think we’re still hoping to get it on the asset store by the end of the year, where the plan is to sell it as an editor extension for $200 per seat under the standard asset store license.

That’s not the end of the road though, we’re still only scratching the surface of where we want to go with this system. We’re also really pleased with the feedback we have received so far so please keep spreading the word!

 

Hi guys,

We've finally made another video showing our Cubiquity voxel engine in action, and released the corresponding snapshot for download!

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

The main new features are:

• New file format using an SQLite database.
• New licensing model such that the system is now completely free for non-commercial use.
• Various API improvements to make it easier to work with volumes from code.
• Collision mesh support for the smooth voxel terrains.
• New examples of procedural generation and creating a maze from an image.

More details are available in our latest blog post: Cubiquity for Unity3D progress update (Nov 2013)

You can download the snapshot here (Windows-only at the moment):

• Download Cubiquity for Unity3D (Preview 04)

Hope you like it and let us know what you think!

 

I know this is long but I figured that as the engine is still under development I would put in my wish list because I'm seeing some real magic here.

Ok some interesting observations i've seen in other engines which would be cool to get a "cubiquity take" on ...

1. Grass,
voxeland for example has a block setting to enable the engine to automatically add grass to the top surface when that block type is used.
its a great looking effect to an otherwise simple scene, but I would love to see a gpu shader based implementation in cubiquity for this.

2. Trees,
An odd one, I think they should still be voxel based but are hard to get right ... maybe a tree generator or something?
Any chance you guys might want to give this one a go as a cubiquity feature?
My thinking here is a sort of L system might be a good place to start, with c++ doing the grunt work it could be fast too.

3. That quality look,
This engine sells itself short by having some pretty basic textures (my personal opinion, you might disagree).
Put some nicer textures in the package guys and maybe do something smart with lighting or something to "enhance" the default look.

Some other cool features I would love to see added in the future (super rare and usually costly to buy if they exist at all) ...

1. Cool tools in the editor,
It would be cool to be able to do things like draw something in the unity editor and then use that as a template, so I could draw a pillar with voxels then copy it and either save it for later use or paste it somewhere else.
Volume management,
The ability to merge, split or select volumes based on either specifying a bounding box or for example selecting an object using a ray.
Maybe a means of arbitrarily declaring a new voxel based game object and dumping data in to it by adding other voxel objects as either data or children in some way.
Mesh to voxel tools to allow anything from the asset store to be imported as voxel data.
I know tools are on the current hit list but figured you don't get unless you ask right?

2. In game tools,
I noticed that more and more games these days are getting "sandboxy" (in the minecraft sense of the word) allowing players to alter the world.
I'd like to be able to specify that my editor defined objects can be used as tools so for example maybe if i dig with an axe it digs differently to if I dig with a shovel with the shape of the tool having an impact on the way the voxel data is altered.
The other neat thing there is that i could draw my axe with voxels in the editor then give it to my in game character to use.

3. I'm pretty sure everyone asks this daily but here we go .... Water,
Fluid simulation and voxels on todays hardware is a nasty proposition but at a more basic level (like minecraft) something can be achieved.
My thinking here is that this may be part cpu part gpu code, this type of thing built in to the voxel engine going to be huge!!!

4. Voxel weather,
A neat voxel based cloud system, rain system and other similar features.
If this was possible in some way along side everything else here, unity users would only need 1 package.

 

omg ... this exists ...

http://www.youtube.com/watch?list=UUnAnbwdbzRvFhQGCAVdh4Pw&v=V04dswEIcQU&feature=player_detailpage

can we have this too please

I know, crazy thing to ask but it's the nature of voxels to be able to write a procedure to do what I lack the skills to create with a modelling tool like 3ds max or maya.
By making everything a programming process us indie gamers can get a workable demo up and running with virtually no extra help until the project becomes an almost viable prospect.

Tooling like this is mind blowing and saves a lot of time

 

That's quite a wishlist ;-) Some of these are what I would call core features while most could be implemented as tools or examples built on top of the core system. In general we need to get the core features working first but we're also writing examples as we go (i.e. the procedural generation examples).

Grass and trees are not really specific to voxel terrain, and there are several scripts/model in the asset store. I don't think we want to get too involved in the rendering techniques for these (GPU grass, billboards for trees, etc) as this moves away from our main expertise, but I do think it would be useful to have an example of combining existing systems with Cubiquity. This applies to clouds/sky/weather as well, though in these cases the integration of external packages should be trivial as there is nothing voxel-specific about them.

I agree that the grass texture in Cubiquity is not so great, but I think the other ones are ok. I think the main visual problem is the lack of normal mapping (or even displacement mapping). We would definitely like to implement this in the future. You can of course use any texture pack you like, and in the future it should be easier to swap out the whole material which is used for rendering the terrain.

For the editor features I'm not sure how far we will go. All the ideas are interesting but it will have to be a balance between what should be done in the editor, what should be done in code, and what should be done in an external application. Raycasting/picking is a pretty core feature and you can already use it to select individual voxels, and being able to select whole volumes would be nice too. But you can probably also use unity's built-in picking for this if the volumes have a collision mesh.

Splitting/merging of volumes is something which would probably be done through code and maybe we could make an example for that. You could probably implement that yourself though as you have direct access to the voxel data.

The in-game tools are I think rather game-specific, so if you want different tools to affect the world in different ways then that is something you would need to implement yourself. However, you are a bit limited in the kind of shapes you can create due to the limited resolution of the terrain.

Water is a very interesting one - I don't really consider it part of a terrain system (e.g. Unity's built in terrain doesn't support it) but Minecraft has indeed introduced Cellular Automata based water. I don't find it very convincing though, and would probably rather make an example using an external asset such as Fluvio.

Cubiquity is quite focused on terrain rather than buildings/architecture, so a system like that isn't really appropriate. I can imagine it would be nice to have an interactive tool for combining noise functions when designing terrain (like this) but there's just no time for that at the moment.

Overall we do need to limit the system to creating and editing voxel terrains rather than turning it into a complete world creation package. But I would like to make an example using a bunch of cool assets from the asset store to show what can be achieved.

 

Aim high, that way if you fall a little short you still achieved something cool.

Really?
Terrain only ... But you can do so much more with all those voxels

 

Hey David,

When I create multiple volumes how do i move them about?
It sounds stupid i know but:
I took this code (see below) from the example code and it generates a child game object but moving the parent game object around in the editor doesn't move the voxel array around ...

Do I have to issue some sort of redraw call to get the array to move?

Also I noticed that unity is using a constant 20% of my CPU whilst using Cubiquity in a scene is this intended?

Other than this ...
Getting some promising results

 

I didn't mean to sound too negative there, I mean we'd definitely like to see many of these features. Examples showing grass, trees, water, building, etc would all be very cool and we hope to get to them in time. But actually they are all things which the user can implement themselves on top of our system (at least in theory...), and they will have a lot more flexibility by doing so.

Other aspects such API design, a LOD system, more platforms, documentation, etc can only be implemented by us, and so it makes sense to focus our efforts here. In practice the two things happen side-by-side as making the examples is actually more fun

 

Don't worry i think you're doing great so far and you're definitely right to focus on the things that are considered to be "core".
Who knows maybe at some point once you get the basic terrain side of things sorted you may well extend the library to do more ... If anything my wishlist was literally just an ideas list that you could play around with.

My suggestion though ...
Architecturally speaking, I would recommend that you don't have any core voxel management code only apply to terrain instead create terrain related objects and functions to handle that on top of the basic voxel functionality that way you can if you want extend in other directions later.
But what would I know, i'm no pro in this area (a web apps guy professionally)?

Procedural generation of an entire game is my goal not just the terrain so ...
Im going to have a go (if I ever get there) at some sort of L system code for things like tree, building or other similar object type generations anyway as that can depend on your game implementation to some extent ("artistic style" en all that) whilst you focus on terrain.
Something like bolted on to basic voxel library functions could be seriously powerful I think.

My thinking here is that the more i can procedurally generate the less I have to worry about modelling and asking players to download.
This is what makes me wonder if voxel data is actually best suited to being handled by the GPU rather than only the resulting mesh data (but that's a much bigger can of worms).

 

This functionality was not in the last snapshot, but it is what I am currently working on. As you noticed in the other thread it is already (mostly) working for the colored cubes volumes, and I'm now in the process of getting it to work on the smooth terrain volumes as well.

Actually this fits in with you comment about the architecture... there is much low-level functionality (including these transformations) which is common between the two volume types and which would also be common to any new volume types introduced in the future. The aim is indeed to factor this out and avoid any unnecessary duplication, so that when something works for one volume type it immediately works for the rest. I think we're on target for this soon.

I haven't looked to hard at performance yet (I've been happy that most things just seem to be fast enough) so it is quit possible that there are some inefficiencies here. In particular I think a lot of work is being done to synchronize the Unity representation of the volume with the internal C++ representation - i.e. checking when parts of the volume have changed (even when nothing has changed). I'll try and take a look at some point.

 

Ah ok ... i did wonder if i was missing something ...

So architecturally speaking would it not make sense to have a basic volume object that you then extend in ways like ...

coloured volume
textured volume
liquid volume (maybe)
custom volume (to allow a custom shader to be used with the volume)

Then a terrain volume would be an extension of a textured volume (at least thats how it works in my head).

This would then allow me (using my own code) to apply a custom shader to a textured volume to represent something like a cloud.

Also ...
Are the cubic volumes drastically different in code to the terrain volumes or is it just a matter of the extra marching cubes pass to get the smoothing?

My thinking was there you could make that pluggable too (not for anyone but you internally though) so you could have marching cubes based stuff, then define bits to handle surface nets, dual contouring, and even tesselation later on.
Obviously this depends very much on the architecture of your code (hense my previous suggestion) but if I was building a voxel engine this is how I would do it for maximum flex.
It's also a neat way to allow for what seemingly others are doing already, using this for much more than just terrain (@voxi for example has a great little project on the go).

I did start doing some of this with GPU based code so all the voxel data in the scene would only live in graphics ram but I couldn't figure out a nice way to have the GPU results just pass over to a render shader and have that give me the relevant surface (nesh) in unity.
I haven't given up on that completely but lack the time to spend writing such low level code.

Let me know when I can move my terrain volumes around this is holding me back at the moment, no huge rush though as i'm still experimenting with shaping for my terrain generation (as you know my terrain isn't quite the normso has some interesting programming oddities to look right).

 

If you are feeling brave you can try the latest version from Git, as I just committed preliminary support for transforming the terrain volumes. If you are not familier with Git then you can get the latest version as a zip file here:

• Cubiquity latest development version

There are several problems that I'm aware of (and probably some that I'm not) but I think it might suit your needs. You can set the volume transform in the inspector and probably also through code (though I didn't test it...), but be aware that the gizmos aren't working so you can't transform the terrain in the scene view. The blue 'brush marker' may be missing but you can still sculpt/paint the terrain.

I think the architecture will end up as a combination of inheritance-based and component-based design. We do have a base volume class from which the two current volume types are derived, but some things (like swapping materials) should be as easy as setting the material property of a 'VolumeRenderer' component. The two volume types actually store very different data internally, so there are some limitations here. We're also keeping Dual Contouring in mind though it will be a while before we implement it.

 

I'm not sure that it's working quite right.
Although it could be me ...

My understanding of unity is that "local position" is a position relative to the 0,0,0 point of of the parent "transform.position" but unless i have something confused here you are using it to absolutely position (in world space) the volume which should be the volumes transform.position.

I couldn't get my terrain volumes to go anywhere without setting a local position rather than a position value on the transform of the volume.

Here's what i'm seeing ...
http://ccoder.co.uk/files/CubiquityTest.zip

This zip just contains cubiquity and the new scene file and my 1 island script (both of those at root level in the assets folder).
It is allowing me to move them about though.

I'm still working on the shaping in the generation code but you get the idea right

Also if I was to update the position in the update function of my script how would I go about redrawing it in the correct position ... I wonder if maybe i'm getting a touch ahead of you here.

Also i'm getting this a lot in the log file (i don't know if that helps at all) ...

[11:13:02][error ]<>: Message: "Volume handle'10' exceeds the maximum permitted value of '7'"
[11:13:02][error ]<>: Volume handle'10' exceeds the maximum permitted value of '7'
[11:13:02][error ]<>: An exception has reached the C interface and been suppressed.
[11:13:02][error ]<>: Type: std::exception

 

Indeed, there are still a number of issues. Actually you've pushed it a bit harder than I did revealed some extra problems which I should keep in mind. In particular it seems like there are some problems with updating in edit mode, though it's probably working ok in play mode. But I wasn't really expecting it to work properly, just to work well enough to be more useful than the previous version you had

I didn't test making the terrains into children of other game objects. Obviously that should be made to work properly by for now it might not. I just placed them at the root.

You shouldn't have to do anything, all updating and synchronization is handled by the TerrainVolume's 'Update()' function. However, in edit mode this is not called all the time and so there is a hack (UpdateAllVolumes.cs) which drives the update. This is all temporary stuff, and there's possibly an issue there. I think the updates probably do work in play mode.

There's was a hard-coded limit of eight volumes. The new limit is 256, so you should download again to get the new .dll (same link as before). If you still find you hit it then you might have to restart unit occasionally. Sorry, but you're right on the bleeding edge here

I'm going to be away from my dev machine for a week or two for Christmas so I can't make any more changes. I'll try to check the forums though. If the multi-volume stuff is too unstable for you then just put it on the back-burner until I polish it in the coming weeks.