maybe a dumb question but i’m curious about this. i’ve read elsewhere:
what would be better performance wise for level geometry: to have a compound static collider with many primitive colliders (as in 50+) for level objects or a single mesh collider?
i tested this small scale but couldn’t really tell the difference and it would take a while for me to test it across a whole scene - does anybody have a simple answer?
Primtive colliders would be faster.
But if you keep the collision mesh size to sane levels, i dont think it will make a big difference. Performance is seldomly limited by that.
cool, thanks for the info ; )
i’ve been keeping my rendered meshes at 3000+/- or less and i was figuring i could get away with a more for collider (non-rendered) meshes - but across a whole scene that could add up to alot of polys in mesh colliders.
I wouldn’t worry about it. If the player isn’t near a mesh, it seems to me that the entire thing is bypassed for collision detection, so you can have a number of large meshes with few problems. As long as tons of stuff isn’t constantly colliding with zillions of huge meshes you shouldn’t see any performance problems, or at least I certainly don’t. Trying to create a bunch of primitive colliders to sort of match a big mesh collider would be far more painful I think…
–Eric
agreed but there are circumstances where the workload can end up being the same really. if you have level meshes that have detail (smaller angled polys) in certain areas you can get the framerate to slideshow on you if, for instance the character controller runs into it generates a bunch of collisions all at once. so for things like that (or for high-speed physics requirements) you need to build a simpler version of the mesh for collision anyway - so pick your poison i guess ; )
yeah eric… you also get 900 fps! 
but yeah i wouldn’t worry about it too much and setting up primitives would be a pain.
i’ve been keeping my rendered meshes at 3000+/- or less and i was figuring i could get away with a more for collider (non-rendered) meshes
games typically do the opposite. collision meshes are usually less complex than the rendered one. Like a detailed house for rendering where the collider is more-or-less a box.
[edit: posted at the same time. um yeah what you said! i still think it’s easier than primitives.]
to be sure, however, i was under the impression that finer tesselated mesh colliders were recommended if you have any highspeed physics (which i do ; ) and experimenting does seem to back that up. my general 3K poly per rendered mesh limit is for video card performance - a non-rendered collision mesh performance is cpu based is it not? - so i was allowing myself a bit more leeway for those that’s all.
Well, it depends on the level, too, doesn’t it. If you’ve got lots of interesting geometry that the player is interacting with, then go for the mesh collider. If you have areas with basic shapes and the mesh is only there for detail (like the house example), then go for some primitive colliders.
Anyway, you should just do whatever’s easiest first (i.e., the mesh collider) and worry about performance later.
Edit: speaking of 900fps, I just did a quick test. In the upper left is 1 mesh, 323 box colliders, no collisions. In the upper right is 1 mesh, 1 mesh collider (3,876 triangles), no collisions. Bottom left is same as upper left, but with 25 spheres rolling right and down across the ground and colliding with the box colliders. Bottom right is same as upper right, but with the 25 spheres colliding with the mesh collider.
Most of the performance hit is because of rendering the spheres anyway. If I turn off the mesh renderers for the spheres, it goes back up to about 890 fps in both cases. Like I said, I wouldn’t worry about using mesh colliders…the physics engine is pretty fast. 
–Eric
i did a test of similar scale on a level mesh of mine couldn’t see any difference as well - that’s why i was asking what i did though - i was wondering the tradeoff between mesh / large combo colliders when you have 30 objects @ 3K polys a piece in one scene (+/- 100K polys overall) - i didn’t think to do something straightforward like your example (thanks for investigating btw ; ) - i’ll try it myself later.
also i’m the kind of weirdo who feels better knowing the “general principle” answer to questions like that ; )
yeah, tessalation helps at high speeds. but it still doesn’t solve it. the issue is that if your object completely moves through a poly in between time steps, the collision is missed. it’s checked every time step. so if your time step is .1 and your object enters at .02 and exits at .08, the collision won’t register. even a tesselated mesh can be beat. it just reduces the odds of it happening.
i think the only way to really ensure it is use a closed mesh. i’m speculating as i haven’t really tested it but i think if you’re object is in the volume, the collision will register. still time dependent but at least you can make your volume bigger. you can’t change the thickness of a poly. opens another can of worms in getting stuck in the volume though…
Just a small note about the above mentioned.
Sphere colliders are faster than Boxes because they only use a Center and a Radius, on the other hand, Box colliders have 2 modes, AABB (Axis aligned bounding box) and OBB (Object Bounding box), where AABB is faster than OBB because it is simply aligned with the world and requires less calculations.
This is true for 2D and 3D collisions
Best
