I’m a Unity guy trying to learn Unreal and I’ve run into a roadblock setting up basic collisions. I followed the docs ( Collision in Unreal Engine - Overview | Unreal Engine 5.0 Documentation) and my two colliders completely ignore each other. I’ve had several other devs take a look at it and nobody seems to know what the problem is so now I’m here.
I have a pawn and a container. The container is just 4 of the built-in Cube objects arranged to make a square fence-like shape.
The pawn has a static mesh and some other components. The mesh is an irregular shape, but the collision for it can be very simple. So the mesh doesn’t have any collision shapes on it and instead I added a CapsuleCollider component to the blueprint.
I made a collision type Container and assigned that to each of my cubes in the container blueprint. It is set to block the Pawn collision channel.
The pawn’s collision type is Pawn and is set to block Container. The pawn is moved using a FloatingPawnMovement component and AddMovementInput in the event graph.
And since I am here making this post you can gather that the collision isn’t doing anything. The two objects pass straight through each other.
I’ve tried every combination of enabling hit events, overlap events, simulating physics, CCD, etc. I set the Cube collision to Use Complex As Simple (I couldn’t find that for the capsule, but I can’t imagine a cube and capsule would be considered complex anyway). If there is something to be toggled I’ve toggled it.
As you can imagine, this is incredibly irritating. Collision should be relatively simple and the docs make it seem that way. What is the missing key to make blocking collisions block each other?
Hey there @JohnAZoidberg! Judging by the two collision settings you showed off, they should be colliding, so let’s take a moment to figure out what’s going on.
Are the collision settings you’re showing off for the pawn the static mesh or the capsule collider you set up?
It’s likely better to generate a basic collision for your SM and just use that for simple floating movement objects.
In this case the Pikachu is just an actor with a projectile movement, but it still doesn’t collide and it is probably safe to assume whatever makes this work will also make the pawn with floatingpawnmovement also work. Maybe. If things worked the way I assume they should I wouldn’t have a problem to begin with.
The collision settings for the pawn (and the pikachu actor in the example above) are shown for the CapsuleCollider component.
The ultimate goal is to make a pawn that can have different meshes swapped in and out without each affecting the overall collision shape, so I made a scenecomponent that will just hold all of the meshes. Think of it like a car that can have a different hood or fenders or whatever but the collision shape doesn’t change just because one set of fenders is a little wider. And since the collision shape can be very simple I just added the CapsuleCollider to the blueprint so the collision and the visible meshes are completely independent of each other.
I’ve been using Unity for some time now and it treats the visible object and the collision as completely separate entities. Does Unreal not separate these responsibilities?
Ok so this is going to lead to a dozen more questions from me.
How am I supposed to know this? The documentation about collisions doesn’t mention this at all.
How does this work with inheritance? Must the parent class have the root component be some kind of collision component that the children can’t change? Just out of habit I made a bp_ProjectileBase class that all my projectiles inherit from. It doesn’t do anything yet, but I expect to need it in the future and doing it now saves me from reparenting everything later. Does this mean the ProjectileBase class sets the collision shape for every child projectile?
Does Unreal not support having several collision shapes on an object? For example, if I wanted a collider that is shaped like a snowman. Would I have to make an fbx of that shape and import that the root object (then make it invisible etc)?
What exactly do you mean by this? If I have multiple static meshes in the blueprint they all move the same, regardless of their position or depth in the hierarchy.
There’s no good answer to this. While the documentation is vast, it’s neither complete or fully updated, and there are gaps; there are undocumented behaviours and what the docs suggest is not always optimal. That’s one complaint that has been persistent throughout the years.
Lots of instant answers in the tooltips, though and in the C++ comments:
The above setup will not work because the actor root has no collision; move the desired collider there:
How does this work with inheritance?
If you now create a child class of this actor, the child will be able to override the mesh the Static Mesh Component handles:
Even though I can no longer mess with the inheritedcomponenthierarchy (I can add to it, of course), I can have another mesh assigned to be used as the collider for the movement component.
Must the parent class have the root component be some kind of collision component that the children can’t change?
Pretty much, yeah. The children cannot change the comp itself, but they can override how the component behaves.
Does Unreal not support having several collision shapes on an object? For example, if I wanted a collider that is shaped like a snowman. Would I have to make an fbx of that shape and import that the root object (then make it invisible etc)?
This has been a requested feature for as long as I remember. If I attempt to:
Thank you so much for your time and the fantastic help. Its a bit of an adjustment coming over from Unity and the way Unreal handles collision just seems so… antiquated? That’s not the right word, but they definitely have some room to improve, imo. I guess that’s what happens when Unreal was designed for FPS games then slowly expanded vs Unity which was designed to do whatever from the start. If only Unity had literally one competent person managing the engine’s development I wouldn’t be so eager to leave.
But I digress. This will require me to rethink how a few things will work, but (thanks to your assistance) I know how it works. And knowing is half the battle. Or something.
