Chaos Modular Vehicles Settings Examples

[than_sad]

Another example is wheels thickness doesn’t effect anything atm, also that really effects the lateral slipping which should have a graph thats not implemented yet. I did that since I had a problem in lateral slips of vehicle in super low speeds and very high torques. Like the example of the loader truck (super powerful but very slow and heavy) .

I have this problem too, due to the wheel center location of the bone, when the car is rotated the wheel goes inside the ground. A s a workaround I’m thinking in to move the wheels bones to the exterior of the wheel instead of the center.

I also use bones for Steering wheel rotation and speedometer and RPM in the car dashboard. It was easier than expected to implement.

[RedGrimnir (Grimnir)]

Thats interesting actually didn’t see that in examples or in my pawn vehicles since they are generally slow industrial machines. I had problems with the “turn in place” and turn arcs simply thats why implemented those, lateral graph helps still game changer was not to have a 4X4 wheel drive.

Think those industrial heavy machines 4x4 steer also not sure.

This sinking I suspect its a visual animation problem more likely than behaviour but can be due to hard limits on suspension is reached + its a very hard turn so it literally sinks to ground. Not sure will try to replicate this. This is actually a nice thing since normally during these kind of turns, inner and outer edges of the wheels gets the forces and pressure. This aspect of forces are also tend to create a natural anti roll movement since the area of the force distribution is wider on each front back axis.
On the image, during the turn FR wheel outer edge and FL wheels again outer edge but less should be the offset of turning forces. Since there is one raycast without writing the entire code block I think its possible to add virtual offsets. I can just get width, calculate the lateral force and move the offset with a coefficient to that side, maybe coefficient of total mass. It’s like a dynamic offset depending on the total inertia. First I have to replicate it though

Can you tell me the map name you mentioned btw ? Either I am checking wrong ones or my engine is not updated properly from branch.

[than_sad]

Here. Remember, the path is from engine, not from content.

[than_sad]

@RedGrimnir

On the image, during the turn FR wheel outer edge and FL wheels again outer edge but less should be the offset of turning forces. Since there is one raycast without writing the entire code block I think its possible to add virtual offsets. I can just get width, calculate the lateral force and move the offset with a coefficient to that side, maybe coefficient of total mass. It’s like a dynamic offset depending on the total inertia. First I have to replicate it though

I verified it trying to drive the car in two wheels, and CMV consider the end of the physcal wheel, the position of the wheel bone. If the wheel bone is in the middle of the wheel, all the outside will be ignored for collisions and forces. I also noticed that driving the car in two wheels, the throttle dissapears, making the wheel rotate but not transfer any force, forcing the car to reduce speed and lost the posibility to retain the two wheels driving position.

Thinking about it, my conclusion is that due to the not implemented thickness, the wheel in CMV is like a disc, not like a cylinder. Reducing the physics calculations but producing this behavior.
About the throttle disabled on two wheel driving, after saw the bTouchingGround=1 in ShowDebug ModularVehicle for every wheel. An explanation for this behavior can be that CMV disable the throttle if one or more wheels have btouchingGround=0. I’ll try and check it again, paying attention to the ShowDebug ModularVehicle data.

[RedGrimnir (Grimnir)]

Allrigh I swtiched to main branch seems its over there. Makes sense to be on the main branch for me anyway so was quite a work to build my dev environment but its ok, thats how it goes

However in main things tend to change rapidly and since this is still in heavy development, numbers, behaviours, setup aspects and many things can change. In my setups didn’t see any hard behaviour changes, just reconfigure some numbers, some behaviour adjustments. That being said still there is a lot of changes as mentioned how suspension behaves.

So I can see many reasons that this is happening on your side. Since you said you also have a skeletal mesh be sure that your tire size and the skeletal mesh physics assets are correct.

However the main issue relies on the engine atm. and it was fairly easy to replicate. What is happenning at the moment with the wheel?

• Each time phsyics step a raycast is made from the wheels from suspension to the SuspensionMaxDrop + Wheel Radius. Simply after this when there is a contact the forces applied on the wheels relative to the contact point.
• This is so far so good however when a wheel is leaning and turning it never considers the lean aspects and the width of the feel thus the contact point. It always considers the local wheel axis which is default 0,0,-1 and at this moment because of the leans of the actual body the point of contact either streches or compresses depending on the suspension and wheel. This aspect can make the wheels dip into the ground a bit.

Solution

• So in order to solve this simply we can calculate the mainbody lean vs world down + pass another variable (WheelWidth) to compansate the locationStart/End of trace to the edges of the wheel.
• When leans left a WheelWidth/2 to the left and vice versa. This trace compansation solves the problem as demonstrated below. I used some large values to show the behaviour differences.
• I will do some more changes on it to actually coralate slip angle (or another variable) to properly propagate WheelWidth compansations to the edges depending on how much wheel leans and how much designer wants it do push to the wheel edges. Since when you think about it not every wheel would be a sports car wheel, there could be machinery tires , stagecoach tires , huge mining tires or rounded motorcycle. Cause of their geometries current setup would behave nicely on a motorcycle tire but not so very good on a sports car tire.
• This is actually something nice since this creates an additional anti roll on the vehicles, it correctly actually simulates the vehicles mass changes from wheel to wheel and natural inert of the cars/vehicles.

In first one wheel width is 0 in the second PIE its like 200 to show difference.

So I think I will maybe keep trace start locked in to the suspension but just change the end location, this would behave slightly different since force application will be same however suspension compressions would be different at that moment. Think Epic devs would already do this, maybe this way or maybe another approach, however if I feel good about the change maybe can create a pull request to have some salt in the soup.

[RedGrimnir (Grimnir)]

Also in addition to offsetting that explained above, if we use an exact match of tire geometry collection , with a capsule that is kinda matching the profile of the wheel.

and use the collision from the source in GC, just make the wheel component radius +1 bigger

Than actually when we observe the wheel contact points behaving very nice with the engine changes especially with moderate spring rates.

Think over here the collision already doing the job preventing dip into ground however the changes of offset in raycast is also helping. There is also an option in the vehicle compnent either use raycast or sphere cast. Sphere cast can be unreliable sometimes hitting edges however think raycast + wheelwidth consideration does a good job with proper GC collection creation.

It generally gives a nice smooth drifting drive on modarate surfaces while you kinda feel the inertia change of car during turns and drifts.

[than_sad]

Hi, I recovered and old version with Unreal 5.6 from the time before I added the skeletal mesh, and modifying some setting, specially the one I commented you before

Changing it to None, as I saw in ue5-main they disabled it. And finally I got a smooth camera and car movements, the same as using the skeletal mesh. But when a car part is broken or near to beak, strange “anticipation crash” happens, making the phisycs do strange mix of past-future behaviours.

After read your mesaages about the use of sockets I’m going to remade the car, trying to understand as much as posible in every step forward. The AI suggested my to use the skeletal mesh as a parts anchors to break the bone on impact and showing the physics instead of the animation.

But I just updated Unreal to 5.7.3 and realized that again the spring Rate changed a lot making my car behave like have no suspension at all (Like the car is 10 times more heavy). Forcing me to change spring rato from 20 to 400 to recover back the funtionality.

From Unreal 5.6 to Unreal 5.7 I noticed the oposit effect, my car was completely rigid in suspension, forcing me to reduce drastically the spring rate. Looks like they returned back to the 5.6 behavior…

Have you updated to Unreal 5.7.3? Have you notyfied any behavior change in you CMV?

[RedGrimnir (Grimnir)]

Hi there,

Yeah I am on main branch atm, it writes 5.8 generally I update every 1 - 2 days depending on my schedule of time available, since it takes a bit time to rebuild.

So short answer is Yes, I felt some changes and saw some changes and as it should be since this is being developed, its nature is that. I generally felt some suspension changes like you said and these were generally fixed by playing with some numbers.

Additionally this changes can come from many places, suspension component not being touched doesn’t necessaryly means that it would behave the same. Since the rates can change, suspension and wheels components is at the moment in the code base are hand to hand on phsyics tick depending on some conditions. Also simpy anything in Substepping / async physics tick would change some behaviours in addition to tensors, spring rates and so on.

I sent a CL regarding the wheels dipping and wheel behaviour change that considers the wheel width, lean factor and accumulates suspension ray traces to opposite direction (to the edges of the wheel), since wheel width has many things to be implemented (Friction, SlipGraph, Also maybe contact surface detection but think that would be too specific) maybe this CL get implemented already before my request, or maybe gets implemented some other way or maybe can be rejected to maintain unification of behaviours neglecting this as a bug or improvement. It’s a trade off, right now designer can control it and generally an improvement. it’s here

So didn’t know or tried the custom renderer types but will.Custom Renderer Type that explains the smooth camera and motion. The proxy renderer path can introduce interpolation artifacts with async physics. Removing it forces direct transform usage from solver would feel better imo.

The “anticipation crash” this also sometimes can happen, I saw in my wrecking ball on network. It’s like the breaking threshold almost reached, the links are about to brake but didn’t so it can feel like its from future and rewinded back, but think its not about the rewind its just about the constraints imo. Ofcourse this is a bit gut feeling.

Besides I am generally over stabilization and testing some high speed stuff on PODs, also invented a new turn control with the chasis model. I was able to change the simulation variables on runtime in vehicle chasis with input from client. That gave me some cool stuff like air brakes at the moment playing with that before moving a bit more forward to dynamic suspensions and some assist layers with respect to pods chaotic nature but so far so good tbh, I was able to achieve 800+ kmph speeds without any casulties on quite rugged surfaces and almost the same behaviours in the multiplayer (local). Sebulba gets stronger.

Sebulba Pod Racer | Dev Log 001 : Speed Scaling Test - UE Multi-Body Physics Simulation

This is the chasis changes I did for runtime changes https://github.com/EpicGames/UnrealEngine/commit/7ee605df5f7201b114eac2d331d34264493a374d

Probably its not the best approach to it but it works surprisingly well at the moment.

[than_sad]

Hey!!! I’m so happy to tell you that after four months without use the 30 GC with fracture of my car due to I was unable to use SKM and fracture togueter. Today and after two days with the help of AURA AI and with the google AI. Teeling to her to go in the way of use sockets as you mention in your messages. Finally i understood how it works and I have a SKM with the full car, and the four wheels (for now) breaking and flying around after break!!!

Four months for this… that can be explained in one Fuc…ing line by Epic in the quick start guide.

Going to preapre the full car parts and take a cool video to share with you.

[RedGrimnir (Grimnir)]

That’s great. Think in a car this is the way to go.

BreakEvent->Detach Component-> Hide SKM->Simulate does rest.

This is totally fair, and would ofcourse give more visual control, broken parts can have different aspects visually. A different texture, changed deforming etc. In AAA scenario this is generally how it is, sometimes even have their distinctive meshes on “Destructed State”.

Can we do vice versa? Probably.

BreakEvent->Detach Component (or Destroy) → Show SKM Bone-> Simulate Bone->BreakConstraint

or

BreakEvent->Detach Component (or Destroy) → Hide SKM Bone-> Spawn Specific SM simulated

These are all possible scenarios (maybe more) to destroy a vehicle. Some of them long standing methods.

However what if we really want to have chaos the way it is. Like really granular debris without faking it and so on this is the way to go.

I will make a new collection with some bones, to remove outer shell of the ThrusterEngines without too much effecting stability but penalty for player to a certain degree. Think its doable, I am just not sure if the chaos editor tool flexible enough to achieve what designer wants.

Will deal with suspension and a horizontal PID controller to my vehicle but before that can test a fracture.

Edit :
This would help Artist creating a single mesh for vehicle but detached parts so those can be auto new bones.

[than_sad]

Again thank you so much for all the information you share. Thanks to that I achieved one of my biggest problems using CMV.

Now with this problem fixed I’m going to rebuild the car from the 3D Max model to fix mesh topology, fix wrong shading groups, and giving shell to the body work to prevent fractures like solid parts, like the front and rear bumper. Also changing the Automotive materials for the Substrate automotive materials. I can’t wait to start it!!!

I’m also thinking it to apply tire deformation and I’m not sure whats the best aproach. The best I saw was in the Electric dreams demo: Electric Dreams - Tire Deformation | Tutorial But I also read from the AI to use another way that I don’t remeber now. Whats your opinion? Electric dreams is the way?

Best regards, Than.

[RedGrimnir (Grimnir)]

My pleasure, did nothing to be honest, atleast from my perspective but if it was helpfull somewhat, thats great!

I never used Electric Dreams or did that tutorial, which is a great method to do things creating a very big visual fidelity with cost of cpu/gpu. Don’t want to misdirect you about it since have no idea what it uses in the background to manipulate vertices on gpu. It uses a simplfied representative, o tire mesh, uses render target to project niagara vertices and reposition them on gpu level seems to be at a glance (I just briefly skimmed), is it worth it on a car? not so sure tbh, however jiggly physics or animations are always welcome

So about fracture would be great if you share your progress as well. I am skeptical about fracture show but SKM hide way of doing it on my side but we will see. Since I think it would create quite a work to resolve fracture bone clusters to main skm bones but could work though so we will see.

[newwdles]

Hello, thanks to the both of you for sharing all that infos, very precious.

I was also having the same camera jitter @than_sad , changed the custom renderer type to None but i was still having the same issue.

Turn out you also have to enable “force update active transforms” on your GC (spent a lot of hour on this one).

[than_sad]

Hey @newwdles thanks for apreciate it and welcome to epic forums.

When you change the render type to NONE in all GC car parts except one with GeometryCollectionRootProxyRenderer, you should see how that GC goes faster than the rest, getting an ofset from the car (the rest of car parts), increasing with the speed.

But the key is, are you using SKM to handle the animation or just pure GC? Also all the components have diferent Tick Groups, to handle the physics. but I don’t really know and understand it.

Give us more info about your project (share captures or videos would be great!). And we will be able to give you more tips and recomendations.

It’s really nice to see other people using CMV. I felt really alone working with Chaos Modular Vehicle…

Now I got blocked trying to fix parts of the GC to the car, for example the base of the rearviews to let part of it fixed and breaked to the car. But nothing works. Tryied directly in to the GC bones defining to Static or Kinematic I don’t remember now, and neither using anchor field becuase you can’t select it in the component… Be a newby in UInreal is a never ending fight.

[than_sad]

@newwdles

I was also having the same camera jitter @than_sad , changed the custom renderer type to None but i was still having the same issue.

The only way in my case to remove the jitter was using a SKM to handle the animation.

[RedGrimnir (Grimnir)]

Thanks @newwdles Its a lot to digest.

So jittering can come from many things by the way, generally in single player there shouldn’t be a massive jittering, also in multiplayer if hierarcy is generally right, nothing interfering the phsyics externally.

This is my setup with comparison at the moment. Left is a SKM visible Right thruster is pure GC nothing else. Optimised constraints to refect single player and multiplayer feeling almost the same. Ofcourse many things to do more so on it.

However wanted to reply again here about this jittering. Rubberbanding / jittering can be mixed so can be happening from rewind resim of the simulation. However in optimum conditions, shouldn’t be so intense as I observed atleast on my vehicles current state.

Additional jittering can come from other things as well. Like a transform overwrite somewhere or interference from GameTick to physics object (not from async phyiscs tick)

Also as mentioned there is this rendering modes which is mentioned some of the videos by Epic

In the video I am using a RootProxyRenderer

It feels like an optimisation method for rendering load on particles which is good ofcourse possibly with trade offs. @than_sad mentioned this before so today I take a look at it to abit understand what is going on since there is no documents yet and think that would take a long time.

Renderings in GC

1- None : When nothing is used, normally a GC all its complex pieces (if there is) rendered individually even though its not broken, standing still. So depending on the setup these tiny geometries appear to be jittering even sometimes almost broken but not (future past blend). In other words this is the most accurate method, even good for single body GC when it comes to fractured GC collection there can be many visual errors.

2- Root Proxy Render : Seems it creates a proxy mesh, so that rather then rendering everything it renders this big mesh. So doesn’t have to batch process everything. As soon as it needs to break this proxy mesh is hidden and fracture is shown. This is good for single body meshes, large buildings, walls etc. Seems its pretty good on high speed too.

3- ISM Pool Render : This is high performance rendering mode simply if there is many many shared parts (repeated) It groups and renders them together as batch. This would be usefull in large explosions, debris even not core gameplay related objects like a box that sides are similar to each other.

Below video shows rendering differences (visuall) on my machine. Right Thruster again GC, left a regular skeletal mesh on top of GC.

Ofcourse some of the components and features at the moment not allowing me to correctly designate sockets and locations to Niagara + Cable components but when I can (Either modify or wait Epic) then would be great to attach cable component to correct slots directly on GC so we can make really cool destruction and physics setups. Thats why I use skeletal mesh additionally for now.

However it can be with or without SKM. SKM has its own nice positives however distrubuted systems come with their own unique quirks.

[newwdles]

Hi guys,

Sorry for the long silence, i should have received a mail when you replied but nothing

Anyway, i’m using pure GC, i’m more into space ship which are very simple to animate (plus i want to keep things simple until i have the basic gameplay ready)

Here’s my hierarchy for the moment :

I have create a subclass of AModularVehicleClusterPawn to tweak a little bit how thrusters work, and since enabling “force update active transforms” everything was real smooth.

That is, until i tried multiplayer As the doc says “This system was designed from the ground up to support the resimulation network physics model” i setup my ship to use the resimulation, and noticed occasional stuttering.

Using the debugging tools mentionned here i quickly realised that the stutter i was seeing were because of resimulation. A resimulation should not be visible to the client, when the simulation differs too much with the server the resimulation is triggered and the result is interpolated smoothly into the current position.

However, the stuttering i have is not caused by the result of the resimulation, but the initial rewind.

In Source/Runtime/Experimental/Chaos/Private/PBDRigidsSolver.cpp l2357 there is a condition to not update SingleParticleProxy (if (!bIsResim), the code is different for UnionCluster and this condition is missing. I’m not 100% sure but this look suspicious.

Here’s the result :

I posted here [Chaos modular vehicle] Stuttering whis resimulation to check if someone else have this issue.

As soon as the performance of the server or the client start to degrade there is a lot of resimulation so this is not acceptable for a competitive multiplayer game.

I will give a try to add the condition in the engine (if i manage to compile it) but the code is quite complicated so i may simply switch to predictive interpolation.

Still, i feel like i missed something because the CMV is supposed to be build for resimulation and this simple case doesn’t work properly.

[RedGrimnir (Grimnir)]

Thats a great and very strong observation! Have you tried it?

I wrapped those solver parts with that bool or hard resim (I beleive I did it correctly and in multiplayer there was a significant change in a positive way.

However since my controlled pawn really depends on the thrusters simulation and the constraints in between them requires a very good connection / network, a bad network already makes all system behave broken. Maybe I will go into a simpler setup with CMV + just simple actors as thrusters to give a try.

[newwdles]

Well, what a week

So i tried the fix on the 5.7.3, there were mixed results. There were still stutter but less noticeable.

Wednesday the 5.7.4 came out, and with it the stutters are completely gone. Resimulation are completely transparent, absolutelly no jitter.

No commit in the 5.7.4 seems aimed at this issue, however there is this one :

Chaos : Fix traces not working properly on partialy destroyed geometry collection when removal feature is enabled cedric caillaud 20/02/2026 19:45

It disable the multithreading on the collection on the dirty particle in the physics logic (or something like that ). Reverting it immediately causes the stutter to come back.

So the isResim condition may not be the real issue, maybe it’s a race condition issue. However disabling the multithreading look like a temporary fix, i’m afraid the bug will come back when the issue described by the commit is fixed and the multithreading is enabled again.

[szefopl (szefo)]

Some ppl where suggesting that the jittering issues is not in the plugin, but with the network and prediction stuff not working correctly.

I do not have right now a good project to test this and the modular example are broken for now on my end, so if anyone wants to check this, here is how.

The best testing level would be the one that u can run multiple vehicles one by one spawning new, at least this is the scenario i always had this issue sooner or later.

At the start it was fine, with 2-3 vehicles, the more vehicles i spawned the more jitter there was.

How to test this, u need to disable physics prediction, after that u will not be able to control the vehicle.

To make it work again with disabled prediction u need to call ProduceInput on tick in UModularVehicleBaseComponent

From c++ or adding BlueprintCallable to the function and calling it from BP tick

This is the function that is called only if prediction functionality is enabled to read input, if u call it yourself it will read the buffer without the need for any prediction.

The only issue is its not exposed to BPs, so u need to call it from c++ or expose it yourself, so its only to test for ppl that can use c++.