Hi

Love the tool.

Any chance of have the ability to toggle the terrain volume collider to be convex? I want to make the carved out rock shapes able to fall and interact like a rigid body, but when I attach a rigid body it (correctly) informs me that unity 5 doesn't work with non-convex colliders attached to rigid bodies.

I can accept the loss in precision using a convex approximation, but I have no way of toggling this on like you do for a normal mesh collider. Can you help provide this functionality?

Its kind of important for my game, so any help would be much appreciated.

Thanks

Stephen

Hi, I have heard about this issue in Unity 5 and have logged a few notes here:

https://bitbucket.org/volumesoffun/cubi ... s-with-non

However, I haven't investigated the issue an further. Can you give any further insights as to what exactly the problems/limitations in Unity 5 are, given that the 'TerrainExampleScene' seems to have functioning physics? Is the problem:

• Non-convex colliders are not supported at all in Unity 5?
• Non-convex colliders cannot collide with other non-convex colliders?
• Non-convex colliders cannot have rigid bodies attached?
• Something else along these lines?

You specifically mentioned having a rigid body attached, but of course the terrain should not be a rigid body. I think it should be marked as 'kinematic' (not sure if that is the Unity term...) which means it is involved in rigid-body interactions but will never move.

For the TerrainVolume it will quite difficult to approximate it with convex colliders, though for the ColoredCubesVolume it should be easy(ish) to approximate it with boxes.

Hi David

Thanks for your link to you bit bucket page - there were some interesting things here.

The problem is that I am trying to make terrain carvable (which isn't a word, but I don't know a better one). I.e., you can take a block of terrain, and carve out a chunk of it and it will fall to the ground. I can handle the maths of checking for connectedness, but what I can't do is make the resulting chunks use a convex collider. At the moment the removed chunks just have a crude box collider attached.

Here is a simple video of my first attempt at this - https://youtu.be/kPbrl0Nl_ec

In some sense, this is the functionality from your example "ColoredCubesExampleScene", where when you click on the terrain it breaks off the cubes as little boxes with rigid bodies attached. However I am instead breaking off potentially large (up to about 20 x 20 x 20 metre) blocks of voxel terrain. When they are carved off a rigid body needs to be attached so they can fall convincingly, but to do this I need to able to make the mesh collider (or volume collider equivalent) convex.

Within the terrain volume collider, I assume you just use the same mesh that is generated for the renderer in a mesh collider, or is it done some over way?

To answer your question from your post, the issue is that unity 5 can't have non-kinematic rigid bodies with non-convex colliders. The collider must be made convex, or the rigid body must be kinematic.

I appreciate what I am trying to do is a) unusual and b) probably beyond what you had in mind when you designed Cubiquity. But I feel like its 90% there already, and if we can just make it work then it opens some new and very exciting game dynamics. I don't think any of the competing voxel engines in Unity support this functionality, but its something that is needed to have in-game deformable terrain look realistic (i.e. no floating blocks).

If you can help me with the colliders, then I'm more than happy to share my connectedness script with you that you can then integrate into your product (once I've optimised it properly).

Sorry for the long post.

Stephen

Very cool stuff!



Yes. In the future I would like to use a lower LOD mesh for physics but so now it uses the same one as for rendering.



Ok, well the terrain is generally non-convex but should be kinematic (you may want to check this). Trying to approximate the terrain with convex colliders will be difficult and probably not the right approach. What about the piece which you split off? I assume that is a normal Unity mesh, or are you creating a new smaller terrain volume? A normal mesh would be preferable, unless you need users to be able to further edit the split-off piece (this will get complex!).

For the split-off piece I think you have two main options for the collider.

1) Apply some for of convex decomposition to create a number of convex meshes from the non-convex one. I'm sure there are known algorithms for this and I expect they are complicated :-)

2) For each voxel in the split-off piece generate a sphere collider, and hold them together with rod /stick constraints (I assume Unity has something like this) to fix the shape. You only need a sphere for the voxels lying on the surface, so your 20x20x20 example would have a lot less than 8000 sphere colliders. Actually the colored cubes example also only generates cubes for voxels on the surface of the destroyed terrain. I don't know how practical this is, or how many sphere colliders you will need, but I feel it would be easier than convex decomposition and is where I would start.

Either way, you now have non-convex but kinematic terrain, with a non-kinematic but convex split-off piece. This is enough for Unity?



It's certainly been on my mind, but generally I think it is outside the scope of Cubiquity once you have separated the piece off from the terrain. From then on it is your problem :-) That said, if the split-off piece was made into a second volume then this would need to be handled inside Cubiquity, but it's pretty complicated I think. Would be cool to have something like this:

https://www.youtube.com/watch?v=nCpTgfVmhcc

Of course, when working with cubic voxels we can approximate it with large box colliders (probably what this video does?), but smooth terrain is more complex.

Anyway, I hope that gives you some food for thought...

It is completely possible to tag Polyvox Mesh as convex, even runtime, like in the screenshot below.

However, your splitted pieces then cannot be concave. They have to be convex. This is the easiest solution.

If you really need these to be "concave" for the puspose of Gameplay, welcome to the world of Convex Decomposition!

The easiest solution is to use Bullet's ConvexDecomposition example. You can write C++ native DLL, and a protocol to pass your meshes to it and take your meshes back from it using P/INVOKE.

You can also find other Convex Decomposition examples, there are even unity plugins for this purpose but paid.

Links to some C++ implementations
http://kmamou.blogspot.ca/2014/11/v-hac ... -here.html
--> https://code.google.com/p/v-hacd/ License: BSD!

https://code.google.com/p/bullet/source ... onDemo.cpp

https://github.com/petersvp/convexdecomposition [Note: This is sitting around into my GitHub but actually never tried it ]

And sorry to tell but Crafterria will have similar feature, so you aren't the first with this feature
Just I did my research but I may end up without it if it bugs the gameplay way too much at the end.

Anyway, feel free to try out all these. HACD seems to be quite good, I tested it in Qt/OpenGL, but it should be trivial to write Unity Native Plugin with it. Also, BSD and MIT licenses are very good for commercial purposes already

@DAVID
2) For each voxel in the split-off piece generate a sphere collider, and hold them together with rod /stick constraints (I assume Unity has something like this)

You only need: Root object with the mesh and RigidBody, And multiple colliders in this same object for each sphere. This way, colliders will be stable, More stable, because they will be strongly fixed, and joints are NOT needed at all!

Well I've finished optimising my script, updated video here: https://youtu.be/18h-Oz7krxg

It now does the connectedness checks and breaks off chunks in about 0.015 seconds, which is fast enough for me.

The broken off chunk is a cubiquity terrain volume. So I can break it further if I want to. It has a rigid body attached, but its volume collider is turned of and instead a crude box collider is used. Your video you referenced (thanks) is basically what I'm trying to work towards.

If you are just using a mesh collider then it should be quite easy in code to set it to be convex. Something like:



However I don't have access to your mesh collider, so I don't think I can do this. Some extra interface needs exposing - either providing my access to the mesh collider or else just a function which I can call which toggles the "convexity" on and off. Can you help with this?

In answer to Peters post, I'm happy just using convex collider. Its not perfect by any means, but to be honest I think its good enough for my purposes. And plus I don't think I can do this as I don't think I can get at the meshes within cubiquity. If my game makes some serious money I can come back to this at some later point, but for now I need to focus on want I need. Its all a balance between time and quality

I didn't know about Crafterria - I'll have to look into that one.

Well, in fact, I never tried Cubiquity, so I don't know how exactly it generates its primitives, but since it's an runtime unity primitive, I am sure that you already have access to the mesh somehow. Did you tried pause in Play mode and debug the scene object tree?

If you find an MeshRenderer somewhere, there should also be MeshCollider somewhere, that you can reference with GameObject.Find... Maybe I have to check, but it should ebe hwer somewhere. Then you steal the mesh from it, assign it to your rigid body and set convex to true.

Ah, yes, this is a better solution.



Right, sorry, I understand. I thought you wanted to really create a convex mesh, but actually you just want to tell Unity you already have one and assume it will be good for most purposes.

To do this, you should add an appropriate flag to the TerrainVolumeCollider and then modify the internals of Cubiquity to synchronize the VolumeCollider flag with the generated MeshCollider. We do something similar with the cast/receive shadows properties of the VolumeRenderer (which are synced to the MeshRenderer) and also the 'Use in edit mode' flag of the VolumeCollider (though this is a little different, as it controls whether the MeshCollider gets generated rather than syncing it's properties).

I hope that is a starting point, but I can help you more if that is not clear.

Got it working, video here shows the much more realistic result.

https://youtu.be/Gl4unqBmJUw

Chunks now can be carved by hand and look and fall realistically (and its slightly quicker). However the shader needs fixing, because it doesn't work well for moving blocks. I'll look into this.

Thanks for your help David.

For those who want to know, the edits to the cubiquity scripts were very minor, detailed below.

Edited the OctreeNode.cs script in the following way:



And edited VolumeCollider.cs to include a public bool named "convex", which by default is set to false. Then in my script I just set the convex to true for the broken chunk. Works like a charm

Very cool stuff! I'll look forward to seeing how it develops.



It looks like it's applying the texture in world-space rather than volume space, though I don't know why that would be happening. Or perhaps it's using the texture matrix from the volume it broke away from? Maybe it's related to this hack?

https://bitbucket.org/volumesoffun/cubi ... ume.cs-296

But it should work properly, maybe try manually creating two terrain volumes in the editor and moving/scaling them to verify.