Apply Resimulation to Chaos Moudular Vehicle

Hello Epic Games Support,

I’m currently testing multiplayer using the Chaos Modular Vehicle system in Unreal Engine 5.5, and I’ve encountered an issue where the positions of vehicles between the server and client are not synchronized properly.

I’ve enabled both “Physics Prediction” and “Capture Physics History” in the physics settings during testing, but the location mismatch between server and client still persists.Could you please advise if there are additional settings or steps required to ensure proper synchronization of vehicle positions in a multiplayer environment when using Chaos Modular vehicles?

Thank you for your support.

[Attachment Removed]

재현 방법
Play as multiplayer in Chaos Modular Vehicle Sample(FlatTestLevel_Basic)

[Attachment Removed]

Hello [mention removed]​

Thank you for reaching out.

Have you tried enabling Async Physics?

I believe this is also a requirement for Physics Prediction.

Let me know.

All the best,

[mention removed]​

[Attachment Removed]

Thank you for the suggestion.

Just to clarify first — when you mentioned enabling Async Physics, are you referring to the bTickPhysicsAsync option in the Physics Settings?

I have already tested with the following Physics Settings enabled:

  • bEnablePhysicsPrediction
  • bEnablePhysicsHistoryCapture
  • bTickPhysicsAsync

The test was performed using the FlatTestLevel_Basic example map, without any modifications, with two vehicles being manually driven via player input.

However, even with these options enabled, I am still frequently observing server–client desynchronization, particularly when:

  • Multiple vehicles are moving at the same time
  • Vehicle-to-vehicle collisions occur

In these situations, the server and client positions diverge noticeably.

This leads me to a few questions regarding physics replication using resimulation:

  1. When using the resimulation-based physics replication mode, is any additional setup or handling required beyond enabling the physics prediction–related settings?
  2. Unlike the default physics replication mode or interpolation modes that perform hard snaps to the server state, is there no mechanism that forcibly corrects the client transform to the server transform in resimulation mode?
  3. If server–client error accumulates, where in the engine is this error expected to be resolved or corrected?
  • Is there an intended reconciliation or correction path that I might be missing?

At the moment, it is unclear to me how positional drift is expected to be resolved when prediction diverges, particularly during collisions.

Any clarification on the intended behavior or recommended setup would be greatly appreciated.

[Attachment Removed]

Hello [mention removed]​

Yes, indeed I meant bTickPhysicsAsync, sorry for not being clear.

On the FlatTestLevel_Basic, from the ChaosModularVehiclesExamples plugin, the default spawned car is the ModularSkeletalMeshAnimated Blueprint, so the following relates to that BP:

Indeed, with the default settings, it’s easy to replicate the behavior you mentioned about vehicle collision, once two cars collide they usually become undrivable.

On Replication, the default is Resimulation (WIP), let me know if you changed that.

During my tests I had better results by disabling Class Defaults>Cluster Union>Enable Damage From Collision.

So, answering your questions:

1. In my tests, enabling those 3 flags plus making sure the Pawn is using PhysicsReplicationMode = Resimulation (WIP) were the requirements. Disabling the DamageFromCollision made the simulation work well with two players even after collision.

2, 3, 3.a : The official documentation goes into some detail:

When the client receives state information from the server, it compares them with the cached physics state in its history for the corresponding physics frame. If the state information differs enough, it triggers a physics resimulation.
 
A resimulation is done by rewinding the physics simulation back to the cached history state, correcting the errors based on incoming server states, and then simulating physics again up until the current physics tick.
 
At the end of a resimulation, an object might be at a different state than before the resimulation, which could cause snapping of the object’s position. In this case, the mode interpolates the rendering of the object from its current state to the new state.

I suggest you check \Engine\Source\Runtime\Engine\Public\Physics\NetworkPhysicsComponent.h for more info, as well as \Engine\Source\Runtime\Experimental\Chaos\Public\RewindData.h.

Some console commands can be verified on np2.Resim and p.Resim.

Let me know if this info is useful.

All the best,

[mention removed]​

[Attachment Removed]

Even after testing with Enable Damage From Collision disabled and Physics Replication Mode set to Resimulation, we are still frequently observing server–client mismatches, especially during vehicle collisions.

During testing, we noticed that when the server and client positions diverge beyond a certain point, a sudden rewind/resimulation seems to occur, which visually appears as a teleport or snap. We would like to understand what controls the cadence or conditions of these corrections — specifically, what determines when a rewind happens and how often the state is forcibly corrected.

To give some background on our Chaos Vehicle development history:

we initially developed our vehicle gameplay using Interpolation or Default physics replication modes. In dedicated server environments, however, we frequently encountered rollback-like behavior, where vehicles appear to rewind or snap back. We are currently investigating how such rollback behavior can be reduced or eliminated.

While we understand that optimizing both the dedicated server and client performance is the first priority, we are particularly interested in whether there are Chaos Vehicle–level mechanisms that can help maintain synchronization when transient events occur — for example, when the game thread experiences a brief hitch or spike due to a specific gameplay event.

We have additionally tested enabling physics-related options such as physics sub-stepping, with the intent of increasing simulation frequency and stability. Although this provided minor improvements, it did not fully prevent rollback behavior.

Given these results, we would like to ask more fundamentally:

in a multiplayer environment, what are the root causes of Chaos Vehicle rollback, and are there any known or recommended approaches to mitigate or prevent this behavior? Or is a certain level of rollback currently unavoidable due to the underlying replication architecture?

Any clarification on the underlying causes, limitations, or best practices would be greatly appreciated.

[Attachment Removed]

Hello [mention removed]​

Thank you for the reply and for sharing some context of your development.

If I undestood correctly, you are trying ChaosModularVehicle (CMV) as a possible solution to the issues you have encountered before.

If that’s the case, I would like to mention that this plugin is marked as Experimental, so Epic does not recommend its use in shipping products.

It’s not in a “ready for production” state, and subsequent versions might break or even be removed without notice.

Regarding the issues you are facing while using CMV, I’ve tried to replicate the behavior you are seeing in a local setup, but I could not see a lot of rollback.

I’m probably missing some key steps here.

Could you elaborate a bit more on the steps to replicate this issue?

A minimal project that reproduces the behavior is the best way to exemplify an issue, so if you have the capacity, that would be great.

Having a project that reproduces the issue you are seeing would also allow me to iterate on the matter and try solutions.

Even a video showing the behavior would be great, so I know what to look out for.

About the conditions to the corrections, have you tried tweaking ProjectSettings>Engine>Physics>Default Resimulation Replication Settings?

AFAIK the basic flow is described in the link I shared before: client forward predicts locally -> client caches the physics state history -> server state arrives and the client compares -> if it differs enough, a physics resimulation is triggered -> the resimulation is done by rewinding the cached history state and simulating again -> the end result could cause snapping of the object’s position, so there’s interpolation of the rendering representation of the object from the current to the new state.

Answering your question, I believe some rollback is unavoidable, but how much is acceptable is highly dependent on the requirements of your particular project.

Let me know if this helps you in any way, and if you are able to provide a repro project or more information.

All the best,

[mention removed]​

[Attachment Removed]