How expensive is line trace ?

Hi,

Should I be limiting it as much as possible?

I’m using a line trace from a player to look for pickup or movable objects. Instead of running it continuously, all my pickups have a collision sphere which notify when the player is nearby, which then turns on the line trace. If 10 objects are all within the radius it keeps track of them until they are all out of range, and then stops the line trace.

I “suspect” this is a good idea, but having it confirmed would be good, especially since I have to think about selective tracing in combat mode, etc.

Thanks
Stuart

You can have hundreds (or even thousands maybe) traces per tick with minimal performance cost.

But collision shapes, overlaps etc. can get costly really fast from my experience, so if anything try to avoid those :stuck_out_tongue:

Before activating any kind of collision, simple distance checking (player to pickup location calc) should be fast…

I’m trying to the normal vectors of the walls my character is colliding with. Would you recommend that I use the sphere trace for that? if not can you tell me if about more efficient ways to implement this. I’m looking to develop for the switch and I want to squeeze out any performance that I can. Thank you very much

No, this is not true. Line Traces should be used rare in one frame. They can slow down your system pretty easy. Never do 20 of them at the same time.

Sphere Overlaps are the easiest to compute Because the Radius is the only variable apart from the location to check.

A single Line Trace in one Frame is absolutely negligible, though.

Just wondering - have you done any performance analysis regarding this?

Both resolve to PhysX sdk scene queries against an internal culling structure.
In general, the queries are resolved in 3 steps (taken from http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/SceneQueries.html):

  1. Broad phase traverses the global scene spatial partitioning structure to find the candidates for mid and narrow phases.
  2. midphase traverses the triangle mesh and heightfield internal culling structures, to find a smaller subset of the triangles in a mesh reported by the broad phase.
  3. Narrow phase performs exact intersection tests (ray test for raycast() queries, and exact sweep shape tests or overlap tests for sweep() and overlap() queries).

I was under the impression UE can support a relatively large number of queries every tick, and that both the overlap and the raycast are fairly equivalent in terms of performance, although I have not done any specific research yet.

Since a spatial partitioning structure is continually updated with all object positions, resolving scene queries may be very fast.

I am hoping to do a little more research and will post any findings.

So, no consensus on this?

If I remember correctly they did some really heavy linetracing in this Live Training and the conclusion was that line and shape traces impacts are minimal. Check the video at about 42:20 (I may have misunderstood what was said though)

From my own experience, you can definitely do 100 line traces per tick with far above 100 fps.

I think your “overlapping sphere, turns on traces” idea is great. 10 traces is OK.

Note that a line trace is synchronous; your main game thread stops, runs the trace, then returns the data. Because the physics collision data is on the CPU, this genreally is not a large amount of time, but it does eat into your main thread CPU budget if you go overboard. (10 traces is not overboard.)

Meanwhile, the overlap sphere is asynchronous; the physics engine (which may be threaded) notifies the main code asynchronously that overlaps happen, and thus your code doesn’t need to block and wait for the result, it can use take it and run.

I need to make a lot of traces… Is there a way to make an asynchronous multi core version of the line traces? for ex, i could request the traces in pre and get the results in post physics. that would be just fine for my application. Anyone has worked on something like that?

I think async traces are only available in C++,
I don’t know if that changed and now can be used from BPs.

Thanks for the response, I would be fine to do it in cpp… how does that work? does it work on several cores?

After looking at the video, they get pretty massive hits, from 36 000 line traces (almost 300+ ms). They are only doing the traces every 3 seconds but then you can see a big spike. Keep in mind though, that they are using For Loops in BPs, which are not the best comparatively to C++ for loops - here is a comparison for BP For loops vs C++ https://www.youtube.com/watch?v=V707r4bkJOY.

It’s safe to say that 1-10 traces are pretty much not going to affect your performance, but there is nothing wrong with trying to stay performant. Only use continuous traces if you have to. Most of the time you will be able to use a Timer instead of Tick which will also help with performance (especially when it comes to BPs).

Hope this helps.