I’m trying to implement area damage, but we are considering alternatives due to a lack of ways to obtain components.
Is it better to use sphere overlap or sphere trace to get all the components that fall within a range?
I need to find the distance from the center to the targets and apply damage to all targets through the interface.
Of particular concern is the performance impact of having to loop through the results of multiple traces.
Also, I would like to know what criteria are used to determine overlap. Does it overlap if the collision is even partially within range, or does the origin have to be within range?
I expect the sphere overlap to do more work but to be more prolonged in time - to register characters as they enter and leave continuously. That is of course if it lives long enough. The initial overlap is probably a sphere trace.
That being said, you can implement them both and benchmark it. Never assume critical performance points - always profile.
My guess is that your accompanying logic will take more time than any of the traces so don’t sweat it too much.
Anyway, if you decide to benchmark, please share the results.
I mean the sphere overlap is essentially doing sphere traces whenever other colliders overlap with it. There may be some differences in the way it handles filtering which objects to trace against, but it’s probably negligible if it exists at all.
Rule of thumb, if you don’t need to constantly trace for objects entering your sphere, just use a trace.
Multi Sphere Trace will trace based on whether a collision is in range though. Meaning any mesh component or collision component that meets the required conditions of the trace. So its origin can be out of range, but if part of its collision mesh is in range, it gets hit. And it traces for every component in range btw. So if you have an actor that has two meshes, it will generate a hit result for each mesh.
And if you’re really worried about the performance of using for loops to filter out your hits, just brave some c++ to make a library function that filters your hit results based on certain criteria. Theres tons of ways to filter it too, by class, by whether or not you’ve already traced that actor, you can even make it a string tag that you apply to either an actor or component.
Btw, you said there was a “lack of way to obtain components”, what exactly do you mean by this? If you mean you want a reference to say a primitive component that gets hit by the trace, you can absolutely get a reference to that from the hit result. And this is the case for both Traces and Sphere Collisions
Ah, it seems that overlap does indeed react to collisions. And, it returns an array, so i can directly execute the interface function.
As you know, Blueprints are vulnerable to loops, so I wanted to avoid using loops as much as possible. However, multi-trace returns a structure of hits, so i can’t avoid using a loop.
Overlap returns an array of object types, so i don’t need to use a loop. If the overlap was determined based on the origin, it would not suit my needs, so I would have used multi-trace.
Hit Result does return overlapping components, but only one at a time. But i wanted to get all the components in the range.
Yeah it’s pretty much inevitable having to filter with a loop. Even with a sphere collision component, the result doesn’t end up much different than if you just ran a loop on a multi sphere trace. Because if you think about it, if 100 components trigger the sphere collision in one frame, it’s going to trigger that overlap event 100 times.
But thankfully c++ can do that kind of thing extremely fast, so if you can stomach it, make a c++ function to filter it. If you can’t, feel free to ask for help
As far as the target pin of a function is concerned, you can directly connect an array of objects. This allows you to run a function on all the items in an array at once without having to go through a loop.
This is a popular technique for avoiding loops in Blueprints
