Collision Ray / Traverser performance

[darthrigg]

Hi all,

I’m really struggling with performance here. After using PStats it’s clear the problem is with the collision traverser.

Initially, I was traversing every frame. I since added a bit of control to that so it only checks every number of frames. Still though, the problem is, the very call to “cTrav.traverse()” is hitting hard.

I have 2 collision pushers - they’re not a problem (if disabled, performance is more or less the same) and 1 collision ray. It’s the “glue model to uneven terrain” approach. The ray is cast down from above the model, collides with the terrain (in this case, a full race track - it is a big model and that might not be helping) and the Z on the model is then set via a call to getSurfacePoint.

Standard stuff. So I’m scratching my head a lot here. Screen shot of pstats…

Can anyone help?

Cheers,
Gary

[ThomasEgi]

testing against one huge pile of triangles is quite slow. there are ways to improve performance by using an invisible-copy of the race track that is split in a lot of smaller pieces. quad and octree-like structures are most efficient.
there should be some scripts on the forum to convert a mesh into an collision-optimized thing. named eggoctree or so

[darthrigg]

@ThomasEgi

testing against one huge pile of triangles is quite slow. there are ways to improve performance by using an invisible-copy of the race track that is split in a lot of smaller pieces. quad and octree-like structures are most efficient.
there should be some scripts on the forum to convert a mesh into an collision-optimized thing. named eggoctree or so

Interesting. …the idea of a second invisible copy I like. Thanks!