Comparing distance vs checking for collisions.

I keep hearing that too many collision checks can be a bad thing, but what about distance checks?

For example, if a guy walks over a trap and takes damage, it could be done two ways. One, it could check for a collision with the trap and say that on collision the guy takes damage. Or two, it could compare two values, and then compare the distance between the guy's X and the trap's X and when it's less than 100, it triggers the damage.

Which way is more efficient? I keep running into times when I need yet another collision check, and sometimes a distance check is better anyway for flexibility. For example, I can set a distance check greater than the sprite's bounding box if I want a bigger trigger zone.

A simple collision check is best. However doing a overlap check is far less performance demanding for some reason.

So "On collision" event you shouldn't use, if you need a lot of tests.

"Is overlapping" you should use for lots of test and in general, if performance is important.

I'll try to use "is overlapping" whenever possible. As long as it triggers reasonably fast, it should be fine. I'll test it. I'm already using it in some places, so I'll see what else I can do with it.

What about distance checks? I need to use them quite often. I didn't know if they were more resource intensive than collision checks since I'm not big on the programming side.

I made this small Capx as a test of collisions. It let you spawn a lot of objects and then check performance.

I have added a distance functionality in it, so collision checks are disabled and enabled based on distance, so if two objects are not with a certain range of each other then collision checking is turned off for those objects.

You can see the difference if you disable the group called "Disable collisions" compared to when its used.

However be aware that the program was only for testing, so you need to do things in the correct order, which is pretty much just to press the buttons in the correct order.

1. So first you spawn the amount of objects you want to test with, you don't need to press it more than a couple of times.

2. Press the second button to remove the current overlaps.

3. Add some speed to the objects.

After you started it don't press the create button, as you will have to force close it then.

But maybe it can give you some ideas of how to do it.

https://dl.dropboxusercontent.com/u/109921357/Performance%20test.capx

[quote:16zj1skn]What about distance checks? I need to use them quite often. I didn't know if they were more resource intensive than collision checks since I'm not big on the programming side.

It depends on how you use them, each time you make a distance check you the computer funny enough have to do a calculation to determine the distance, so it would seem logic that it would be worse than not doing it, but in my test for instance I use distance checks a lot as it will help reduce the amount of collision checks that needs to be done each tick, as not as many objects need to be checked all the time, it actually give a performance boost.

Cool, thanks. I'll play around with that.

Wait, what? I'm 99% sure 'on collision' and 'is overlapping' are exactly the same performance-wise. nimos100 where did you get this info?

Obviously doing a simple distance check is less expensive than a collision check, but you lose polygon data.

[quote:479cjqvv]Wait, what? I'm 99% sure 'on collision' and 'is overlapping' are exactly the same performance-wise.

nimos100

where did you get this info?

I cant explain exactly how they work as I simply don't know. But its based on pure testing. You can actually check it with that program I linked earlier. If you just add that event, and disable the other.

Here are some data from my tests:

(The collision group is a functionality I added, trying to optimize collision checking, if you wonder what it is, its not an event or action you find in C2)

Using overlapping (With the Collision group disabled)

Number of objects: 2490

FPS: 8-9

Collision checks per sec: 18000-21000

Using On collision event (With the Collision group disabled)

Number of objects: 2512

FPS: 2-3

Collision checks per sec: 1013025+

Using overlapping (With the Collision group Enabled)

Number of objects: 2501

FPS: 29-30

Collision checks per sec: 12000-15000

Using On collision event (With the Collision group enabled)

Number of objects: 2464

FPS: 3-4

Collision checks per sec: 2048000-3100000

These are my tests that I just did, as it removes overlapping objects before checking collisions, there is a slight difference in amount of objects. But nothing that will change the results in any significant way.

But if you look at the collision per secs, which is from the debugger, it goes nuts on the On collision event, even when you remove the squares that are overlapping. So something is clearly not the same but there aint really a lot you can do with the "On collision" event as its part of C2 and cant be modified.

[quote:479cjqvv]Obviously doing a simple distance check is less expensive than a collision check, but you lose polygon data.

My program only uses small squares so whether the tests would differ if it was random shapes I don't know or whether it would have an impact on the polygon collision mesh accuracy when doing collision checking. However I do actually think that the result would be pretty much the same as them being simple squares, but I haven't tested it.

Is overlapping isn't necessarily faster than on collision, but I've found it to seem less prone to causing jank when you have a lot going on. I use it 95 percent of the time.

On distance: seems like one of the most useful things you can do with the distance command is make a non-physics object that's perfectly spherical.

Distance tests don't work with collision cells, do they? Like, if you have a few thousand enemies spread over a large layout, and you are testing collisions against them, col cells will eliminate a lot of the overhead, whereas distance will test against everything--unless that's changed recently.

Actually, I did an opt in one project where I was using pick nearest/distance for cols, then taking that distance and using it to determine how often to check cols. So...an object far away from anything it can collide with will check for cols much less often. Seemed to work pretty good even with boatloads of objects.

[quote:33eidwo3]Distance tests don't work with collision cells, do they? Like, if you have a few thousand enemies spread over a large layout, and you are testing collisions against them, col cells will eliminate a lot of the overhead, whereas distance will test against everything--unless that's changed recently.

Not sure I understand exactly what you mean. But in my case, as it uses a simple distance check to determine whether a collision check should be made in the first place or not, the problem occur as the distance check doesn't take the shapes of the object into account, so if a distance check is used to limit the amount of collision tests needed but the shape of the object is not symmetrical there might actually be overlapping and a collision check should be made, but doesn't happen because of the distance not matching the conditions, so at least in my example you get performance at the cost of flexibility. And guess that will be the same problem that the OP will experience if using distance checks.

But in my tests all uses the same setting in regards to collision cells etc, the only difference Is the amount of objects that might differ a bit. But you can easily see the difference in performance when using one method compared to the others. the only one is On collision as it doesn't allow you to change how it works, so it doesn't make much different how you try to optimize it as I see it.

[quote:33eidwo3]Actually, I did an opt in one project where I was using pick nearest/distance for cols, then taking that distance and using it to determine how often to check cols. So...an object far away from anything it can collide with will check for cols much less often. Seemed to work pretty good even with boatloads of objects.

Yeah agree, there are lots of ways to optimize performance when working with collisions. And if you need a lot of tests, its definitely worth trying to find a way to do it. It seems that C2 provide the functionality so it is solid and work in every setting, but doesn't do much to optimize how its done.

Regarding "On collision" I suspect that the reason it give worse performance might be because it some how sub divide the amount of checks being done, as it needs to trigger on a very particular point, which is the moment that a collision between 2 objects are made, and therefore it need to be more precise.

So if an object travel at 300 px per sec and hit another object, to avoid that the object overlap the other object or overshoot it, the amount of checks needed is sub divided to make sure that It doesn't happen. Also it might be more sensitive regarding the collision mesh of the objects than overlapping is. However its just a guess.