So, I’ve done some research and I’m not satisfied with the answers I’ve found. I’m hoping some experienced programmers can give me insight.
Is it better to have a collision/overlap box on the character or the mesh that the character is going to interact with?
“OnEventBeginOverlap” is a tick function, no? So, if I have an elevator button that has a collision box on it, that box is using resources to detect my character when they draw near?
If there are MANY interactables (characters, objects, etc.), and they all have their own collision/overlap boxes, would that negatively impact performance?
I would prefer them to have their own boxes because it will GREATLY simplify animations, but if my suspicions are correct, and they do have non-stop ticking going on, then I suppose I need to attach a collision/overlap box to my character instead.
Hey @Leomerya12,
not an experienced programmer, sorry, but I can give you some basic answers
The collision detection will slow down your Game very badly when:
you’re moving the collider or its Owner a lot (since collision update happens whenever the Component’s Transform updates, or during animation or anything else that moves the moves the Component)
the collider has a complex geometry (more complex geometry == more math calculations to detect the collision)
the collider is very BIG or moves very FAST (because then it can collide with multiple objects around and has to respect them all during collision calculations, which takes time)
and that’s exactly why you can often see in Games that:
there are no many objects that move and collide at the same time
whenever an object moves it has a simplified collision (e.g. ACharacter uses capsule and projectiles use sphere collision)
objects with complex collision are almost always static / non-movable
collision geometry differs from actual visible geometry and it’s often way more simpler
So the answer for almost every your question is… well… it depends, haha
You need a collider on both, it doesn’t really matter what is the type of the collision - either blocking or overlapping. For your CPU is just a simple check.
No, it’s not. Collision updates aren’t based on ticking (already explained it above).
Yes, something like that - if they’re close and some of them is moving (already explained it above).
So, I imagine putting an “interactor” box on a character is a bad idea?
As that collision will be interacting with everything as I move, doing checks on whatever it comes in contact with?
When I was a beginner (I’m advanced intermediate at this point) I remember making a tiny RPG, and when I did attach a collision box on my character so that they could interact with other characters, the editor ■■■■ near crashed until I made sure to set specific actors as interactable.
We all use Unreal differently, so this may not be in your wheelhouse (or it may!) but what would you do in that situation? You have a moderately sized RPG with a character that needs to interact with 1) Other characters 2) Objects.
Box collision (with exceptions) on the main character?
OR
Box collision on the objects and NPCs themselves?
I’m early in development, so I want to nip this in the bud.
Again, it depends how exactly you use it. You may not see any performance issues after doing such thing.
To be honest, if you don’t actually know how something works, I would highly suggest not caring about the performance at all, as probably you will only waste your time on premature optimization than achieving anything.
However, if you’re using an ACharacter, this class should already have UCapsuleComponent which is very fast and you can use it for collision checks.
Just make sure to:
whenever possible, use already inherited collision components (e.g. ACharacter comes with UCapsuleComponent, just like mentioned above)
use as simplest colliders as possible. e.g. you’re asking about “Box” collision, but why don’t you use a “Sphere” or “Capsule”? these are way cheaper
make sure to set up the collision channel/response to detect only what you actually needs. e.g. if you’re setting up a collision trigger on the NPC, and said trigger only needs to detect your Character, don’t make it “overlap” everything, instead let it “ignore” everything and only overlap the Pawn (ACharacter is inherited from APawn so it would also detect the ACharacter). More about this topic here Collision Response Reference
Try NOT to use casting inside of OnBeginOverlap. Ppl often do that do detect witch exact Actor/Component they’re colliding with but this approach is very costly. Instead you can use something like Blueprint Interface
I’m pretty sure this issue was caused by not following some of the rules that I stated above.
Also, one more thing
Don’t care about the performance in the Editor or Development builds (unless it makes the development process impossible).
You should only test and fix performance issues if they appear in Shipping or Test builds.
I hope, this is helpful enough.
Sorry, for not giving away a direct answer for your exact problem. You should be the one finding it
