Cubiquity - A fast and powerful voxel plugin for Unity3D

Ok, as mentioned on Friday I've now disabled the LOD system in the 'develop' branch as it's not ready for the assets store yet. I'll put together the release and then re-enable it in a few days time. In the mean time, if you're using the develop branch and want the LOD system back you can reverse these changes:

• https://bitbucket.org/volumesoffun/...mits/19413660e4046b6d46fe007b2bc2ef97cb2cfcf5

 

Is this still the case? Textures are not supported for cubes? We have to use small cubes?

 

As far as I'm aware, textured cubes for cubic volumes is still not possible.

 

Indeed, as @SirStompsalot says the cubic voxels have just a single color. They are designed to let you replicate the retro-style art of games such as Voxatron, 3D Dot Heros, or Critical Annihilation. Newer engines such as VoxelQuest or Atomontage have voxels so small that you can't really see them anymore, and this is also a longer-term goal of Cubiquity.

 

Ok - I can understand that. Just wish that textures were an option so that the engine doesn't lock you into a particular art style. My artist was completely turned off that Cubiquity doesn't support textures on cubic voxels. Hopefully I can convince him with using small voxels, as I'm really impressed by Cubiquity's performance so far.

I do have a few questions about Cubiquity (cubic voxels only, not smoothed):

1. Is there a built-in way to store additional data about a voxel? For example, to store what type a particular block is. Seems like the way to go about this is by the voxel's color, but then if let's say a player wants to paint their block house the same color as lava, there would be no way to detect that the voxel is different from a lava voxel.
2. Any way to use a different shader for specific voxels? For example, to make a voxel glow?
3. Is there a recommended method for saving and loading prefabs on the terrain?

 

Indeed, adding support for cubic textures may be desirable and could happen in the future, but I think it's lower priority than things like better editing tools or mobile support. Basically I want to polish existing capabilities before adding new ones.

You can keep a separate data structure for this, which at the simplest level could just be an array. Memory can be a concern, but the largest volume we have shown is the 'City' map from a few posts back, and it is only 512x512x64 = 16 million voxels. So storing an extra byte per voxel would need 16Mb which isn't so bad on a desktop system.

You can look at a Cubiquity volume as the equivalent of a framebuffer in 2D graphics. You write color values into the framebuffer to be displayed as pixels in the screen, but you wouldn't use the framebuffer to store additional information about your sprites, etc.

That said, it would clearly be useful to uses if we did provide some extra data structures to save users from writing their own. Some kind 'BigArray' perhaps, which could page data to disk. Maybe this happens in the future.

You can change the shader for a volume but not per-voxel. I do intend to add an emissive component to the colors (which would let you do glow) and maybe a small amount of custom data which could be passed to the shader. It's not in place yet though.

I'm not sure what you mean by this. The scene saves a link to the terrain, and of course your scene can also contain other Unity objects such as prefabs for buildings, etc. So you can build a scene which contains a terrain and also buildings... maybe you can clarify the question?

 

Ok, I'll definitely experiment storing additional data in a array, thanks! Looking forward to this being a possibly built-in feature in the future.

I think this question has pretty much been answered in your response about storing additional data about voxels. An example case for this would be prefabs placed (or generated) on the terrain at runtime that are not Cubiquity volumes, and the ability to save the prefab's position etc. But if I use a separate data structure to store information about voxels, then I can use that structure to also save information about prefabs in the scene.

Now I have a bunch of experimenting to do! Thank you very much for answering my questions.

 

Hi guys, I'm happy to announce that the first game using the Cubiquity voxel engine has now landed on Steam! Spark Rising was previously using their own voxel engine but moved over to Cubiquity in the last few months. I believe their terrain is still home-grown, but Cubiquity is used for the buildings.

​

I'm really pleased to see this as it shows Cubiquity is usable for real games

 

Hi David,

Out of curiosity, what do you suggest for instantiating multiple objects that use the same volume database? Obviously I want it to be read only, but any action I take with one (for instance, painting or adding voxels) carries over to all instances. Cubiquity even scolded me for it.

Multiple use of volume data detected! Did you attempt to duplicate or clone an existing volume? Each volume data should only be used by a single volume - please see the Cubiquity for Unity3D user manual and API documentation for more information.
Both 'GameObject 11' and 'GameObject 10' reference the volume data called 'Assets/GameObject.asset'.

I have a couple ideas here. I want to see what you recommend first.

PS: Congrats on Spark Rising, that's most cool.

 

Minor detail - but I'm working off the develop branch on git and am seeing an error thrown every frame if I have a Volume Renderer component and haven't created or loaded Volume Data yet. Error goes away once the Volume Data has been set, but it still makes reading the console difficult. Here's the error:

 

First of all, make sure you've read the relevant docs here. As mentioned on that page, I'm still a little uncertain how multiple volumes should operate so I'm open to feedback if something doesn't make sense. But this was also one area where the integration between the Unity and Cubiquity became a little difficult because we had no way of intercepting things like Unity 'duplicate' events.

In your case I believe you want a single .VDB file containing the data for you object, and then a large number of VolumeData assets (one for each volume). This will be painful if working in the editor because you'll have to manually create the assets one at a time through the main menu, but I think in your case you'll be creating them at runtime so it should be ok?

Have a go at this and let me know if it doesn't work out (and get latest, I made a VolumeAsset related change a week or two ago).

Yep, that's annoying! I think you can fix it in Volume.cs by changing line 290:

Code (CSharp):

1. if (volumeRenderer.material != null)

to

Code (CSharp):

1. if (volumeRenderer.material != null && data != null && data.volumeHandle.HasValue)

I've logged the issue and will test/fix it properly in the coming days. I'm preparing the next release at the moment so I'm hesitant to to commit anything which isn't well tested

 

Let me chew on this. You've described exactly what I was running into - duplicating via the editor. I'll try carving out some runtime instances instead.

 

That fixes it, thanks!

 

Thanks!

Generally this is not recommended - see here: http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/page_duplication.html

You mean you'd like to copy and paste volume data? I agree it would be nice to have this feature. But I guess you mean you'd also like to do it from code, which I hadn't thought about before but it seems reasonable.

You can do this yourself of course by iterating over the voxels and copying them, but if I added it to the .dll it would probably be faster. I'll keep this in mind.

I think it should work like this already? Cubiquity doesn't do anything until the Update() function on Volume is called, and this happens once per frame. If you do some heavy work then I think Unity doesn't render another frame until you are done?

No, I'm sorry, I'm not currently planning to add this. I mean, it's a popular request so maybe it happens one day, but it's not on my todo list at the moment. Cubiquity isn't really aimed at a typical Minecraft game.

Honestly I haven't really considered networking as it's not my area of expertise. I'd expect users to implement some kind of synchronization appropriate to their game (as you describe). It may be that I can add some utility classes but I'd need more networking experience myself first.

No, but adding threading support is fairly high on my list of priorities. At least the mesh extraction should be moved to backgrounds threads, and it would be desirable to edit from other threads too.

Not at the moment, but in the future I intend to remove the concept of a volume having a fixed size. I think every volume should let you read or write to any position, and would create the necessary data behind the scenes.

Hmmm... I haven't really thought about this. Probably you should indeed use a transparent plane, but a Cubiquity raycast can't hit it (it only hits voxels). So you should also fire a Unity Raycast if the Cubiquity one doesn't hit anything? Seems like that should work.

 

Is there a way to determine which side of a cubed voxel has been clicked?

 

There are actually two versions of the raycasting function for coloured cubes volumes. These are 'PickFirstSolidVoxel()' and 'PickLastEmptyVoxel()'. If you want to know where to place a cube as part of a building operation then 'PickLastEmptyVoxel()' voxel is probably what you want, but if you really want to find the face then you could call both raycasting functions (with the same input) and you should receive two adjacent voxels. I think these two voxels will only differ in one coordinate, and that is your shared face.

I didn't test it but I think it works

 

Using both PickFirstSolidVoxel and PickLastEmptyVoxel does work, thanks!

 

When I suggested this I was imagining you would use some conditional logic to determine which of the three coordinates was different. But thinking about it further, you can compute a point on the face as the average of your two voxel positions, and compute the face normal as one voxel position minus the other. I'm not sure which approach is best for your situation but it's worth keeping in mind.

 

I'm not quite sure I'm following what you mean there.

My use case example is:
- I have a 2D array of colors
- When a voxel is clicked, the area surrounding the click on the XY plane is colored with the 2D array.
- Problem: This works great on the XY plane, but I want this to work for XZ and YZ planes too depending on what voxel face was clicked.
- Solution: Use PickFirstSolidVoxel and PickLastEmptyVoxel and subtract the difference between their worldSpacePos values. Can determine which plane to use from that difference value.

 

Yes, this is basically what I was saying. Initially I had a more complex approach in mind, and then I realised there was a simpler solution. But you are already using the simpler solution so all is well

 

Ok! Simple is good

 

Hi guys,

I'm pleased to announce that we've just uploaded a new version of Cubiquity for Unity3D to the asset store!

​

This release adds several performance and memory usage improvements, supports 64-bit architectures, and includes experimental heightmap import. Read our blog post for more details of what has changed and then check out the links below:

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

Do let us know if you have and problems, issues, or other feedback! There's more exciting stuff to come in the future, and as always you can stay up to date on our progress with the following links:

• Our blog
• Twitter
• Google+
• YouTube

 

Hi, aim very interested in your engine but I have a few questions since voxel is a new sector for me.

Is the terrain automatic randomly created? If so, how can I set objects in world since the map does change every time i open it?! What is the + of using a voxel engine?

 

This is up to you. It is possible to generate random terrain if you understand how to write noise functions, etc, but this isn't done for you. If you choose to randomly generate terrain like this then you can also make it deterministic, so that it will be the same every time.

The main advantage is that you can have structures like caves, overhangs, arches, etc which are not possible with heightmap terrain.

Remember, you can download it for free so give it a go!

 

Hi guys,

Just a heads up that, as an asset store publisher, I recently received access to the Unity 5 Release Candidate. I haven't installed it yet but will do so over the coming days, with the intention of getting Cubiquity working with Unity 5. Based on user feedback I expect the main challenge will be the shaders but I'll keep this thread updated with any progress.

I'm looking forward to seeing what Unity 5 brings to the table!

 

I'm not sure if I'm missing something but when I go to 'build and run' one of the example maps the volume doesn't render. It renders fine in the editor mode.

 

This is probably a result of the native code library not being found or failing to load in the stand alone build. Can you have a look in the log to see if it makes any mention of Cubiquity? Also what platform are you on, and what versions of Cubiquity and Unity are you using?

The native code libraries are stored in the streaming assets folder and should be copied to an appropriate place (probably next to the executable) the first time the stand alone build is run. Do you see a CubiquityC.dll/.dynlib? The copy may fail if you run the stand alone build from read-only media or from a folder where you don't have write permissions.

If the file does appear to copy but won't load then are you doing a 32 or 64 bit build? Both should work, but try the other. 64-bit builds will only work if you have a recent version of Cubiquity.

Let me know if any of the above helps.

 

After experimenting with Cubiquity so far, I'd say there are two features that are at the top of my wishlist:
- Multithreading
- Generate chunks closest to player (from this card on Trello)

 

@pxlweaver - Threading is one of the main things I expect to be working on in the native code library over the coming months. I assume you want it because you are encountering performance problems? I'd at least like to move the mesh extraction to background threads to free up the main thread for Unity.

 

I'm testing a method to load and unload volumes based on the player's position to lower the framerate and memory cost of having one large terrain - similar to what's described in this thread.

For me at least, having a single volume larger than 512x512x512 impacts performance too much. If I wanted an area larger than that, seems like loading and unloading volumes is the best option.

I have generated and saved volumes to disk outside my performance test (so no procedural generation at runtime). Inside the test, each vdb is simply loaded and applied when the player is within range.

The time and resources it takes to generate a volume's mesh is another issue when loading and unloading multiple volumes. Loading a couple 512x512x512 volumes kills framerate. I've found so far that 128x128x128 or smaller performs better, and making sure the throttle how many volumes are being loaded at the same time.

The next problem (although more of a minor one) is that volume meshes generate it's own chunks in a specific order every time. Which works great if the player is moving in the +X +Z direction, because that side of the mesh is generated first. However, if the player is moving in the -X -Z direction, it would take slightly longer for the full volume to appear in front of them. So my only option around this at the moment is to make sure the range that volumes are loaded in is fairly large.

 

I got it working with the 32 bit build. I'm on windows and pulled cubiquity from git.

Something else I noticed is 1 pixel white dots between some voxels. It seems like a precision thing, they change when the camera moves.

 

Ok, great, but 64-bit builds should also work if you have the latest version from Git. Can you confirm you have a 'StreamingAssets\Cubiquity\SDK\Windows\x86-64' folder present in your checkout?

Yep, this is basically caused by T-junctions in the mesh and is a classic problem in cubic-style voxel engines. I've been aware of the issue for a while but have now logged it in the issue tracker. I'm not sure how hard it is to fix - I can take a crack at in in the coming days in case it is easy, but if there are complications then it might have to wait until more stuff is in place.

Right, so basically you are building a paging system on top of Cubiquity to support larger volumes. The size of Cubiquity volumes are indeed relatively limited because the whole volume is always rendered. Long term I would like to see such paging implemented inside Cubiquity because it can be done more efficiently there, but until then you will indeed have to improvise with the approach you decribed.

There are a couple of things you can try to improve the performance:

1. Try turning off collision meshes. I realise you might want them, but it's worth finding out if they are a bottleneck. If so then threading won't help much (Unity can only build them on the main thread) but there may be other things that can be done here.
2. Try changing the 'maxSyncOperationsInPlayMode' and/or 'maxSyncOperationsInEditMode' variables. These control how much work Cubiquity does each frame - you might find that reducing them makes the volumes load slower but have less effect on framerate.

 

I only enable colliders on volumes within range of the player which does help a little. The biggest framerate impact is from having one large volume or a large amount of smaller volumes in the scene at once, especially if they're in the middle of syncing. I've also noticed that even having a gameobject with a Volume component that has no data assigned still impacts framerate, so for now I disable the component when it's not in range.

Ah! I didn't realize there was such a variable. Looks like those variables are protected. If I set the maxSync on the volumes that are out of range to zero, that does help quite a bit but I've only done a quick test with it so far.

Thanks for the tips

 

Indeed, these are not part of the public API so you'll have to actually change them in the Cubiquity code. Ideally they wouldn't be necessary as long term I'd like the most appropriate values to be automatically (adaptively?) adjusted in some way, but for now it might be useful for you to change them.

Setting the maxSync variables to zero will stop Unity syncing the meshes with Cubiquity, but I think that Cubiquity will still be doing some work internally. It might be that you should disable the VolumeComponent once they are more distant, but this might also stop them rendering (though it probably shouldn't). To be more explicit, it should be possible to separately control the updating (by enabling the VolumeComponent), the syncing (with the maxSync variables), and the rendering (by enabling the VolumeRenderer) but I haven't really tried unusual combinations of these so let me know if you hit problems.

You could also consider making use of different layers in the scene. You could create and build your Cubiquity volumes in a hidden layer, and then move them to a visible layer once they are built (use OnMeshSyncronized())). This will stop the user seeing which order the chunks are being built in.

 

When the Volume component is disabled but not the renderer, the mesh does indeed still render. However, when the component is enabled again, isMeshSyncronized becomes false and the mesh is rebuilt.

 

Ok, thanks, it would be better if the mesh didn't get rebuilt in this case. I'll see if I can improve something here once I have taken care of the Unity 5 update.

 

That'd be awesome, thanks!

 

Hi guys,

I'm making good progress on updating Cubiquity to work on Unity 5. I've fixed most of the issues and everything seems to work properly on Windows. However, I'm having a problem on OS X which is proving rather tricky, in that it seems there are no longer enough texture intepolators available to support eight textures on the smooth terrain. I guess Unity has reserved some extra ones for internal use.

The short term solution will probably be to limit the number of supported textures to four when using Unity 5. Or perhaps I can test the underlying capabilities and only apply the limit when necessary (as I said, it works on Windows) but I'm not exactly sure yet.

Apart from that it's working well, so if you're not using the smooth terrain on OS X then you can grab the latest version from the Git repo and start playing around with Unity 5. Let me know if you find any further problems which weren't present in Unity 4.

 

I was wondering if this plugin is viable for large hand built worlds(Cube style)? i need some help or some ideas lol. I cant find any editors that go above 1024^3 for voxel cube creation's and that converting them to .vdb even if you could create them would take forever.

And since i have very little skill in c++ or unity or any of this stuff really (im a web developer just doing a hobby project outside his comfort zone to expand my horizon's) im having a hell of a time creating anything.

I know i can use a noise library and get large procedurally generated world's with biomes but i want to actually have a defined world that i can add towns and events and sculpt for story (like skyrim or fallout).

Even though im saying ^3 on all my measurments the height would be no higher than 255.

So this is the way ive been trying to make my world.

1. First I make it in World Machine (large 10km^3) and save as Heightmap
2. Import Heightmap to Worldpainter (creates minecraft maps) than export as new minecraft map
3. Load Minecraft map in Mineways (converts part of minecraft map to obj). This is where it gets bad because converting something as large as 10k^3 to obj is just stupid so i do it in chunks of 126^3 (80 chunks)
4. Import OBJ into Magicavoxel and save as .vox and finally convert it to .vdb.

and once in unity add them all as seperate assets and place them next to eachother in the scene.
this would not be bad if the world was 504^ but its a lot and im not even sure the game could handle a world as large 5k^3

so here are a couple solutions i can think of but have no idea how to even begin implementing them.

1. Load the chunks dynamically as the player walks towards them, not sure how i would do this at all considering i need to use the in game editor to add mobs and scripts and that would all have to be dynamic as well..

2. Merge all the .vdb files into one large one and if the game has some way of handling loading the voxels as needed instead of all at once it could work, I of course have no idea how to merge .vdb's.

I created a .vdb that was 5000x2x5000 (attaching it to this post) and placed it in the scene and it appeared invisible on the top for whatever reason but the blocks appeared properly when clicked and exploded. not sure if thats a bug or its just not built to handle anything larger than 1024 on any axis.

If anyone has any ideas that can help me please speak up lol, ive been at this for about 200 hours now and still have no idea where to go with it. Yes im a unity/c++ noob but i cant think of any easier program to learn than unity lol.

 

At the moment the size of the worlds is relatively limited, and you will struggle to use more than 512^3 voxels in your worlds. Actually, the problem is not the size of the voxel data but the size of the mesh data which represents the surface. In the future this will hopefully be solved by only displaying the parts of the world which are near the player, but for now you are stuck with this limitation.

Ok, that's a rather convoluted process! Just to be clear, are you using this process just to get the data from WorldMachine into Cubiquity, or are you adding other things along the way? Because if you just want to import the height and color map then this can be done much more easily and directly with the ProcessVDB tool.

Take a look at the posts above from 'pxlweaver' as she is describing something similar. However, I wouldn't recommend you tackle this as you say you don't have much experience with C# and Unity. So if you want to work with Cubiquity then you will probably have to reduce the scope of your project until Cubiquity can handle it.

I think the only reason you have multiple .vdb files is as a result of your import pipeline - using the ProcessVDB tool should give you a single .vdb from the heightmap easily enough. So then this is the correct approach, and in the future Cubiquity will handle the loading of various parts of your map on demand (but again, it doesn't handle this yet).

I think it's a bug and I've logged it here. If the bug is fixed then I think this scene will load successfully because it is completely flat (so doesn't need many triangles) but it will become very slow when you add hills/noise/etc.

Good to hear of your enthusiasm anyway

 

@Nvenom - Since you're new to Unity and C#, I would recommend that you check out a visual scripting plugin such as Playmaker. It can be really helpful in training you to use small actions to achieve a (possibly) complex function. Later you can move onto examining the code of those actions, and then start writing your own custom actions. That's how I got started anyways

If you have an idea like loading in chunks as the player moves around, you need to break down the idea into smaller steps.
So something like this:

• Generate multiple volumes and display them in a grid
• Convert the player's position to volume coordinates
• With the volume coordinates, find the neighbor volumes of the current volume and load them
• Unload any other volume that's not a neighbor

Those could be broken down into even smaller steps, but that gives you the idea anyways. Good luck!

 

Hi guys, I have just submitted a new version of Cubiquity (ver1.2.1) to the asset store with support for Unity 5! Hopefully it gets approved in the next week or two, but you can also grab the non-commercial version now:

• Download Cubiquity for Unity3D ver1.2.1 (non-commercial)

However, as mentioned previously I have had to reduce the number of materials which can be used on a smooth terrain from eight to four. If you are only working with Unity 4 then you can re-enable all eight materials by searching for all lines containing the text 'EIGHT_MATERIALS' and following the instructions (note that this exists both in C# and shader code). I'll look at re-enabling support for eight materials by default in a future version.

 

Hi!
I just got the 1.2.1 non-commercial version to test it and I get the error "Assets/Cubiquity/Examples/CreatingVolumesFromCode/MazeFromImage/ColoredCubeMazeFromImage.cs(27,151): error CS1729: The type `Region' does not contain a constructor that takes `6' arguments". Why does this happen? If I remove it, it keeps moving onto the other examples.

 

That's very strange, I've never seen this. Which version of Unity are you using? Can you make sure you are importing into a completely fresh project to avoid any conflicts (though Cubiquity uses it's own namespace)? Can you have a look at Region.cs and verify it has the correct constructor as shown here: https://bitbucket.org/volumesoffun/...s/Cubiquity/Scripts/Region.cs?at=master#cl-16

 

Hi all,

Cubiquity version 1.2.1 has now been accepted on the asset store, and adds Unity 5 support. The link is below:

• Purchase Cubiquity for Unity3D on the Unity asset store

 

Hi David, I'm brand new on voxel concept then I have some questions.

If I do understand well I can use vdb files to store modelled voxel objects (even a full world) and load it into a scene, so can I load multiple vdb files that represents individual objects like house, car, tree and so on once onto a scene or I must only load a big file that contains entire scene objects?

Is it possible to use raycast, linecast and some other method to track voxel objects down? I mean the engine provides some methods to Interact with them?

Can I store some objects or part of them into a GameObject for apply some physical process?

Thanks for your time and sorry if these questions are very novice.

 

Both of these options are possible. In general it is better to use a single large volume, and this will become more true in the future. However, there is (currently) a limit to how big a volume can be, and many editors (Magica Voxel, Qubicle, etc) also have a size limit.

See also here: http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/page_duplication.html

Yes, have a look at the Picking class.

I'm not exactly sure what you mean here, can you elaborate with an example of what you would like to do? A volume object is already a GameObject which has some volume-related components attached (a VolumeRenderer, a VolumeCollider, etc). The design is quite similar to other objects in Unity, and allows volumes to participate in physics interactions.

 

Thanks for replying, I'll check all links provided.

I mean if it possible once the map/vdb is loaded I can determine which object would be. For example: the vdb contains trees, fences, rocks, house and so on, somehow they can be identified and be treated differently and none of them as the same thing (not only as a gross mass), then I could manipulate each object as well, scaling, duplicating, change their shapes, applying scripts, etc.

I say that because I think, for example, RTS games could be made using this engine if it is capable of to handle these things.

 

Right, I've got you, and again it depends how you structure your volumes. If you have a separate volume for each of your objects the you can use conventional Unity approaches such as setting tags or adding custom components to indicate behavior (but as mentioned, there are performance implications to having many volumes). If you have a single large volume then you can't do this, and Cubiquity does not (currently) provide a way to store extra per-voxel data. So you would need to keep a separate array (or other structure) which stores such properties.

 

Hi David, I have two quick questions:

Is it possible to paint vertex colors at runtime in Cubiquity?

Will Cubiquity ever support mobile platforms/how difficult would it be for me to make the changes necessary to run on Android?

Thanks for creating a great asset!