What exactly is the consequence of Complex Collision in game design
polycounter lvl 2
Using UE4 atm, just been curious there is an option for simple and complex collision. The auto generated simple collision rarely fits the shape correctly and hence it seems most are making them from the 3d software they are using. I've been thinking, what is the reason that most devs use simple collision if complex offers it up so precisely in UE4?
My guess is that having everything as complex collision is incredibly unoptimized and results to a lot of physics related calculations that slows the game. I've been looking through videos on this topic but can't find any to support this guess i have. Although i did view one that stated that complex collision or convex decomposition can create rather messy situations regarding in-game physics kinda like the issue back in Halo where frag grendes got stuck in the spartan's shoulder pads.
Hence most devs look to simplify the shape of the collision rather than having it super accurate down to the tee just to avoid such errors that might throw gameplay off on rather complicated meshes which would generate very complicated collisions. Is this right, or a mix of both perhaps?
My guess is that having everything as complex collision is incredibly unoptimized and results to a lot of physics related calculations that slows the game. I've been looking through videos on this topic but can't find any to support this guess i have. Although i did view one that stated that complex collision or convex decomposition can create rather messy situations regarding in-game physics kinda like the issue back in Halo where frag grendes got stuck in the spartan's shoulder pads.
Hence most devs look to simplify the shape of the collision rather than having it super accurate down to the tee just to avoid such errors that might throw gameplay off on rather complicated meshes which would generate very complicated collisions. Is this right, or a mix of both perhaps?
Replies
Where high accuracy is needed people will typically hand author a custom collision mesh out of convex shapes in a modeling app.
Having needlessly complex collision will have to track more faces on the collision mesh and things that don't need to be part of that collision are now factored in. Players can get stuck on things and a player capsule might pass a long a dozen or so faces when sliding along a wall where a single poly would have been fine.
When you have a wall made up of a bunch of different faces that are slightly different angles you have to store those vectors for when something collides with it. If they're all roughly the same but just slightly different you can store a single value in a larger face.
With larger simplified "impressionistic collision", the chances of hitting two faces at the same time is usually reduced. When you hit multiple you have to factor in that many more vectors, usually trying to average them and come up with an angle to react to.
You're basically rendering the world twice, once for visuals and another time for collision. Anything you can shave out of the second collision pass will help keep things running smooth.
Per Poly Collision is probably where the industry is headed at some point in the future. Certain game styles might be ok with it because the visual shapes are pretty low poly, while others will have way too many faces to deal with. Better automated solutions will help but I don't think they're focused on that because most of the stuff they do is either easily handled by it, or get custom collision meshes.
I know that some physics engines uses octree / kd-tree type of acceleration structures which results in checking only those tris against the collider, which are inside the colliders voxel, so in this case, only a few tris of the per poly collision would be actually checked, instead of every tris of it. Now I'm not sure if this is what happens in Unreal too, but if so, this could explain why I couldn't make a full per poly collision scene any more expensive than the collision primitive counterpart of it.
Make a simple container and drop 256 rigid bodies into it. Swap physics methods each time, from sphere up to per-triangle, and record framerates.
We did this while developing a Wii game, and it was instructive. Mostly people here assume everyone's developing for high end PC, but mobile is arguably a bigger market. Tighter perf constraints.
Anyhow the rigid bodies we tested:
Sphere (a position + a radius, very fast to test collisions).
Capsule (two positions + a radius, still very fast).
Box (a position + three lengths, width/depth/height, a bit more to test but still pretty fast)
Convex hull (per-triangle test, can use an arbitrary mesh shape, slower than primitives but more customizable, and I guess the fact that it has no overlaps or divots means it can be tested for collisions more quickly than concave shapes?).
Mesh collision (most precise, but most expensive, each triangle is tested for collisions).
Some systems also let you define a hierarchy for the collision shapes, which speeds up collision tests. Shapes can be ignored until their parent shape is hit. Havok did this, helped a lot.
Simple vs Complex (nightmare scenario).
Simple stores a small table of values that is easy to look up and if a player ragdolls on the simple floor they will only need to look up one or two faces per capsule on the given body part (chest, pelvis, thigh, calf, upper arm, forearm ect...). If they ragdoll on the complex, each capsule in the body may slide across hundreds of faces and have to look up a bunch of faces and calculate odd vectors which could cause the physics body to skip and vibrate in weird ways as it interacts with faces at different angles. You can have it average out these bumps by doing more math over several frames but it's better to feed it a smaller table of stable values.
Complex can store a huge table of values and even with advanced sorting methods it can be overly complex and just a large pool of data that doesn't need to be stored.
If the complex collision is only a tiny fraction more dense than simple, I don't think you'll see too much of a performance hit or an issue when something simulates so in that case it's probably worth it to use per-poly. So yea it depends and yea like others said, testing is critical.
It's also worth noting that assembling your buildings from pieces (floor, wall, beams, stairs) in Unreal with simple collision applied to each piece it will create decent collision on each piece. Then you can collapse them down into a single static mesh (to reduce draw calls) and it will merge all of the simple collision. Giving you're entire building much better collision than if you had imported the entire building as a solid chunk and tried to generate concave collision on the whole thing.
Doing it that way you don't have to make custom collision meshes and you're not using per-poly collision either.