p.AsyncPhysicsBlockMode

p.AsyncPhysicsBlockMode

#Overview

name: p.AsyncPhysicsBlockMode

This variable is created as a Console Variable (cvar).

• type: Var
• help: Setting to 0 blocks on any physics steps generated from past GT Frames, and blocks on none of the tasks from current frame. 1 blocks on everything except the single most recent task (including tasks from current frame). 1 should gurantee we will always have a future output for interpolation from 2 frames in the past. 2 doesn\'t block the game thread, physics steps could be eventually be dropped if taking too much time.

It is referenced in 3 C++ source files.

#Summary

#Usage in the C++ source code

The purpose of p.AsyncPhysicsBlockMode is to control how the physics simulation interacts with the game thread in Unreal Engine 5’s Chaos physics system. It determines the blocking behavior of asynchronous physics calculations, which affects the balance between physics accuracy and game performance.

This setting variable is primarily used by the Chaos physics system, which is part of Unreal Engine’s experimental physics framework. It is referenced in the PhysicsSolverBase class, which is a core component of the Chaos physics simulation.

The value of this variable is set through a console variable (CVar) named “p.AsyncPhysicsBlockMode”. It can be changed at runtime using console commands or through configuration files.

The AsyncPhysicsBlockMode variable interacts directly with p.AsyncPhysicsBlockMode, as they share the same value. This variable is used to initialize the AsyncBlockMode member of the FPhysicsSolverBase class.

Developers must be aware that this variable has three possible values, each with different implications: 0: Blocks on physics steps from past game thread frames, but not on tasks from the current frame. 1: Blocks on all tasks except the most recent one, ensuring interpolation data is available. 2: Doesn’t block the game thread, potentially allowing physics steps to be dropped if they take too long.

Best practices when using this variable include:

1. Consider the trade-offs between physics accuracy and game performance when choosing a value.
2. Use value 1 if consistent physics interpolation is crucial for your game.
3. Use value 2 for better performance, but be prepared to handle potential physics step drops.
4. Monitor performance and adjust the value as needed based on your game’s requirements.

Regarding the associated variable AsyncPhysicsBlockMode: This is an integer variable that directly corresponds to p.AsyncPhysicsBlockMode. It’s used internally in the PhysicsSolverBase to store the current blocking mode. The best practices and considerations for p.AsyncPhysicsBlockMode apply equally to AsyncPhysicsBlockMode, as they represent the same concept within the physics system.

#References in C++ code

#Callsites

This variable is referenced in the following C++ source code:

#Loc: <Workspace>/Engine/Source/Runtime/Experimental/Chaos/Private/Chaos/Framework/PhysicsSolverBase.cpp:215

Scope (from outer to inner):

file
namespace    Chaos

Source code excerpt:

	// 2 doesn't block the game thread. Physics steps could be eventually be dropped if taking too much time.
	int32 AsyncPhysicsBlockMode = 0;
	FAutoConsoleVariableRef CVarAsyncPhysicsBlockMode(TEXT("p.AsyncPhysicsBlockMode"), AsyncPhysicsBlockMode, TEXT("Setting to 0 blocks on any physics steps generated from past GT Frames, and blocks on none of the tasks from current frame."
		" 1 blocks on everything except the single most recent task (including tasks from current frame). 1 should gurantee we will always have a future output for interpolation from 2 frames in the past."
		" 2 doesn't block the game thread, physics steps could be eventually be dropped if taking too much time."), LambdaAsyncMode);

	FPhysicsSolverBase::FPhysicsSolverBase(const EMultiBufferMode BufferingModeIn,const EThreadingModeTemp InThreadingMode,UObject* InOwner, Chaos::FReal InAsyncDt)
		: BufferMode(BufferingModeIn)
		, ThreadingMode(!!GSingleThreadedPhysics ? EThreadingModeTemp::SingleThread : InThreadingMode)

#Associated Variable and Callsites

This variable is associated with another variable named AsyncPhysicsBlockMode. They share the same value. See the following C++ source code.

#Loc: <Workspace>/Engine/Source/Runtime/Experimental/Chaos/Private/Chaos/Framework/PhysicsSolverBase.cpp:214

Scope (from outer to inner):

file
namespace    Chaos

Source code excerpt:

	// 1 should guarantee we will always have a future output for interpolation from 2 frames in the past
	// 2 doesn't block the game thread. Physics steps could be eventually be dropped if taking too much time.
	int32 AsyncPhysicsBlockMode = 0;
	FAutoConsoleVariableRef CVarAsyncPhysicsBlockMode(TEXT("p.AsyncPhysicsBlockMode"), AsyncPhysicsBlockMode, TEXT("Setting to 0 blocks on any physics steps generated from past GT Frames, and blocks on none of the tasks from current frame."
		" 1 blocks on everything except the single most recent task (including tasks from current frame). 1 should gurantee we will always have a future output for interpolation from 2 frames in the past."
		" 2 doesn't block the game thread, physics steps could be eventually be dropped if taking too much time."), LambdaAsyncMode);

	FPhysicsSolverBase::FPhysicsSolverBase(const EMultiBufferMode BufferingModeIn,const EThreadingModeTemp InThreadingMode,UObject* InOwner, Chaos::FReal InAsyncDt)
		: BufferMode(BufferingModeIn)
		, ThreadingMode(!!GSingleThreadedPhysics ? EThreadingModeTemp::SingleThread : InThreadingMode)

#Loc: <Workspace>/Engine/Source/Runtime/Experimental/Chaos/Private/Chaos/Framework/PhysicsSolverBase.cpp:239

Scope (from outer to inner):

file
namespace    Chaos
function     FPhysicsSolverBase::FPhysicsSolverBase

Source code excerpt:

		, MMaxSubSteps(1)
		, ExternalSteps(0)
		, AsyncBlockMode(EAsyncBlockMode(AsyncPhysicsBlockMode))
		, AsyncMultiplier(AsyncInterpolationMultiplier)
#if !UE_BUILD_SHIPPING
		, bStealAdvanceTasksForTesting(false)
#endif
	{
		UE_LOG(LogChaos, Verbose, TEXT("FPhysicsSolverBase::AsyncDt:%f"), IsUsingAsyncResults() ? AsyncDt : -1);