Collision for procedural generated mesh?

#1

I’m working on a terrain engine that procedurally generates meshes as the player moves around. I want to add collision detection to these meshes. How should I go about that? These meshes aren’t simple height maps, they include geometry such as overhands, ceilings, cliffs, caves, etc.

Update; I found StaticColliderComponent and ConvexHullColliderShape, but from what I can gather ConvexHullColliderShape doesn’t actually make a collision mesh that matches the original shape, it creates a simplified convex volume containing all the points. Is this correct? If so, is there some way to turn an arbitrary mesh into an accurate physics mesh? I need the mesh to retain its concavity, or some other solution entirely. I realize this could pose performance problems but I may be able to work around that regardless.

Looking into BulletSharp I found btBvhTriangleMeshShape. This sounds like the type I’d need. Does Xenko support this, or could it?

1 Like
#2

Triangle mesh shape is not ideal in terms of performance. You should definitely use a convex hull. We currently have the feature disabled but proper decomposition is possible (to retain concavity) and will re-enabled.
In the mean time I suggest to make the decomposition manually in blender/maya/max and make a compound of those shapes.

#3

I know a triangle mesh is not ideal in terms of performance, but I can’t manually perform a decomposition in another tool. The meshes are generated procedurally at runtime as the player moves about the game world.

Does Xenko support a feature I could use to perform the decomposition at runtime? If so, how would the performance of that stack up against just using a triangle mesh? That aside, if Xenko does support such a feature I might be able to work around any performance hit from using it.

#4

Generating such stuff at runtime is not ideal in most of the cases.
Can you roughly describe your scenario?

#5

I’m building a voxel engine that enables randomly generated worlds as well as the player’s ability to build or destroy anything (s)he desires anywhere in the world at any time. It’s the same kind of technology that enables the sandbox nature of Minecraft. Unlike Minecraft however my voxel engine creates more organic looking blocks. It’s still based on an underlying cube structure, but distorted to provide a different look. Here’s a couple pictures to help demonstrate;

ommpnd.png1295×761 765 KB

zxsmoi.png1296×758 665 KB

Because the player can dig or build anywhere using blocks the game engine needs to be able to update the graphical and collision meshes at runtime. I have the graphics working as shown, but I have yet to integrate any kind of collision detection for moving or ray tracing for selecting blocks to place or destroy.

2 Likes
#6

See Project Voxelscape for more on this project :smiley:

#7

Looks awesome! Would love to know more about how you are achieving this specially without instanced drawing.
About collisions, not so easy… height field might work tho, it should be possible to update it in real time.

Triangle mesh might be way too slow to update in real time.

#8

I hate to admit it, but brute force on all fronts (at the moment). The meshes in the distance are just as detailed as the ones up close so the poly count gets absurdly high with a long view distance. This is only manageable on my machine because of the 780 Ti I’m running. I am using reusable buffers to transfer the data to the GPU to reduce garbage production though. Very happy to see that Xenko lets me do that :smiley:

However, I am working on a level of detail system to combat this. The voxels are generated in an octree data-structure and can be sampled at any depth to get a more or less precise representation of the environment. Sample at the leafs and you get what you see now. Sample closer to the root and the surfaces will be larger and fewer, reducing the poly count.

I have the octree portion already completed and am working on updating the contouring (the mesh building) to be able to run on it. A non-uniform tree structure is a bit more tricky than a uniform grid :cold_sweat:

Height field collision won’t be enough I think. The system generates overhangs and caves so more than a height map is required. Video here if you’re interested; https://www.youtube.com/watch?v=whJOtux2DrQ

As for triangle mesh; if collision detection against them using primitive shapes is fast enough for real time then that’s all I need. The environment meshes won’t be moving and I’ll likely not be colliding convex hulls against them, only primitive shapes. My system can handle reconstructing/updating the meshes in real time when the players edit the voxels. It already does essentially that for creating the graphical meshes.

#9

Not really, triangle mesh won’t help at all, every time the players add a new voxel/cube/whatever it will need an update, and there is no easy way to do that fast.

Any voxel game really goes the custom way for many things, be rendering, physics etc, that’s why most of commercial successful games you find of that style have been done from the beginning on a custom in house engine.

That said I think Xenko is extremely flexible in terms of customization compared to other engines around so it could be definitely used as foundation! With lots of love tho and will of improving and adapting the core components to the task.

Using the default physics engine as it is right now it’s going to be difficult… I’m going to examine the possibility to have custom collision detection classes plugged into the engine. Can’t promise anything tho :slight_smile: