Does on component hit use the collision box?

Unreal Courses Ask
#1

Does on component hit use the mesh’s collision box? Or the mesh geometry to determine there was a collision? I think it would have to use the mesh’s collision box, because UE doesn’t calculate collisions for the mesh geometry right?

What about the actors it collides with? If you add an actor to the level, and only give it a capsule component, will this delegate still detect collisions with that actor?

What, exactly, has to collide for this to generate a hit event? Is it always the bounding boxes, and/or collision components (like the capsule component)?

Collisions in UE are still a mystery to me, even after getting this far into the course haha.

#2

It would use all collision enabled components.

Have you tried that?

#3

Hey Dan, I’m trying to figure out how it calculates collisions for those collision enabled components. Like the static mesh component, is it going to use the bounding box defined for that mesh, or the mesh geometry? If an actor has a multiple components with collisions enabled, then is it’s just going to collide with the first component it hits? I’m trying to understand UE’s collision system better.

I understand your comment about “Have you tried that”, however, discussing questions with like minded people can often yield better ideas to experiment with and better define the original question. Kind of like rubber duck debugging, but you have people to challenge you as you articulate your problem.
In this case, I still don’t understand how UE does collisions and struggle to properly articulate my question and create test setups. Being able to explore this question might help with that. Obviously, if you don’t want to discuss things, you don’t have to. I’m sure many students, like myself, would find an open discussion more useful though.

1 Like
#4

What trouble are you having with that? The example you gave sounds like a trivial setup. Create an actor with a collision component, add one to the level and see if hit registers. Or do you mean different setups you would like to test?

To be honest, I wasn’t 100% certain on the finer details and was less certain before you asked.
I removed the simple collision on the projectile mesh and the hit no longer registered. And looking at the code there’s

if (!ShapeHandle.GetGeometry().IsConvex())
{
    //We skip complex shapes. Should this respect complex as simple?
    continue;
}

So I think that’s what one of the things you were asking about? As for

By looking at the code (UPrimitiveComponent::MoveComponentImpl).

else if (BlockingHitIndex == INDEX_NONE)
{
    // First non-overlapping blocking hit should be used, if an overlapping hit was not.
    // This should be the only non-overlapping blocking hit, and last in the results.
    BlockingHitIndex = HitIdx;
    break;
}
// lots of code
// Update blocking hit, if there was a valid one.
if (BlockingHitIndex >= 0)
{
    BlockingHit = Hits[BlockingHitIndex];
    bFilledHitResult = true;
}
// lots of code
// this will end up calling OnComponentHit.Broadcast()
DispatchBlockingHit(*Actor, BlockingHit);
#5

Yeah I meant thinking of different setups! Because I agree, that one scenario is trivial, but it isn’t enough to fully understand how everything works.

Ok, so that makes sense, and if I understand you correctly: actors can collide with a mesh component if and only if it has a bounding box, unless UE updates the engine code to change that. Which it looks like they haven’t decided haha.
In addition, it seems to treat every component separately, and will do a blocking collision with the first component it hits (if blocking collisions are chosen instead of overlap/ignore).

So based on that, I think we should be removing collision boxes for the tank and tower pawn’s mesh, so that only the capsule component is having collision calculations done. That is, if we wanted to improve efficiency.

I found some interesting things too!

You can’t generate hit events when colliding with actors attached to an actor via AActor::AttachToActor. I tried grouping actors together with this so I only had to call one set location function, but none of the attached actors would properly generate the on hit event (but they would still properly do blocking collisions in the viewport). However, if I used a TArray instead to group them, they all generated the on hit event as expected.

Furthermore, I found out that you have to set the optional bSweep=true when setting the actor’s location otherwise it won’t generate the on hit event. This one probably seems obvious to people with more experiences though.

The final interesting thing I discovered is that collision boxes are sticky (At least for ACharacter, I haven’t tested with APawn of AActor). If the collisision box moves and the character is on top of it, then the character sticks to it and moves too without generating collision events. The only work around I found was to have the mesh and collision box move separately, ie, the collision box stays still while the mesh moves.

I’m still trying to figure out if there’s any implicit enforcement for child components. Like if a capsule component is doing block-world-dynamic collisions, and it has a child mesh component that’s doing overlap collisions. Does the parent component override the child components setting. Do they both keep their individual collisions settings. I don’t know yet.

Anyway, I really appreciate the in depth response Dan, Thank you!

#6

That should be part of the UCharacterMovementComponent code if I’m not mistaken.

#7

Oh ok, interesting! I only did some tests with an ACharacter subclass so that’s good to know it’s probably in the character movement component!

I ended up fixing this by creating a separate actor for the mesh and the collision, and then moving the mesh so the collision box stayed stationary.

#8

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.

Privacy & Terms