The last few weeks have seen some more work on integrating Cubiquity with Unity3D. The screenshot in the last blog post was actually a single large mesh which made it difficult to modify, but it’s now being properly broken down into a number of small meshes which can be updated individually when their voxels change. So everything is a lot more dynamic now.
Physics objects bouncing around a voxel terrain.
The meshes are also now fed into Unity’s physics system so that they can be used as colliders. Also raycasting functionality has been exposed and these capabilities have been combined in the extremely simple ‘game’ you can see in the screenshot below. The tank can be controlled by the keyboard while the mouse aims and shoots.
The tank is a physics object so you can shoot holes in the ground and then fall into them.
So a lot of stuff is starting to come together, though I must emphasise that it’s still very much a proof-of-concept. The main issue is that we are still new to Unity, and so not exactly sure how it should be integrated. Currently there is only an interface for programmers as we need to think how this gets integrated with Unity’s edit mode.
Anyway, we’re thinking about releasing a ‘preview’ version (for free) in the next couple of weeks to get some initial feedback. I just need to look at how this stuff is supposed to be packaged up, as well as polishing a few bits of the system. Stay tuned!
How heavy is the performance cost of all those mesh colliders?
We haven’t done any performance analysis yet, so all I can really say is that it runs smoothly on my four year old PC. The boxes are all Unity Box Colliders and the terrain is a Mesh Collider with something like 12,000 triangles as I recall. You can see a wire frame here: https://pbs.twimg.com/media/BIusZM5CYAANrMW.png:orig
Eventually we should replace the Mesh Collider with a set of Box Colliders to approximate the shape, but that’s just an optimisation really.
Ah nice, quad merging too! Yeah, I did think about the possibility of a bunch of Box Colliders, but I wonder if that would be viable for voxel volumes where there was likely to be frequent alterations made to the voxel data? Looking great though, can’t wait to play with it =)
From what I’ve heard it’s faster and more robust, but as you say there’s the extra overhead of determining the Box Colliders each time a voxel changes. No idea how long that takes but there was some code floating round our forums at one point.