pour suivre j’ai aussi des problemes de saccades.
I tried it, but it didn’t fix my stuttering problem.
Then maybe its not true that the prediction is the issue.
Did someone record physics with chaos visual debugger if it also shows the jitters?
I think I have a problem with my Geometry Collections.
In the first video, you can see stuttering with my Geometry Collections.
In the second video, I simply replaced the body Geometry Collection with the one from a Chaos Modular example. You can see that the wheels are stuttering, but the body is not.
In the third video, you can see that the rendering does not follow the collision properly, as if there were a delay (spring arm).
In the end, I found the difference.
I had already tried setting “Custom Renderer Type” to “None”, but I did it in the Geometry Collection Components, not directly in the Geometry Collections, which didn’t fix the problem.
Setting “Custom Renderer Type” to “None” directly on the Geometry Collection greatly reduced the stuttering. There are still a few occasional ones, but it’s much better now.
Renderers
1 Like
What about async interpolation, did anyone try tuning p.AsyncInterpolationMultiplier or p.AsyncPhysicsBlockMode ?
Didn’t try it but
CHAOS_API FRealSingle AsyncInterpolationMultiplier = 2.f;
FAutoConsoleVariableRef CVarAsyncInterpolationMultiplier(TEXT("p.AsyncInterpolationMultiplier"), AsyncInterpolationMultiplier, TEXT("How many multiples of the fixed dt should we look behind for interpolation"), LambdaMul);
// 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 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."
So I a little bit look around analyse try to understand and honestly I learned something nice today cause of this question, so thanks for that @szefopl
What I think happening is in plain words:
1- When we enable async physics and resimulation, the phsyics thread creates a buffer. It doesn’t exactly show the actual physics step, instead it shows a bit from past time.
2-While physics solver doing this its also calculating the current/future frames upcoming. At this very moment during the engine step AsyncInterpolationMultiplier defines how much back should look back frames. In a sense how big is the buffer zone is.
3-Without this variable phsyics engine simply would try to show the actual step creating visual artifacts, jitter. Decreasing this in a sense create more up to date phsyics viewmodel, on the other hand increasing the buffer also enables much more smoother results.
4- If chaos doesn’t have a future frame in a sense (buffer) there is nothing to interpolate to thus jjittering and stalls can happen.
5- CVarAsyncPhysicsBlockMode think it defines how the game thread should behave during this interpolation of buffer. Not super sure about this but feels like during buffer , wait if no data, block till there is data OR don’t block. I didn’t try but think 0 , 1 is the most meaningfull over here.
However I would like to know if you experimented with it, think this is one the core aspects of the async physics logic and to be honest very smart way of approaching the problem.
Hey! It’s really nice to see people like you (not a newbie like me) analyzing and getting inside of the simulation core, helping others to understand what and why in CMV and giving an explanation of the behaviors that I never understood before. Thanks for share all this information 
I just checked the ue5-main branch to see the new additions to CMV and few hours ago they added this:
# Commit ef2300b
Modular vehicle : Can setup vehicle using only static meshes or skeletal meshes without needing cluster unions (or geometry collections). The existing setups still exist/work.
#jira UE-294456
#rb markus.boberg, tom.waterson
#Synced-CL 51943232
[CL 52096220 by bill henderson in ue5-main branch]
1 Like
Thanks a lot, it’s win for me too so I enjoy it especially subjects around physics, interaction, gameplay 
Just natural curiosity let’s say and it takes quite a time to digest all physics side so I am taking these as opportunities.
That’s actually great news, I need to make some time to get latest changes and rebuild but that would be a nice addition overall to the system potentially unlocking us to do more stuff.
1 Like
yeah its funny to use p.AsyncInterpolationMultiplier
u can set the async physics to like 5 fps and then set interpolation to 0 disabling it
and watch how physics bodies jump 5 times a second
the # Commit ef2300b is interesting, but there was more changes, so i cant check it in 5.7, only the skeletal pawn can be added here
Hey guys, I’m new to CMV. It seems really interesting to me, but I have a Chaos Vehicle system already in place and would like to improve it with the CMV Clutch system, i read about. Do you think it makes sense for me to switch to CMV, when I only need the Clutch and destruction system for now? Or is it possible to use the clutch logic only from CMV in my Chaos Vehicle setup, since both can be used in parallel according to docs?
@cem_ck Hi there, I don’t think CMV done done at the moment, it is still in active development and think it would take for a while, for just clutch, I don’t think you really need it at the moment especially if your product is in active development as well.
Building the cart while train is moving is not the best idea or you have to take responsibility that it can break. However at the same time as I see clutch module is fairly done in CMV depending on the child modules speed so there is no big dependency overall specifically for clutch module. That can give you some space to make a decision.
However even from the core engine module a clutch is
void FClutchSimModule::Simulate(float DeltaTime, const FAllInputs& Inputs, FSimModuleTree& VehicleModuleSystem)
{
//FTorqueSimModule* Parent = static_cast<FTorqueSimModule*>(GetParent());
//FTorqueSimModule* Child = static_cast<FTorqueSimModule*>(GetFirstChild());
//float EngineSpeed = Parent->GetAngularVelocity();
//float TransmissionSpeed = Child->GetAngularVelocity();
//// difference in speed between the two plates
//float AngularVelocityDifference = EngineSpeed - TransmissionSpeed;
// Inputs.Clutch 0 is engaged/locked, 1 is depressed/open
ClutchValue = (1.0f - Inputs.GetControls().GetMagnitude(ClutchControlName)) * Setup().ClutchStrength;
FTorqueSimModule* Parent = static_cast<FTorqueSimModule*>(GetParent());
FTorqueSimModule* Child = static_cast<FTorqueSimModule*>(GetFirstChild());
if (Parent && Child)
{
float EngineSpeed = Parent->GetAngularVelocity();
float TransmissionSpeed = Child->GetAngularVelocity();
// difference in speed between the two plates
float AngularVelocityDifference = EngineSpeed - TransmissionSpeed;
Parent->AddAngularVelocity(-AngularVelocityDifference * 0.1f);
Child->AddAngularVelocity(AngularVelocityDifference * 0.1f);
float BrakeTorque = 0.0f;
TransmitTorque(VehicleModuleSystem, DriveTorque, BrakeTorque, 1.0f, ClutchValue);
}
}
As we can see it gets the first child , they look the delta difference between the angular velocities (slip) and make addition/substraction to angular velocities (even it’s hardcoded so there is no clutch effectiveness at the moment)
Parent->AddAngularVelocity(-AngularVelocityDifference * 0.1f);
Child->AddAngularVelocity(AngularVelocityDifference * 0.1f);
You can do same system for any vehicle in any system. Think Epic when time is right will add some stuff over here aswell since this is not a super nice clutch at the current state but more likely a spring constraint without spring.
I would possibly add some parameters as,
A Clutch Curve : Defining its effectiveness on press how much it try propagate energy.
A Clutch Friction : Defining how much force it generates at the very moment.
A Scalar Multiplier for Mass : Defining how much parent and child masses considered during the clutch solve. Since sometimes as gameplay we would want to neglect portion of the parent/child mass. This can be default 1 and this would be a quality of life variable.
Some Limiters : Maybe some max clutch force limiters can be nice over here not exceeding total torque on parent body because without limits it can achieve full authority so better have those by design.
Edit : At a second thought since changing the model over here with these thoughts, adding a very brief state machine (Free, Partial, Locked) over here would make sense and it would be a more elegant model.
Think wouldn’t be adding more besides this like energy conservation etc. since would be too specific at least in my opinion. With these it would be possible to mimic a realistic behaviour in clutch putting inertial forces on the parent body (car) like engine stall.
Let us know if this is good enough insights around it.
just starting with this, i have the stuff ticked in the plug-ins but is there any “actual examples” of modular vehicles “pre-built by Epic” or are we just going in blind, and yes i’ve already found the doc pages.
Thanks in advance
Hi Geodav, you have to enable the plugin: Chaos Modular Vehicle Examples, and search for it in engine folder - plugins - experimental - chaos modular vehicle examples.
Try it and let us know if you found it 
1 Like
Thanks for the tip @than_sad just what i need to get back into things
1 Like