Performance check: Collision Overlap events or timer based distance checks?

Hi, I have some AI bots that move toward a static target. When they overlap with this target’s collision component, the bots deal damage to the target and destroys themselves. I’ve been using Overlap events using capsule components to fire this explosion behavior. Due to a bug with inheritance, I have to rebuild my AI code again. So I’m wondering whether it would be better to use timer based functions that are called say, every .5 seconds to check the distance between the bot and the target. Performance wise, would it be better compared to collision overlaps?

Performance wise, I believe even distance check per-tick would be cheaper compared to overlaps (because it’s simple vector math vs object iteration) but the difference is probably not going to be something noticeable either way (well it depends on the number of bots, objects in the level and size of overlap shape I suppose).

Thanks for the quick reply @TK-Master :smiley:

For this particular enemy type, I do not have much need for the overlap except this one object in the map. Besides it’s for a template that I’m working on and this particular functionality is for one of the sample bots. So if people would want to have many bots at the same time, it might help them.

Sorry for semi-necro, but I have the same concern, but about static sphere colliders. Will distance checks still be cheaper than them? I ask because I want to switch my sphere colliders to distance checks every ~0.1s and I don’t know if it wouldn’t be less performant?

PS. Here’s my original thread: Static Sphere Colliders VS Distance check every 0.1 s - Content Creation - Unreal Engine Forums

Im curious about this as well. In the same token, are raytraces cheaper than colliders? I mean the way i understand them,they are technically still collision detection tests.

I guess that in some cases it’s better to use colliders, for example when we don’t know the exact actor that we want to interact with. Then when *something *enters a collider, we check if it belongs to some group, etc. But if we know specifically against which actor we want to check distance, then… Probably distance check every x seconds is better… But I still don’t know how about performance when it comes to **static ** sphere colliders vs distance checks…

… Anyone? :slight_smile:

BTW. I’m really curious about how colliders/triggers/etc. work internally - do they check something every tick, if so, what it is? I can’t find any articles about that.

I would also like to know if the colliders keep checking their bounds every frame or not. Since most of my current requirements are centered around interactions with known actors, I use the distance+angle+linetrace check with timers. But it would still be great, if more information could be available for these things.

I would do 5-10 checks/second on a more broad trace, that way the component does have to check if it moves and it doesn’t consume tick-based resources.

I know this reply is quite late, tho

Hi, I want to share my experience in deciding what to choose between a timer check distance and by collision.
I have a pretty big island, with lots of light, particles. Since my project also works on mobile devices, I often worry about places where you can optimize something.
In particular, it is not only to turn components on/off, but also to switch between using Timeline and Timers.
Looking at the Profiler, I found that my events, which calculate distances to processed actors, take quite a good time.

Briefly, how many objects I consider and when.
The timers are set to 2 seconds for phones and 1 second for PCs. Time between checks 0.3 ms (Time after which a different type of validation queue will occur).
The total number of components being processed is ~ 1607 (night 1917).

It was decided to transfer completely the mechanisms from distance checking to object collision checking.
In fact, for these components, added small balls, added his own channel to check overlap, created a separate actor sphere, and attached as Child Actor to the main character so that the events of intersection are not sent to the main character.

Result:
Got a very cheap search algorithm by the proximity of actors, but had to rework the existing switching algorithms (including from game settings)

In fact, I would also like to mention the problem that many faced, namely - in the movement of the sphere, the loss of FPS. To minimize this problem,
I turn on and off the collision for the character sphere at intervals. Also, if I have moving objects that I also work with, I add all the actors on stage, at the stage of actor initialization. And I also switch collision for them.

During the inspection of the components inside the sphere, I create an additional set (a copy of the set) of the selected actor type, and delete the element if this actor was found during the search for actors inside the sphere.
To speed up checks, I don 't naturally use Arrays, but Sets. (They store items not by index, but by hash code)
At the end of checks of actors, I dump from the current sets, I Pass sets on removal (Difference) on all elements, disconnecting the corresponding event.

Also, I will attach screenshots of processing time before/after.

Before:



2bbbc4a60301608c219c624d778b6d2d0cea58de.png
6a61176efa1e7bcc87f9b1d3f98d7ed126c72227.png
https://forums.unrealengine.com/core/image/gif;base64

After:

a80efb1a8064c724cc25dd6295965cb97cd7cfc7.png
2c38e5dbd4debecf55f11f54a4856a2f846f5037.png
https://forums.unrealengine.com/core/image/gif;base64

UPD: I was embarrassed that turning on/off the collision took 0.050-0.060ms.
The solution was to create an overlap sphere through the function rather than using a sphere component. (Thanks)
I have disabled Generate Overlap Events for my components and I do not process moving objects in any way. (Just processing them as everyone)

I can also note that using collision checking - perfectly optimizes game events that need to be activated during the game, or changing
graphic settings. Since with this approach, we contain information about all components inside spheres, and can immediately switch only their state.

62fdd7773d52aa032cbb5282673cd58aa094a70a.png
4f41b5b1f833e6368866288e433b71ca7bfeb644.png

If someone wants to realize a spherical overlap collision, you can take my approach.
Before turning off, I check whether the object is valid (since I have objects that can be deleted over the course of playing time)

bff383dd48da01b49c5e28c5c52cb592376bdb2d.png