Advertisement

Improving collision query?

Started by October 13, 2016 12:18 PM
14 comments, last by Kylotan 8 years, 4 months ago

I just tried +2000 objects to see what happens, but yeah in the end I will only need around 500 checks at most considering what I have planned for now.

Never used a profiler but I'll take a look at it.

But yeah I understand now what you mean

Thanks all for the tips and help

"Two plus two equals five ... for extremely large values of two."

As already noted, spatial partitioning is key. I have also found in my own implementation to be very helpful, for per primitive collision checking, such as with terrain, hold an index to the last previously collided with primitive, check that first in your loop. If that doesn't hit, next check the surrounding 6 primitives, if none of those hit, then do a complete collision check starting from scratch. That turned my unplayable scene from 10fps with multiple objects, to lightning fast.

Advertisement

You might want to have/use variables/constants with the values (TILE_SIZE_W / 2.0f) and (TILE_SIZE_H / 2.0f) at least to simplify your code (in its code appearance as if thats a constant then the compiler should be simplifying it itself)

I would use a name like HALF_TILE_SIZE_W HALF_TILE_SIZE_H ...

Also once you determine it->isColliding = true; you keep looping and you should probably break out of the loop (or never enter the loop if its true at the if(it->CheckMapCollision()) test

you also seem to be running the same full collision testing twice (2 loops) doing the X Y vectors seperately when you aught to be able to combine them . It looks like are doing all the setup calc for each of the 2 it->Collide() twice.

As for minimizing the set of objects you need to test against that requires a spatial splitting method (if the obstacles are static, then there is less overhead than if you have to adjust the sets every time them would move)

If static a you could use a 2D supergrid array of nodes each with a membership list which you then test the moving 'it' object against only the supernode grid its in (or a small subset if your movement vector crosses more than one)

--------------------------------------------[size="1"]Ratings are Opinion, not Fact

Yeah I've done some improvements to the loops, for example skip them if already colliding.

you also seem to be running the same full collision testing twice (2 loops) doing the X Y vectors seperately when you aught to be able to combine them . It looks like are doing all the setup calc for each of the 2 it->Collide() twice.

I run the loops twice so I can "slide" the player along walls/objects when it collides. For example if player can't move on the X axis, I don't want Y axis movement to stop if Y doesn't collide. I've never really figured out how I could achieve the same effect using only one collision loop for both X and Y

I bet there's a simple method for that but I always think so complicated..

"Two plus two equals five ... for extremely large values of two."

When performance becomes a problem, just switch to some stablished physics lib. Bullet for 3d, Box2d for 2d.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

I run the loops twice so I can "slide" the player along walls/objects when it collides.

But you only need to worry about that when there's actually a collision. Run just one loop to find collisions, then if (and only if) one is found, check the 2 axes separately to calculate the sliding.

This topic is closed to new replies.

Advertisement