Cubiquity - A fast and powerful voxel plugin for Unity3D

Are you talking about the smooth (rather than cubic) type volumes? And do you really want to paint colors directly (instead of having textures), or do you just mean the ability to control the texture blending via vertex colors? The smooth terrain always has textures applied (unless you create a custom shader...), and you can paint these textures at runtime (which internally is done via vertex colors).

You can see the terrain painting in action here:

We will add mobile support eventually but there is no timescale at the moment. Unfortunately we need to add it ourselves, it's not something which users can do.

 

Thanks David! I did mean painting vertex colors directly and not using textures at all, and doing so on the smooth (not cubic) volumes, so that each triangle could have a different color, for a kind of low-poly aesthetic. Is this possible? I guess it depends whether the painting of the vertex colors internally at runtime happens on the c# or the c++ (PolyVox) side?

 

You can try applying the 'MaterialSetDebug' matrial to your terrain as this draws each material as red, green, or blue, and you can mix materials together. This could perhaps be a starting point for your system . However, there is a restriction in that in Cubiquity material weights must always sum to 1.0 (because they are intended for blending textures). So using this approach you can't represent dark colors.

You might be able to work around this by using the fourth material channel to represent the intensity of the color, but this is untested. You'll need to be creative and do some hacking on the shader to get the effect you are after, but I can try to guide you if you want to take this approach.

 

Hi guys,

As I'm sure you've all heard, the free edition of Unity 5 includes all of the engine features which were previously pro-only. With this in mind, are there any paying customers who plan to stick to Unity 4 for the foreseeable future? Or is everyone upgrading already? I need to decide what the minimum version of Unity should be as we go forward.

Any thoughts? Thanks!

 

Mobile support would be great, the multi platform support is one of the main features that separates unity from other engines.

Furthermore this would enable Cubiquity to be used for mobile VR as google updated the cardboard sdk for unity recently. It's very easy now to get a unity project running on VR and with google cardboard kits available for 2€ on eBay even cheap 'hardware' for development is easy affordable.

 

@Bitstream - I do agree, and we'll get there eventually. I'm putting a lot of emphasis on performance and memory usage at the moment which will also benefit mobile in the long term.

 

If you want to set the dimensions of a volume (in terms of voxels) then you can do this through the dialog which pops up when creating empty volume data, or if you are creating the volume data from code then you can do it through the first parameter to CreateEmptyVolumeData().

If you want to apply scaling to the volume (so the number of voxels is the same but they have a different size) then you can just apply a transform to the volume's GameObject.

 

I'm comparing Cubiquity to a few voxel libraries written in c# - how significant are the performance advantages of c++ (Cubiquity) vs. c#?

 

I don't have a clear answer to this question, mostly because I haven't tried any of the other voxel engines for Unity3D (though I do follow their development of course). I believe that C++ can be significantly faster than C# in applications which are computationally expensive or require careful memory management (voxel engines would fall into this category), but there are many other aspects than language choice which affect overall performance. For example, Cubiquity (currently) runs on a single thread, which may cancel out some of the performance benefits of C++.

You also need to consider what kind of performance you want. For example, I do believe that Cubiquity offers very fast voxel access and surface reconstruction, meaning that it was well suited for tasks such as real-time fluid simulation or terrain sculpting. I know the author of that work found it very difficult to update other voxel engines fast enough. On the other hand, Cubiquity is (currently) focused on finite size terrain and always loads the whole terrain into memory, so if you want infinite terrains then another system might be more appropriate. This isn't really about C++ vs C# though, just different goals.

Overall, I think you need to choose your engine based on the features you need rather than the performance, because the available options are all quite different (this is why we make a free version available). If you want infinite terrains then Cubiquity isn't appropriate, whereas if you want in-editor editing, direct access to the volume data, the ability to apply transforms to terrains, or colored-cubes style volumes then Cubiquity might be the best (or only?) choice.

 

Ok, I've taken a look at this and unfortunately it's not a quick fix. The mesh representation is currently maintained by the Volume (or one of it's subclasses) which is why the synchronization gets reset when you toggle that component. It would probably make more sense if the mesh representation and synchronization callback were part the renderer and collider, because this way they could each maintain their own representation (e.g. the collision mesh could be at a lower resolution than the rendered mesh) and could be synchronized separately from whether the Volume is enabled.

This means the issue should be fixed by some on-going internal restructuring of the code, but I'm not quite sure when it will happen.

 

Is your kit compatible with the Flash plugin? http://docs.unity3d.com/460/Documentation/Manual/flash-whatssupported.html

 

Cubiquity makes use of a native code (C/C++) library and so unfortunately it does not work with Flash/Webplayer. Currently only desktop platforms (Windows/Linux/OS X) are supported.

 

Agreed - moving the mesh sync (and maxSync for that matter) out of Volume does make sense. This is now #1 on my Cubiquity wishlist

Would an easier solution for now be something that disables unnecessary functions in Volume while maxSync is 0?

 

Perhaps you can indeed do something like this. The maxSync property is not part of the public API so I never really considered that it would be zero, but potentially you add an early-out at the start of 'SynchronizeOctree()'. I'm not in a position to test it at the moment though.

In other news, I'm currently working on some optimizations in the PolyVox library which powers Cubiquity. I'm trying to speed up both voxel access and meshing speed, and these changes should propergate up to Cubiquity for Unity3D in the coming weeks.

 

Ok thanks - I'll check out SynchronizeOctree and let you know how that goes.

Ooooo that'll be exciting!

 

David - I just downloaded Cubiquity again after a long break from game development. I'm really impressed with how far this plugin has come! The view distance and performance are fantastic.

Is there any chance that the voxel fake ao or the more complex Minecraft smooth lighting systems will be implemented? I've tried using Unity's SSAO shaders and they don't work very well with smooth colored voxels.

I've implemented a Minecraft smooth lighting system before in polyvox and found that it greatly enhances the visual experience. Each voxel would require an extra byte of storage for the light levels, and the lighting information would have to be computed per vertex along with some interpolation in the fragment shader.

EDIT: I'm not sure how the lighting would interact with the LOD system either

 

Thanks! I assume you are this user from the PolyVox forums? You did some great lighting work in PolyVox.

Lighting is of course important for creating a realistic image and Cubiquity is currently rather limited in this regard. However, I certainly do intend to add the type of small-scale AO you describe, as well as possibly some larger scale AO for both the smooth terrains and colored cubes volumes.

But I actually have a different implementation in mind for the small-scale AO. Each voxel in Cubiquity is essentially rendered as a cube, meaning that each vertex is surrounded by up to eight cubes (though of course we don't actually generate the surface when all eight are solid). What I would like to try is to encode the state of each of the surrounding eight voxels/cubes in a single byte (eight bits), and pass this information as part of the vertex.

This means that each vertex would basically have some neighbourhood information encoded within it. The vertex shader could then count the number of set bits to determine the amount of small-scale AO. This is possibly slower than computing the AO on the CPU, but the advantage is that the neighbourhood information could be used for other purposes as well, for example it could be used to calculate per-vertex normals on the GPU. Maybe there are other uses for such information, I'm not sure.

Anyway, this is completely untested but seems like an interesting way to pack both AO and normals into just a single byte Probably a lot more research and experimentation is needed but I'd like to investigate it in the future.

 

But atm there is no ETA for mobile support?

I have seen a video on your website of the polyvox engine running on android and i thought cubiquity is based on polyvox?

 

That's correct, there is no ETA at the moment.

Yes, this is true. Cubiquity is built on PolyVox and we have had PolyVox running on mobile in the past. For this reason I'm fairly optimistic that it can be done. However, it means more platforms to build for each release, more testing and support, and extra hardware. We'll probably also need more mobile-friendly shaders as they are unnecessarily heavy at the moment.

None of these are deal-breakers but together they add up to some extra work, so we need to be careful about what we take on and when.

 

Do you think your voxels would cooperate well with this asset? As in convert to the faceted style http://forum.unity3d.com/threads/polyworld-for-unity.239365/

 

Can cubiquity voxels be something other than cubes. Like how minecraft blocks can be staircases or levers and so forth.

 

Yes, I think it should work fine. A Cubiquity volume is just like any other Unity GameObject in many regards, so you should be able to just drop it into the scene and then position it as you wish. The only concern which springs to mind is whether it affects selection in the editor in some way (I recall there are issues here). At runtime I think it will be fine.

Nope, only cubes I'm afraid. Of course you can use normal Unity meshes in your scene to represent some other objects.

 

I absolutely love this! Its sooo fun to play around with for an artist, a must have!! Thank you very much for such a polished and fun product!

 

Wow, thanks, comments like this really inspire me to keep working on Cubiquity! It's great to know the hard work is appreciated

 

Hey guys, it's been a bit quiet around here for a few weeks but don't worry, we're not slacking off ;-) Work has been focused on the PolyVox library which underpins Cubiquity and you can see we've been making a continuous stream of commits here. We tend to operate in waves - a few weeks on PolyVox, then a few weeks on the core Cubiquity library, and then a few weeks on the Unity3D integration layer.

We've just written a blog post about the work we've done switching PolyVox to use Morton ordering. It's pretty low-level so might not be of interest to end users, but should be interesting to anyone with experience making their own voxel engine:

• Implementing Morton ordering for chunked voxel data

Also, just a reminder that when we come back to the Unity3D work we plan do drop support for Unity 4, given that Unity 5 is free for most purposes and makes working with plugins a lot easier. We're also keen to try out some of the new lighting

 

Update - Cubiquity for Unity is now free!

Hi guys,

I've got some exciting news today - after some careful thought we've decided to release Cubiquity for Unity for free The full details are in our blog post.

• Blog post: Cubiquity for Unity is now free!

This is with immediate effect, and is already reflected on our asset store page. Support will continue to be provided though this forum thread so please ask if you have any questions, and development will still be ongoing.

Hopefully this encourages more people to play with Cubiquity for Unity in the future so we look forward to seeing what you come up with!

 

Hi there! I have one question about your asset.

Is there a way to change the Colored Cubes texture? I tried to change the material in the resources but that didn't do anything.

 

Yes, you can change the diffuse texture and normal map. From the example volume:

1. Select the volume in the hierarchy
2. Find the Colored Cubes Volume Renderer component in the inspector
3. Double-click the material (should read 'ColoredCubes(Clone)')
4. You should now see the material in the inspector, and can change the textures.

I hope this matches the normal Unity workflow... if you think something should be done differently then let me know!

Note that you cannot do Minecraft style terrain - the cubes are always a single color. But the approach above let's you add detail via diffuse and normal maps.

 

Hi Guys,

Just a quick note - those of you who are using Cubiquity from the Git repository may have noticed that the LICENSE.txt has not been updated yet (it still shows the old non-commercial license and may give warnings). I will try to get this updated over the weekend so there is some consistency with the asset store.

Also, once you have some experience working with Cubiquity and feel qualified to talk about it, please post a rating and/or review on the asset store so that other users know what to expect

Thanks!

 

Ok, I've now applied the licensing changes to the Git repository as well. I made the smallest set of changes I could because you're not really supposed to work directly on the master branch according to the Git Flow development model, but I didn't want to go through a release cycle (or change the version number) just to change the licensing. So the licensing code is now disabled but for the next release I'll strip it out completely.

The LICENSE.txt just redirects the reader to the standard asset store terms which are available here. I'd quite like to make the asset open source, but I need to restructure it a bit before I do that (e.g. the compiled binaries should not be bundled in the Git repo, as an open source license would not apply to them). This is again something which can happen for the next release.

 

Hello there, I would just like to say Thank You! I have been silently working with your asset using the evaluation model. I was in shock and awe to see you have posted this very worthy engine for free and again for that I have logged on just to post a solid Thank you ( its well deserved) and keep up the great work!

 

Wow, thanks a lot! Comments like this are really inspirational and help keep me motivated to work on the project. Do share some screenshots when you have something you can show - it's always great to see what people are working on!

In other news, the next few weeks are going to be really busy so apologies in advance if I'm slow to respond to any posts here. I'm moving from Holland to the UK to start a new job and will be without my main development machine for at least a couple of weeks. I'll try to check in when I can though.

 

Yeah !!!!

 

Hi! I just gotta ask. How well is this optimized? I noticed that when I imported a medium sized map from MagicaVoxel, my FPS got stuck at around 45 and my computer started to struggle a bit. When I removed it, it worked fine with 100+ in FPS.

 

Could you add support for textured cubes environment (like in Minecraft)?

 

This is a bit of an open ended question, as I have put some work into optimizing it but there is always more which can (and will) be done. The only reasonable metric is whether it is sufficient for your project. Personally I think the performance is pretty good for most purposes, and our tank demo shows a lot of real-time destruction happening on a 512x512x64 map (which is probably the largest you can practically use).

That said, there's a few obvious performance bottlenecks:

• MeshColliders are slow, and should probably be replaced BoxColliders
• The whole system is single-threaded. Visibility calculation and mesh generation should be moved to a separate thread from rendering.
• Everything is rendered. There is no unloading of distant chunks, etc.

There's a few others I'm aware of but the system is constantly improving, and so far every release has been faster than the previous one.

I'm afraid there are no plans for this, as I'd rather spend the time polishing and optimizing the existing voxel types. You might want to look at this system instead.

 

hi first off thanks so much for making this amazing engine open source , it trully is exactly what i need for my game ive been working on , i do have a few problems though , not really from your end just mostly my lack of knowledge as far as voxel terrains go , first is there anyway i can enable lod(level of detail) cause i saw in your code that it was commented out , so i un commented it and it still doesnt seem to be working as expected maybe it is and the lod works so well i cant see it , otherwise would you know how i can enable it , also the amount of vertices and triangles is really high is there anyway i could change the voxel density in editor , after ive created the terrain . thats all i have for now once again thanks so much truly a great voxel engine , i specifically like the fact i dont have to generate it at runtime as thats usually quite slow on other voxel engines , and this one gives me more control .

 

Hi, sorry for the slow reply, as mentioned above I'm moving house this month and don't have access to my main PC.

There is indeed experimental LOD support but it is disabled in the released version of the code because it isn't yet working well enough. I think it is enabled in the version of the code in BitBucket but I'm not in a position to check this properly until I get my PC back.

Assuming that the feature is enabled, you should see some option in the TerrainVolumeRenderer (in the inspector) to adjust the minimum and maximum LOD levels. Or maybe it affects the distance at which they are activated... to be honest I can't quite remember. Sorry I can't look into this properly at the moment!

You can scale the terrain in the same way as any other Unity object (set the scale through the inspector). So if you want a large, low resolution terrain then you can create a small, high resolution terrain instead and then scale it up.

 

i see thanks for the reply , ill try get the bitbucket version , im not to worried about how well it works even if theres a few seams its fine , just need the lod for testing as currently a terrain of 2048 by 2048 is a bit performance heavy , with lod it should be fine , ok that makes sense , dont know how i missed that , anyway thanks so much.

 

I seem to be having a problem, which sadly I didn't try until now. I can't seem to get the voxel terrain to build, well when I build my game. It just vanishes and everything in my level falls as if there is nothing there. I thought hmm maybe load time, the mobs/items are getting updated before the terrain, but nope it just doesn't load. Anyone have any ideas?

 

This is most likely because the native code library is failing to load for some reason. What platform are you running the editor on and what platform are you building for? Does it work if you build for a different platform? Are you using Unity 4 or 5? Does the native code library get copied next to the executable (it should on Windows, and I think also on others)? Is there any mention of Cubiquity in the log file? Does it work correctly with the sample projects which come with Cubiquity?

That's a lot of questions, but hopefully we can shed some light on what is going wrong.

 

Hola -

I'm knee-deep in developing a authoritatively networked version of Cubiquity but coming to a few hiccups so I'm reaching out to the wider audience here to see if anyone has any bits of advice.

I've gotten as far as being able to spawn a volume over the network between the server and the clients; however, I'm coming to realization one big challenge.

- Players joining later spawn their own copy of the volume, not the server's version, causing synchronization issues. I believe I can send the server's version of the voxeldata to the client upon joining (through a JSON string), but I'm not sure what to serialize? Can I extract the volume data to a byte array? How do I get a volume to some kind of primitive data type that I can then reconstruct or edit on the client side when they join?

Thanks DavidWilliams, really appreciate your product.

 

I must admit that I have no experience with networking so if anyone has had some success combining it with Cubiquity then I would like to hear about it too.

Can you elaborate on how you are obtaining your volume data? Specifically, is it generated procedurally (in which case you would usually distribute the seed) or created by an artist? If it is created by the artist (a built-in map) then the player would usually have it already on their system simply by virtue of owning the game? If it is player created content then perhaps the client should just download the .vdb file before joining the game? The .vdb file is basically the serialized version of the data, though it exists separately from any C#/.Net/Unity concepts of serialization.

 

Hi David, thanks for the reply.

I'm obtaining my volume data in an artist-made vdb file created from MagicaVoxel. In essence, I'm not creating a terrain, but rather spawning a voxel "House" that can be edited anyone inside it. I'm treating each House as a separate voxel volume.

If it is player created content then perhaps the client should just download the .vdb file before joining the game?

In my case, I think it would be better to transmit the data to the player at the point where they are getting close to a "House" instead of when they connect. The reason is my environment is very large and I know for a fact the player wouldn't see every House, let alone want to know about all the edits that happen to them after they join. (for network bandwidth reasons)

The .vdb file is basically the serialized version of the data, though it exists separately from any C#/.Net/Unity concepts of serialization.

This is more the path I'm looking to pursue. How would one access this serialized data? I'm believe I'm faced with two options, stream the data to the player gradually or have them download the vdb file when they get close and create their own volume from that.

I'd be happy to share whatever I come up with encase there's other who are also interested.

 

@bigd Good luck on that, sounds like an amazing concept. Maybe there'd be a way to convert the data from the volume data into bytes and stream it over. I had to convert an entire exe that way once to extract a program from a program. Can't wait to see how it improves, I'm hugely interested as I'd love to make my WIP coop with cube volumes from this system.

My Q for David, is there a "proper" workflow between Qubicle (in my case Qubicle2) and Cubiquity? I've seen it mentioned a couple of times, but my question is slightly more complicated. I want terrain to be purely a volume, but I'll then need to place objects I've made in QC into the world. Is it suggested I keep them as an mesh format rather than convert it to some type of volume for performance reasons?
Also, when placing them in runtime is the Picking Class the best route for where they should go? As there will be a bit of randomization in placement. (My levels are a combination of hand made and rng content.)

 

You can usually find (or place) .vdb files in the '...\Assets\StreamingAssets\Cubiquity\VoxelDatabases' Folder. The reason they are placed here is that are not true Unity assets but just binary data. Anything placed inside the 'StreamingAssets' folder gets automatically shipped with the game. You then also need an instance of 'ColoredCubesVolumedata' (which is a true unity asset) and which points at the .vdb file.

See also:

• http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/page_key_components.html
• http://www.cubiquity.net/cubiquity-for-unity3d/1.2/docs/class_cubiquity_1_1_volume_data.html
• http://www.cubiquity.net/cubiquity-..._cubiquity_1_1_colored_cubes_volume_data.html

Note that you might not actually be able to write into the StreamingAssets folder at run time because on some systems it might be read only. I think that in principle you can place the .vdb anywhere as long as you provide the path to the ColoredCubesVolumeData. In practice there is probably C# code to validate this path and you may need to remove this validation to get this working. This is just because you are operating slightly outside the expected use case.

I hope all the above is correct - I don't have my dev machine for a couple of weeks so I can't check carefully.

You have direct access to the volume data via GetPixel() and SetPixel() so in general you can do this, but then you have to handle compression etc yourself. It's not wrong though, and can be considered as an option.

No, unfortunately not. To be honest, now that Cubiquity is free I'm more inclined to support other free or open source tools such as Magica Voxel and VoxelShop. However, Quibcle is very popular so perhaps I still get around to it.

In the meantime, you can implement it yourself if you know how to read the Quibicle format in C#. As mentioned, you can use SetPixel() to write the values into the volume. Also, I believe you can read Quibicle files from MagicaVoxel so perhaps there is a pipeline there?

Yes, in general it is better to make objects regular meshes unless you need then to be volumes (e.g. to edit in real time).

This is really quite application dependent. But I think in general I would choose a 2D location at random, iterate over the voxels in the given column to find the top one (the height of the ground) and then check surrounding voxels to see if it is flat. But really, it depends on exactly what you are trying to do.

 

Thank you for the helpful questions. I however have still not been able to pinpoint the problem.I'm on windows 8 x64. Using Unity 5 and also building for Windows, I also did the Web Player and Android all with the same results. I checked cubiquity.dll is there, the log states it has created the volume. I'm a little lost

 

First I totally understand your perspective on supporting different software, I'm a big fan of VoxelShop and honestly considering switching to it for more applications.

What I meant about streaming the data from the volume isn't the GetVoxel info, but to take the file itself that holds the information and using a filestream compress and send the data. Slightly older approach, but with things like .net's async and threading might not be a bad concept. (Not a networking person so no idea how to do -that- part though.)

As for the picking of voxels, since I'm using all colored cubes, I was trying to figure out the right method to using the Picking class; as do I using a normal linecast from an X/Z position down and find the first hit and gather the cube from that V3, or do I only use the picking class and V3i to locate it? (Btw V3i is a handy system )

I'll experiment with it, but I wasn't sure if a position is at a corner, or a center-center...so when I locate a cube am I pointing at the middle of it? (So I'd have to get the V3 + 0.5f in height.) Thanks for all the answers, love the system, totally switched over to it for the prototyping and might be keeping it for the entire design.

 

Thanks for the tips David and all, this has been very helpful.

I feel I'm "close" and I plan to spend some time over the weekend diving into it a bit deeper.

My experience with sqlite (or any database for that matter) is quite limited, but after doing some stackoverflow searches and peering into the voxel database a little more, I believe I can simply convert the voxel BLOB database into a byte array using something like: byte[] binDate =(byte[])row["Date"];
And from there, send it to the client, where they can reconvert the byte array to a voxel database to be assigned to the volume. At that point, it's just a matter of keeping the two volumes (client and server) in sync via events.

Seems like it'll work in theory, but I'm sure there's going to be something that mixes this plan up. It really all depends on whether this transmission between server and client is fast enough to make this even fit my project's requirement. We'll see! I welcome any additional thoughts.

 

@DavidWilliams Will you ever implement a way to lock to a plane for editing? Such as only x,y,z etc? I find the edit speed it really fast and I have to go back over and over when making a whole for example.