Hello,
As long as you don’t have any interaction with a mesh, does it’s collision complexity matter?
For instance if a mesh’s collision is 8 poly or 512 poly, is the 512 one costing more performance already even if you are not touching it’s surface?
Try it out, make a collision mesh with a dazillion tris ^^
I’m curious about this too – glad to see Luftbauch volunteered to measure for us!
Yes Sir, with all my love i created a performance testsetting, it took me 12 years from plan to finish, but now it is finished.
Here you can find my testresults. Google
I reviewed first 18 pages of your study, alas it appears that original question is still unanswered. Could you please direct me to the actual location where the question is anwered:
Does collision complexity affect performance, for an object that is not collided with? (bonus points for ‘how much does it affect by’)
Dear Sir. While looking at your nice project, i feel that you are more experienced in any section then me, aside breathing.
When you could do us the favour to setup a representative testing area and system analysis, it would be more representative and official!
The “that is not collided with” part smells like a trap for me, better duck and cover.
The question would be, why it has a complicated collision object, when no collision is checked?
If anyone has an answer to OP please share a word.
Thanks.
I would assume that yes, complexity does increase the cost. If you want to test it out for yourself take a peek at the profiling tools as they will give you a lot of info into what amount of time things are taking in your game loop.
In general though, I’d suggest not worrying too* much about optimizing too early, because without knowing your exact use case it may or may not be an issue at all. Won’t know till you try 
It’s also worth pointing out that at least for colliders used for player movement, simpler can often be better because it’s relatively easy for the player to get hung up on corners and the like so ‘smoother’ colliders can often help with ease of movement though the level.
For our game, use case is quite simple – all non-skeletal geometry is generated at runtime (except skybox), and collision is created by passing all triangles (as per ProceduralMeshComponent). Therefore, collision is quite complex.
In a arbitrarily selected view, we could have some 500k vertices, ALL of which participate in individual object’s collision primitives. However, all of our performance is consumed by either GPU or Render thread, and just a fraction on the CPU. Even a scene with some 50 NPCs roaming about, we don’t start noticing collision taking much of the CPU. This is probably due to fact that most of the walkable surfaces have triangles that are some 2m-5m in size. Most of the objects with higher density are not collided with very often.
Reason for curiosity (but not enough to start some elaborate measurements) is concern that at some ‘later’ stage we’ll have to redo all our collision primitives. Quite a bit of our gameplay relies on accurate collisions. If we have to simplify it, we would get into all kinds of problems requiring further rework.
Our current gut feeling is that complex collisions cost some RAM but bounding boxes of the object take care of all non-collision cases. Since bounding box processing is per-object, non-colliding doesn’t add any CPU time.