Vehicles with different suspension geometries?

[YaBoyShredderson]

I have been working on a custom wheel collider for some time now, and have a pretty robust implementation using a spherecast with some additional stuff to solve problems like suspension bottoming out/zero suspension and wheel width and things like that.

An issue i have however is that the suspension can only move up and down. I tried before using configurable joints and rigidbody with sphere colliders and cylindrical mesh colliders for the wheels to be able to configure mutliple different suspension geometries, and it worked out relatively fine when on smooth flat ground, but the moment you hit a curb or had some wonky terrain (or even just a ramp that was too low poly) it would rip the wheels off, bring the vehicle to halt, magically attatch the wheels back on again and then fling the vehicle into space.

The problem the joints is that they are not particularly stable (at least not for this use case in my experience), however i recently came across the articulation body, and throwing together a very rudimentary test, just a box with 1000kg articulation body as the root, with 4 20kg articulation bodies attached as the wheels with prismatic joints, it seems to be relatively stable (i havent actually driven it as my current vehicle system and tyre model would need to be redone, and im not sure how to fully use articulation bodies, as it doesnt make a whole lot of sense to use one on the body of the vehicle?) as i can set the spring damper values to anything i want without causing problems, and it appears that the constraints are inviolable?

Also, using physical colliders for the wheels is somewhat janky, and have recently discovered the ContactModificationEvent which has somewhat helped me fix this. Currently I am just aligning the normal of any collision to be Inline with the suspension to fix the poor collision handling with curbs and such, but its janky in other ways still, and requires me to use only discrete collision detection.

What is generally the best way to go about having this kind of suspension geometry? I want to gradually build up the complexity and realism of my vehicle simulation slowly over time, but as of now i think i will be ok with working out how to have stable implementatios of fixed suspension (think BMX, no suspension), straight up and down, and pivoting around some other point (motorbike swingarm kind of thing).

this isnt for any particular game i have planned, just for some experimentation and experience.

[codebiscuits]

Hi,
In our game Exo Rally Championship I’m using an ArticulationBody hierarchy with frictionless wheelmesh colliders to handle suspension. I had exactly the sorts of experience you describe with configurable joints (Edy, see below, seems to have absolutely nailed suspension using these joints (check his Twitter), but, he’s an actual wizard, I couldn’t get anywhere). I think the articulations are great for “stability”, but they do have various problems of their own (mostly, you can’t change the articulation hierarchy, including enabling/disabling stuff once it’s in place). We have swingarm suspension (single revolute arm joint per wheel)! It was hard! Kindof on the edge of my maths skills:)
In my own game, I was using Edy Vehicle Physics, and switching out the regular Unity WheelCollider for my own one that had the same interface (Exo Rally’s using the enterprise/full-source version of Vehicle Physics Pro in the same way; I think VPP is going to be more modular at some point in the future so you won’t need to buy full source - it’s a lot of money, but also, wow a lot of source!).
EVP was awesome as a starting point, as it had already solved a load of problems I wasn’t even aware of, so I could concentrate on just the suspension stuff. Even if you want to write your own eventually, I think it’s a great (cheap, full source) way to get started quickly and concentrate on the stuff you’re interested in.
I’m not suggesting this route as a best way to go at all, just, it’s working for us in our game right now. Our biggest challenge right now seems to be detecting wheel impact damage.
I’m using contact modification to “soften” impacts with small bumps (I weaken the max impulse, depending on penetration), otherwise the wheels would ping up all the time going over offroad terrain. I’m running physics at 120Hz, which for a single vehicle seems fine (could go higher?). I’m not sure how well it would cope with bumps as big as kerbs, I’d probably cheat a bit and bevel their colliders or something:)
Ah, I’ve also implemented fakey tyre flex, by putting prismatic joints in Y, Z and X, pretty stiff with a little bit of movement on them. The visible mesh is only a child of the spring, so the actual collider bobbles around invisibly inside, kindof.
I went down the solid colliders route because our vehicles have these large, “exposed” (not under the vehicle body) wheels, and traditional WheelCollider is bad at stunt driving/ weird terrein (no wheelies, no side-wheelies, etc); for regular vehicles on roads, regular WheelCollider is probably easier. Like, wow.
Good luck!

[YaBoyShredderson]

I will experiment with articulation bodies, due to there stability, but I kind of want the ability to break the joints. The contact modification works great with discrete collisions, but i have had problems with the ccd one.

Ill give the articulation bodies a go and see if i can find a work around for joint breaks and stuff. Thanks!

[codebiscuits]

Articulations can only use CCD with Sphere-, Capsule- or BoxColliders so we stuck with discrete @ high physics Hz. It seems fine for our ~300kph vehicles, provided we use the various tricks I talked about to smooth bumps. The Perrinn thing I linked has physics at 500Hz! I think I’m successfully using the contact mod CCD callback for other collisions elsewhere in our game though.
You can break articulationbody joints, but I found it awkward.
At one point I’d destroy and rebuild the articulation hierarchy (which can be awkward, restoring state to the articulations).
Now I just set the wheel mesh collider to be a trigger so it doesn’t collide with anything, hide the visible mesh & spawn some debris. The weight’s negligible compared to the rest of the vehicle, so, fine I guess:smile:
Other issues with ArticulationBody that occurred to me: no isKinematic! No visual interpolation/ extrapolation (e asy to do manually though ).

[Edy]

Fully agreed with @codebiscuits , they have a huge experience on this matter working on Exo Rally. Some additional notes:

Different suspension geometries can be achieved by making the wheel hub to rotate around an arbitrary axis, named Instant Axis, instead of just moving vertically. Check out the #VPPDev hashtag on my Twitter/X for details on how I’ve been developing a double-wishbone suspension out of the design specifications in the past months:

https://x.com/hashtag/VPPDev?src=hashtag_click&f=live

Standard Configurable Joints are very good on rotating another object around an axis and imposing hard limits in the rotation angle, but they’re not reliable on setting precise stiffness or damping values. So I leave the joint rotate freely within its configured limits, and I apply the suspension spring and damper forces myself. The video examples I upload to Twitter/X are recorded with physics at the default 50 Hz. However, I recommend 100 Hz for better consistency.

Colliders are purely rigid, non-deformable colliders. Whenever two colliders contact or inter-penetrate, the physics engine will either simulate the hard contact, or freak out trying to de-penetrate them. When using colliders as wheels, you need some way to prevent the physics to handle the contacts, and do it on your side. The contact modification API is the only way we have to do that. In my case, I use a standard collider for the wheel rim (hard collisions are ok here), but simulate the tire with an array of standard Raycasts. This allows to simulate the physical tire stiffness in the three directions straight away without additional joints.

[YaBoyShredderson]

@Edy

Fully agreed with @codebiscuits , they have a huge experience on this matter working on Exo Rally. Some additional notes:

Different suspension geometries can be achieved by making the wheel hub to rotate around an arbitrary axis, named Instant Axis, instead of just moving vertically. Check out the #VPPDev hashtag on my Twitter/X for details on how I’ve been developing a double-bone suspension out of the design specifications in the past months:

https://x.com/hashtag/VPPDev?src=hashtag_click&f=live

Standard Configurable Joints are very good on rotating another object around an axis and imposing hard limits in the rotation angle, but they’re not reliable on setting precise stiffness or damping values. So I leave the joint rotate freely within its configured limits, and I apply the suspension spring and damper forces myself. The video examples I upload to Twitter/X are recorded with physics at the default 50 Hz. However, I recommend 100 Hz for better consistency.

Colliders are purely rigid, non-deformable colliders. Whenever two colliders contact or inter-penetrate, the physics engine will either simulate the hard contact, or freak out trying to de-penetrate them. When using colliders as wheels, you need some way to prevent the physics to handle the contacts, and do it on your side. The contact modification API is the only way we have to do that. In my case, I use a standard collider for the wheel rim (hard collisions are ok here), but simulate the tire with an array of standard Raycasts. This allows to simulate the physical tire stiffness in the three directions straight away without additional joints.

Thanks. I had a look at #VPPDev and it looks very impressive. I never had much luck with configurable joints due to them being pretty unstable even at higher physics rates. I did make them better by modifying the normals of contacts to be inline with the suspension though.

How are you managing collision with raycasting? I tried that before, but the number of raycasts needed to model collision well enough was too high, so i stayed with sphere casts down from the top of suspension. Is there a reason to use raycasts instead of using a collider and modifying the contacts?

EDIT: Also, what do you mean by kinematic in your posts? Im assuming the wheels rigidbody isnt kinematic? I have only just started learning all of the physics about this kind of stuff recently so im not too familar, but im assuming you mean kinematics as a sub branch of physics?

[Edy]

@YaBoyShredderson

Thanks. I had a look at #VPPDev and it looks very impressive. I never had much luck with configurable joints due to them being pretty unstable even at higher physics rates.

Thank you! Actually they work pretty well when configured and used properly. I’ve rigged quite complex vehicles with configurable joints, using realistic masses everywhere, and working at the default 50 Hz.

@YaBoyShredderson

How are you managing collision with raycasting? I tried that before, but the number of raycasts needed to model collision well enough was too high, so i stayed with sphere casts down from the top of suspension. Is there a reason to use raycasts instead of using a collider and modifying the contacts?

Precision and versatility. I’m simulating the contact patch of the tire with the ground. For that I’m “reconstructing” the patch out of a very specific array of raycasts. This allows to simulate how each part of the tire’s profile supports a portion of the load, how the contact patch shifts depending on the conditions, and the tire’s deflection due to its own stiffness.

For example, here the tire uses 7 raycasts of different lengths to recreate the curvature of the section of the tread (white lines). The wheel has a slight camber, so only 5 of those raycasts make a contact. The different contact depths show the shape of the contact patch very clearly (white arrows). Tire forces are applied at the center of the contact patch (axes of coordinates).

This how the specifications of the tire looks like:

With standard colliders, the physics engine chooses the contacts arbitrarily based on its own criteria, typically related with the vertices and normals of the triangles contacted. Reconstructing a proper contact patch out of that doesn’t seem feasible, other than manually calculating the intersection of the tire-sphere with the rest of the geometry, for which a bunch of raycasts can make the job perfectly fine. Also Raycasts can be jobified (RaycastCommand), so they can be virtually free.

@YaBoyShredderson

EDIT: Also, what do you mean by kinematic in your posts? Im assuming the wheels rigidbody isnt kinematic? I have only just started learning all of the physics about this kind of stuff recently so im not too familar, but im assuming you mean kinematics as a sub branch of physics?

Oh, it’s not related with the Rigidbody settings. Those are standard non-kinematic bodies. “Kinematic suspension” refers to the design of a vehicle’s suspension system based primarily on geometric relationships and constraints, without directly considering forces and moments. This approach focuses on how the suspension components move relative to each other as the wheels travel up and down and as the vehicle steers.

[YaBoyShredderson]

@Edy

Thank you! Actually they work pretty well when configured and used properly. I’ve rigged quite complex vehicles with configurable joints, using realistic masses everywhere, and working at the default 50 Hz.

Interesting. Most of the problems I had were probably because I was sliding a frictionless mesh collider across the ground for wheel collision. If you’re simulating soft contacts using raycasts then I suppose the physics engine doesn’t freak out as much.

@Edy

Precision and versatility. I’m simulating the contact patch of the tire with the ground. For that I’m “reconstructing” the patch out of a very specific array of raycasts. This allows to simulate how each part of the tire’s profile supports a portion of the load, how the contact patch shifts depending on the conditions, and the tire’s deflection due to its own stiffness.

For example, here the tire uses 7 raycasts of different lengths to recreate the curvature of the section of the tread (white lines). The wheel has a slight camber, so only 5 of those raycasts make a contact. The different contact depths show the shape of the contact patch very clearly (white arrows). Tire forces are applied at the center of the contact patch (axes of coordinates).

You have given me an idea of how I could do something similar actually. Are the raycasts sent out from the centre across the width of the tyre, or is there also some cast around the rotational axis as well? Assuming the longer white arrow means that raycast is deeper into the terrain, would that translate to a higher normal force at that point on the contact patch?

This is no longer about suspension geometry, but I would like to ask about friction. I model friction at the moment using pacejka curves and slip ratio/angle. This works fine when moving at regular speeds for the most part but does require some fudging to keep behaviour reasonable. One thing it doesn’t do however is keeping the car stationary on a slope, because it requires the slip to occur before it can generate forces to maintain it in position. Do you have any advice or know any resources on that? Thanks.

[Edy]

@YaBoyShredderson

Most of the problems I had were probably because I was sliding a frictionless mesh collider across the ground for wheel collision.

I had tested this solution long ago and discarded it right afterwards. Now we can amend the contact points with the contact modification API, but the degree of precision I need discarded this as well. I’ll probably use the contact modification for the vehicle collisions, which in reality are not purely rigid.

@YaBoyShredderson

Are the raycasts sent out from the centre across the width of the tyre, or is there also some cast around the rotational axis as well? Assuming the longer white arrow means that raycast is deeper into the terrain, would that translate to a higher normal force at that point on the contact patch?

The white/gray vertical lines in the picture are the raycasts. The requisite is their origin to be inside a standard “hard” collider. Apart from that, you have plenty of freedom to throw them in the directions that best fit your contact model.

Yes, the white arrows are proportional to the contact depth in the terrain. A longer arrow means the wheel is supporting more load at that point.

@YaBoyShredderson

I model friction at the moment using pacejka curves and slip ratio/angle. This works fine when moving at regular speeds for the most part but does require some fudging to keep behaviour reasonable. One thing it doesn’t do however is keeping the car stationary on a slope, because it requires the slip to occur before it can generate forces to maintain it in position. Do you have any advice or know any resources on that? Thanks.

As you know, the slip ratio and slip angle produce an indetermination (0/0) at zero speed. All solutions I know involve using different calculations at low speeds. For example, a solution I used in the past is using the downforce and the ground’s slope to calculate a force that precisely cancels the velocity and the slope forces at each wheel when the car is stationary. Here you have freedom to calculate the forces in the way that best fits your model.

Also, don’t hesitate to simply switch between two completely different and discontinuous models at some speed threshold. Take iRacing for example. If you play iRacing, you can clearly notice in the steering wheel how they use two different friction models that switch at exactly 40 km/h.

[YaBoyShredderson]

@Edy

The white/gray vertical lines in the picture are the raycasts. The requisite is their origin to be inside a standard “hard” collider. Apart from that, you have plenty of freedom to throw them in the directions that best fit your contact model.

I have the idea to use a sphere cast as a sort of preliminary check going around the circumference of the tyre, and then if it hits, casting a collection of rays to get more detailed collision information.

@Edy

As you know, the slip ratio and slip angle produce an indetermination (0/0) at zero speed. All solutions I know involve using different calculations at low speeds. For example, a solution I used in the past is using the downforce and the ground’s slope to calculate a force that precisely cancels the velocity and the slope forces at each wheel when the car is stationary. Here you have freedom to calculate the forces in the way that best fits your model.

Yes, this causes problems. I limit the denominator to be 1 such that below 1m/s of true speed, it uses the absolute slip rather than the ratio, which solves the NaN/Infinity problems, but doesn’t really solve the “mush” the tyres seem to have at low speed. When I evaluate the friction curves, if the slip is than the critical slip, i simply return the peak grip and clamp the friction based on mass and the inertia tensor to prevent jitter.

@Edy

Also, don’t hesitate to simply switch between two completely different and discontinuous models at some speed threshold. Take iRacing for example. If you play iRacing, you can clearly notice in the steering wheel how they use two different friction models that switch at exactly 40 km/h.

Have never played iRacing. I don’t even really know any other friction models besides pacejka. I have heard of the brush model, but haven’t looked into it all too much.