Is is safe to call "trace" methods from another thread?

Development Programming & Scripting C++
1

Is it safe to call trace functions, like OverlapMultiByObjectType, from another thread (not the game thread)?
I’ve put my traces in an AsyncTask and the speedup is pretty awesome, but is that safe or I’m just being lucky?

2

No, you have to use the AsyncPhysics interface, for example “UWorld::AsyncLineTraceByChannel()”:

3

Could you please explain a little bit? I looked in the source and it seems it’s a FPhysicsInterface call executed inside an async task plus some threadsafe communication.

4

They return safe struct copy containing data from the alien thread.
Normal functions might return pointers to world elements or delegates and so they run in game thread.

5

You mean the normal function, like OverlapMultiByObjectType, can return pointers to Components that are not in the same World? I do many traces but only return one component back to the game thread.

edit: i mean, I just give some actors to the task, do some traces and calculation in the task, then give back a component. They are all supposed to be in the same world. So, if the communication between threads is okay, the trace itself is is tread-safe?

Let’s say the task and the game thread are not communicating, the task runs traces and print numbers on the log. Is that safe?

6

While i’m still looking for answer, it’s worth mention that this suggestion doesn’t seems correct now. I’m on 5.3 and UWorld::AsyncLineTraceByChannel calls the StartNewTrace that has a guard against threading at the very begining:

		// Using async traces outside of the game thread can cause memory corruption
		check(IsInGameThread());

upd:
ActiveSound.cpp Have an interesting comment at the line 1220

				if (UWorld* WorldPtr = World.Get())
				{
					// LineTraceTestByChannel is generally threadsafe, but there is a very narrow race condition here
					// if World goes invalid before the scene lock and queries begin.
					bIsOccluded = WorldPtr->LineTraceTestByChannel(SoundLocation, ListenerLocation, OcclusionTraceChannel, Params);
				}

So it seems default traces is a way to go now. At least they seems to work at the first glance.
Also there is a topic with an engine fix that seems relevant to the problem, but i’m don’t need it yet.