Hello there,
I recently played around with shape traces in Unreal 5.6 and stumbled upon something that got me wondering. Let’s take a look at the Box Trace in Blueprint:
As you can see you specify a start location, an end location, an orientation and a half size. Most if this is fine and obvious, but I was wondering why would “Half Size” be a vector3 instead of a vector2. If you think about it we should be able to create the complete collision shape for the trace with a vector2 describing the box length and width since the final value can be derived from start and end location:
Reading the documentation for Multi Box Trace For Objects it says:
Sweeps a box along the given line and returns all hits encountered
I was wondering why we would want to do that. Wouldn’t it be more performant to just have a single shape and do the trace than moving and checking step by step if something is inside my collision shape? What would be the applications for sweeping smaller collision shapes from start location to end location instead of having one big shape and doing no sweeping at all?
So I went ahead and posted a question in the forum asking for help understanding the different use cases and applications. Special thanks to @Chatouille and @ClockworkOcean for helping me get on the right track understanding shape collisions.
While you can achieve the trace in a number of different ways, your results will vary depending on which approach you use. I went ahead and tried out different settings and wanted to share my results here, hoping that if someone wondering in the future might find this helpful.
So here is my setup:
You can see a box collision and a number of colored spheres. The box collision itself is just a visual representation of where the trace will happen later when I run the game and won’t be used for the actual collision handling. The colored spheres are just basic shapes of Unreal colored and named differently.
First setup: Trace 1 One Box for the whole trace, no sweeping
First let’s take a look what happens when we do a trace with a single box, not moving from start to finish (this time the box you see is the actual box trace):
I hope you can zoom in on the images in case you want to read the values I have logged out. But for most of the images the visual representation will suffice.
What you can see here on screen is:
- Hit locations (Cyan Ball)
- Impact Locations (Yellow Ball)
- Impact Normals (from Impact Locations, yellow cylinder coming out of the Impact Locations)
- Hit Normals (from Impact Locations, cyan cylinder coming out of the Impact Locations
We will keep this coloring for the other setups too so refer to this legend if you need a reminder.
The setup is quite simple: start and end position will be the same, so the box collision shape will not move. In other words no sweeping from start to end location occurs here since start location = end location. Instead we scale it so big that it ranges from start to end position and see what happens.
Here is the code:
Trace 1 Impact Locations
The first thing I have noticed is that we only see 3 different impact locations on screen. I have rotated around the purple and orange sphere in the viewport, but would not see any impact location shown. Upon closer investigation it seems that the impact locations were inside the purple and orange sphere. The impact locations were exactly at the object origin of the purple and orange sphere. This would only change after I moved the spheres so their object origin would be outside of the box trace collision shape.
This means: if you do a box trace and the object origin is within the box trace collision shape at the very beginning of the trace, the impact location will be the object origin and not on the surface!
Trace 1 Hit Result Order
Furthermore, the Hit result order is wrong. The start position is on the left and the end position is on the right. I would have assumed the order of the hit results to be:
Purple > Blue > Red > Orange > Green
but it is:
Orange > Purple > Green > Blue > Red
This means: for all objects with their object origin within the box trace collision shape at the very start of the trace the hit result order will be random.
This also means: if you simply need to check for objects within the trace shape and do not need an exact impact location or the hit result order this approach with a large shape without sliding it from start to finish works fine (and is assumingly more performant). If you do however need to work with impact locations, or need the hit result order to be expected (for example where exactly a gunshot hit a mesh), then this approach does not work and you need to work with a finer collision mesh which slides from start position to finish position (which we will look at in the next example)
Trace 1 Hit Locations
The graphic also shows all hit locations (cyan spheres) of each colored sphere. But you might be wondering, why do we only see one hit location? That’s because all the 5 hit locations share the exact same location! You can double check this in the values printed at the very start if you want.
This means: the hit location is the location of the collision shape (in our case our big box scaled so it collides with all the spheres shown earlier). It essentially says “where was my collision shape when it registered the hit”, while the impact location says “where did the collision shape hit the object”.
This might be obvious to most of you, but this setup really helped me understand the difference between Hit Location and Impact Location and the next traces will drive this point home.
Trace 1 Impact Normals
Also worth mentioning is the normals of the impact points (yellow cylinders coming out of the yellow spheres).
For box traces the impact normal will always point from object origin of the colliding mesh to the nearest face of the box collision shape. You can see this in the image: the blue and green sphere are just below the box collision shape so from their object origin to the nearest face (which is the bottom face of the box collision shape) is straight up. The red sphere on the other hand has the nearest face be the outer face of the box collision shape (from our view) so it points straight in that direction. I think its best shown in the following gif:
This behavior is differently for sphere collision shapes for example which always point to the center of the sphere collision:
Same for the capsule collision:
The Line Trace Impact normals however would point in the direction of the face thats being hit, something like a reflection:
So regarding the impact normals the TLDR is that the impact normals also depend on the collision shape. Again something that might be obvious to you, but to me as a beginner that was something I did not know. Up until know I always chose the collision shape which can most easily encapsulate the objects I want to trace for, but the impact normals are something to be kept in mind. But let’s go back to comparing one big shape trace vs finer sweeping shapes. Again, something that might be obvious to you, but this was news to me starting off my UE journey.
Trace 2: Small box sweeping from start to end location
For the next trace I did the multi box trace again, but this time with a very thin box, sweeping from start to end position instead. Here is the Trace 2 Setup:
You can see a reference for what would be the collision shape of the thin box on the left side. We will be sweeping a collision box similar to the reference box from start location to end location. Now we get individual hit locations for each time the thin collision box shape has been moved to one step closer to the end location and a hit occurred. This also means the impact normals now differ too, since they correspond to a different hit location and collision shape.
What Unreal does by sweeping from start to end location is essentially move the collision shape specified from start to end and check if a collision occurred after each step. So Image the grey box in the following clip is the collision shape in the trace, what happens is:
Which raised 2 questions for me:
- What happens when an actors object origin is contained within the shape collision similar to Trace 1 (by contained I mean its object origin starts off within the collision shape at the very start of the trace)? Specifically what happens when an actor is contained within the collision shape, but when sweeping the actor(s object origin) leaves the collision shape? Do we get the impact point to be the hit actor location again as in Trace 1 or will it update to the surface as seen in Trace 2 when leaving the collision shape after sweeping another step?
- Which steps does unreal use to move the collision shape from start to finish? Say I specify a collision shape taking up half the space from start to finish, does it trace twice moving the shape by its length or does it move it with a fixed floating point number or integer?
Object Origin starts off within collision shape, but leaves the collision shape after sweeping
For this test setup I first tried increasing the box collision shape and introducing another colored sphere to trace for, the grey sphere. The grey sphere is almost at the exact same location as the purple sphere. What I tried to do here is if Unreal would be moving the collision box by its own size from start to finish I would expect the Hit location and impact point of the purple and grey sphere to be the same. If however Unreal moves the box collision shape by a tiny amount from start to finish, then the hit location and impact point would differ slightly, because the grey and purple have a slightly different location. Here is the result:
We can see that the impact point and hit location differ slightly. This means unreal moves the collision shape with a fixed amount from start location to end location, or in other words it moves it in fine steps from start to end like this:
Instead of moving it in a chunk size of the collision shape (or in this case the box collision) like this:
Which amount does UE move the collision shape at each step?
One question left: how fine detailed does unreal move the collision shape? In other words, how close can objects be in their transforms until we see a change in the trace results, even if only slightly?
For this setup i brought back the grey sphere and placed it closer and closer to the purple sphere until I wouldn’t get any difference in the output log anymore. I got as far as to a 0.000001 difference until the print of the hit location Y would be equal of both colored spheres when tracing. This small floating point number seems to roughly be the accuracy of floating point numbers in Unreal I assume (or rather C++). Which is to say that I couldn’t directly undermine the exact way that Unreal moves the collision shape from start to finish. All I can conclude from this with confidence is that Unreal is able to pickup on even small transform differences. But this information should suffice I think.
So in conclusion, we:
- Looked at the different results and use cases for fine and large collision shapes with and without sweeping
- Looked at the impact normals of different collision shapes
Researching this all helped me solidify my understanding of traces greatly. I really hope someone out there might find this useful too.
Did I miss anything? Do I have an error somewhere? Would love to hear feedback, your thoughts and additions. Thanks!