Hi again to everyone

I noticed we are now at least 3 on this forum, trying to create a proper car simulation. It seems everyones main goal is to create something fun (drifts...), based on realistic physics, but not too hard for the player. So closer to something like GRID than Forza.

I think i am right when i say this : we all want the kind of fun we can find in games like NFS. If a game like NFS or GRID (or even the Steam racing casual games) can only be achieved by using some cheats or specific player input tweaking, i suppose we all want to know what they are.

What i propose here is :

1. Share the fundamental basics every car simulation based on newton physics should have. eg : weight transfer, pacejka-like curves for getting output of SR/SA....
   
2. Share one or two basics car models and parameters to be sure we are talking about the same thing.
   
3. Share some reference values/behaviours in predetermined situations, so that everyone can compare their own values with some reference to know if things are going right or wrong.
   
4. Share math/physics formula, tips & tricks, or cheats & shortcuts that would allow us to make the game more fun. Because we must not forget, it is all about fun in the end.
   

I would try to maintain the first post as updated as possible as people bring their contributions. So if this thing is going well, it could be a very good starting point in the future for programmers wanting to create their own car simulation.

I'll start to fill the blanks, and i hope the car experts will bring their knowledge to be sure future readers won't be misleaded by the things listed here.

One of the goals here is to cover 2D and 3D games, as the car behaviour will be similar in both situations.

Part 1 - What should i absolutly do to make this a fun game with drifts, skids and such things ?

Let's make an exhaustive list of things needed to achieve a drifting behaviour on a racing car.

1. Get basic newton physics right : forces, acceleration, torque, integration. You can use a physics engine for this, like box2d or PhysX.
   
2. At first use a 1ms timestep to update the simulation at a decent rate and avoid bad approximations.
   
3. Create 4 wheels and attach them to the body.
   
4. Use wheel distance to CG to calculate weight transfer lateraly and longitudinal. Combine those two.
   
5. Use real car suspension/springs/anti roll bars, or the weight transfer will just be instantaneous and make the car highly unstable.
   Subsidiary question : is it vital to have proper car suspensions ?
   
6. Use some "soft" player inputs, and try to limit steer angle at high speed to get good lateral forces, or the car might be totally uncontrolable. Or use realistic driving accessories.
   
7. Find out velocity for each wheel contact patch, transformed in the wheel space. So if the wheel is heading 45° and the car going straight, the front wheels will have both X/Y velocities, as rear wheels will only have Y (if Y is front).
   
8. Use the powered wheels velocity to determine motor RPMs. Based on player throttle input, and engine torque curve, generate a torque force for powered wheels.
   
9. Apply torque on wheel so it increase their angular velocity.
   
10. Calculate wheel slip angles and slip ratios.
    
11. Use a plotted pacejka curve, or a real formula to find out the normalized force the tire must produce front/lat.
    Subsidiary question : is it vital to have the original formula instead of a simple pre-plotted curve ?
    Subsidiary question : is it vital for nice drifting to have combined lateral/front formula ?
    Subsidiary question : is it vital for nice drifting to feed directly the real load to the formula ? If i multiply the normalized 1N value by the wheel Fz result is supposed identical right ?
    
12. Create a vector for front/lat forces, and check this vector on friction circle/ellipse. Cut any part which is not inside the circle.
    Subsidiary question : should ellipse max values be the same as pacejka normalized max values ?
    
13. You can now multiply the remaining vector by the wheel weight (Fz)
    
14. For the longitudinal component of the force, reintegrate it in the wheel (with the radius), so it decrease their angular velocity. That part is what makes the wheel angular velocity adapt to the car speed.
    
15. Apply the resulting forces to the body, at the attach point of the wheel, or directly the contact patch in 3D, and calculate resulting torque/acceleration on the body.
    
16. When 4 wheels have generated torque/forces for the car body, integrate those values in the physical engine to produce velocity and move the car.
    
17. Apply damping forces (rolling friction, air drag). It is not supposed to be vital to car behaviour, but it might help a little. It will mostly influence acceleration time and maximum speed.
    

That should be all what is needed to get a car simulation right. At least theorically. I think i have forgotten nothing.

Part 2 - The reference car(s)

The goal of this part is to have reference values for a classic car, so we can compare our values and behaviours.

The classic car inspired from some Corvette C5 values and other frequent values seen here and there. Let's call it X-Car-1
[spoiler]

/** GENERAL BODY CONFIGURATION **/
// Length of the car (m)
body_length = 4.57;
// Width of the car (m)
body_width = 1.87;
// Mass of the car in Kgs
body_mass = 1500;
// Inertia of the car
// Rectangular box inertia formula is : (mass * (boxWidth² + boxLength²)) / 12 --- (height doesnt count)
body_inertia = 3000;


/** WHEEL ATTACH POINT AND STATIC WEIGHT DISTRIBUTION **/
// Vertical distance from front axle to gravity center horizontal line (if car is heading vertical)
geometry_frontAxleDistanceToCG = 1.60;
// Vertical distance from rear axle to gravity center horizontal line (if car is heading vertical)
geometry_rearAxleDistanceToCG = 1.60;
// Horizontal distance from any wheel attach point car vertical middle line
geometry_wheelDistanceToCarCenter = 0.80;
// Height of the CG (in meters)
geometry_heightOfCG = 0.30;

/** ENGINE SETUP **/
// Values of the power curve for each RPM
engine_torquePowerCurveValues = [ 400, 430, 448, 460, 480, 486, 480, 500, 550, 500];
// Values of the RPMs for the power curve
engine_torquePowerCurveRPMs = [1000, 2000, 2500, 3000, 4000, 4500, 5000, 5500, 5800, 6000];
// Used in dev to quickly enhance engine power by a flat multiplier
engine_torquePowerCurve_multiplier = 1;
// RPMs at wich the driver should shift up
engine_shiftUpRPMs = 5800;
// RPMs at wich the driver should shift down
engine_shiftDownRPMs = 3000;
// Some values used to slow down car engine when no throttle is applied
engine_brakeCurveValues = [ -40, -40, -50, -60, -70, -80, -100];
// The RPM values
engine_brakeCurveRPMs = [ 1000, 1050, 2000, 3000, 4000, 5000, 6000];
// Used in dev to quickly enhance engine brake curve effect by a flat multiplier
engine_brakeCurve_multiplier = 1;
// The gear ratios of the gearbox
engine_gearRatios = [-2.90, 2.66, 1.78, 1.30, 1.10, 0.96, 0.80];
// The differential ratio (between gearbox output and motorized axle input)
engine_differentialRatio = 3.42;
// Efficiency of power transmission
engine_transmissionEfficiency = 0.7;
// Ratio of power going to rear axle (1 means 100%)
engine_rearAxlePowerRatio = 1.0;
// Ratio of power going to front axle
engine_frontAxlePowerRatio = 0.0;


/** WHEELS SETUP **/
// Time in seconds to reach max steering angle
wheel_steerSpeed = 0.500;
// Maximum steer angle when the car is stopped/low speed (in radians !)
wheel_steerAngleMax = Math.PI / 4;
// If setted to yes, the driver will not be allowed to steer to much at higher speed
wheel_optimizeSteerAngle = true;
// Adjusts autosteer level, from 0 to 1 : 1 will be perfect knowledge of actual cruise speed
wheel_optimizeSteerAngleValue = 1.0;
// Bonus : autosteer formula | max_steer = Math.min(maxSteerAngle, Math.PI/2 - Math.acos(peakLateralSlipAngleInDegrees / absFrontSpeed))
// Inertia of the wheel
// TODO : it should depend of the actual gear but i have no formula for it
wheel_inertia = 25;
// The radius of the wheel (in meters)
wheel_radius = 0.33;

/** FRONT FRICTION FORCES SETUP */
// The front pacejka curve values for a load of 1N (for slip ratio output)
friction_front_longitudinalPacejkaCurve_valuesFor1Nload = [0, 1.00, 1.20, 1.30, 1.20, 0.90, 0.70];
// The front pacejka curve slip ratios corresponding to the above force outputs
friction_front_longitudinalPacejkaCurve_slipRatioValues = [0, 0.01, 0.03, 0.05, 0.10, 0.20, 1.00];
// Used in dev mode to multiply pacejka output for testing purposes
friction_front_longitudinalPacejkaCurve_valuesMultiplier = 1;
// The front pacejka curve values for a load of 1N (for slip angle output)
friction_front_lateralPacejkaCurve_valuesFor1Nload = [0, 0.10, 0.20, 0.30, 0.41, 0.49, 0.58, 0.66, 0.73, 0.80, 0.87, 0.92, 0.97, 1.01, 1.05, 1.08, 1.11, 1.13, 1.14, 1.15, 1.16, 1.15, 1.10, 1.03, 0.94, 0.79, 0.66, 0.55, 0.50, 0.46, 0.39];
// The front pacejka curve slip angles corresponding to the above force outputs
friction_front_lateralPacejkaCurve_slipAngleValues = [0, 1.00, 2.00, 3.00, 4.00, 5.00, 6.00, 7.00, 8.00, 9.00, 10.00, 11.00, 12.00, 13.00, 14.00, 15.00, 16.00, 17.00, 18.00, 19.00, 20.00, 25.00, 30.00, 35.00, 40.00, 50.00, 60.00, 70.00, 75.00, 80.00, 90.00];
// The slip angle for which you get maximum force
friction_front_lateralPacejkaCurve_slipAngle_peakGrip = 20;
// Used in dev mode to multiply pacejka output for testing purposes
friction_front_lateralPacejkaCurve_valuesMultiplier = 1;
// The front traction ellipse longitudinal friction limit
friction_front_longitudinalLimit = 1.30;
// The front traction ellipse lateral friction limit
friction_front_lateralLimit = 1.30;


/** REAR FRICTION FORCES SETUP */
// The rear pacejka curve values for a load of 1N (for slip ratio output)
friction_rear_longitudinalPacejkaCurve_valuesFor1Nload = [0, 1.00, 1.20, 1.30, 1.20, 0.90, 0.70];
// The rear pacejka curve slip ratios corresponding to the above force outputs
friction_rear_longitudinalPacejkaCurve_slipRatioValues = [0, 0.01, 0.03, 0.05, 0.10, 0.20, 1.00];
// Used in dev mode to multiply pacejka output for testing purposes
friction_rear_longitudinalPacejkaCurve_valuesMultiplier = 1;
// The rear pacejka curve values for a load of 1N (for slip angle output)
friction_rear_lateralPacejkaCurve_valuesFor1Nload = [0, 0.10, 0.20, 0.30, 0.41, 0.49, 0.58, 0.66, 0.73, 0.80, 0.87, 0.92, 0.97, 1.01, 1.05, 1.08, 1.11, 1.13, 1.14, 1.15, 1.16, 1.15, 1.10, 1.03, 0.94, 0.79, 0.66, 0.55, 0.50, 0.46, 0.39];
// The rear pacejka curve slip angles corresponding to the above force outputs
friction_rear_lateralPacejkaCurve_slipAngleValues = [0, 1.00, 2.00, 3.00, 4.00, 5.00, 6.00, 7.00, 8.00, 9.00, 10.00, 11.00, 12.00, 13.00, 14.00, 15.00, 16.00, 17.00, 18.00, 19.00, 20.00, 25.00, 30.00, 35.00, 40.00, 50.00, 60.00, 70.00, 75.00, 80.00, 90.00];
// The slip angle for which you get maximum force
friction_rear_lateralPacejkaCurve_slipAngle_peakGrip = 20;
// Used in dev mode to multiply pacejka output for testing purposes
friction_rear_lateralPacejkaCurve_valuesMultiplier = 1;
// The rear traction ellipse longitudinal friction limit
friction_rear_longitudinalLimit = 1.30;
// The rear traction ellipse lateral friction limit
friction_rear_lateralLimit = 1.30;

/** DRAG FRICTION FORCES SETUP **/
// The air drag value, wich is multiplied by speed²
// Bonus : air drag formula
// AIR_DRAG_FORCE_CONSTANT = 0.5 * Cd * A * rho
// Cd = coefficient of friction > depends on the shape of the car and determined via wind tunnel tests (Approximate value for a Corvette: 0.30)
// A is frontal area of car > approx. 2.2 m2
// rho (Greek symbol )= density of air > 1.29 kg/m3
// AIR_DRAG_FORCE_CONSTANT = 0.5 * 0.30 * 2.2 * 1.29 = 0.4257
friction_air_drag = 0.4257;
// The rolling friction value, wich is multiplied by speed (applied blindly in X, Y)
friction_roll_drag = 15;


/** CAR SUSPENSION SETUP **/
// TODO : implement real car suspensions
// Flat front/rear weight transfer division
suspension_frontRearWeightDisplacement_divider = 2;
// Flat lateral weight transfer division
suspension_leftRightWeightDisplacement_divider = 4;
// Time for a new load value to be fully applied in milliseconds
suspension_timeToReachForce = 1500;

[/spoiler]

To be honest i must say this reference values don't make a nice car. I'll post a general handling video soon.

Here are some parameters taken from Edys Car Vehicle Physics for the Red Pickup you can try in the demo. Some of the values can be monitored with B and the SHIFT+B in the demo. I post it here to give some elements to discuss about as a part of those values are not present above, and for some i just dont know what they mean. Any idea / insight would be appreciated.
[spoiler]

[/spoiler]

Part 3 - Reference handling and values

The goal of this part is to put the car in a typical situation with controlled environment, and to look at what happens. Game may be written in Java, .NET, Unity or whatever, if you have taken control of the physics, and if you have the right car parameters, the values should look like these.

X-Car-1_T01 : apply 100% throttle for 10.00 seconds
Coming soon...

X-Car-1_T02 : launching directly the car with a front velocity of 50 meters/s
Coming soon...

X-Car-1_T03 : launching directly the car with a side velocity of 50 meters/s
Coming soon...

X-Car-1_T04 : launching directly the car with an angular velocity of 10 radians/s
Coming soon...

X-Car-1_T05 : launching directly the car with a combined front/lateral velocity : 50m/s in each direction
Coming soon...

X-Car-1_T06 : launching directly the car with a combined front/lateral velocity : 50m/s in each direction and a 10 radians/s angular velocity
Coming soon...

X-Car-1_T07 : apply 100% throttle for 10.00 seconds, then without releasing throttle, press the right key for the next 10.00 seconds (right + full throttle)
Coming soon...

X-Car-1_T08 : apply 100% throttle for 10.00 seconds, then release throttle, and press the right key for the next 10.00 seconds (right + free roll)
Coming soon...

X-Car-1_T09 : apply 100% throttle for 10.00 seconds, then apply brake, and press the right key for the next 10.00 seconds (right + brake)
Coming soon...

X-Car-1_T10 : a controled drift situation (still have to find a reference test)
Coming soon...

Part 4 - Tips & tricks

This part is still R&D, and i am more open to debate and wanting to collect ideas and tests than trying to explain to do this or not. I do not have the solution for doing most of those things anyway.

List of "legit" tricks :

1. Limit maximum steer angle according to speed & max grip peak SA
   
2. Same for throttle/brakes with peak slip ratio output
   
3. Decrease gently (or not) steer angle after input release
   
4. Be aware (you, programmer) of when a drift situation occurs and change car control inputs to help player have more fun
   
5. Instead of modelizing a complex combined front/lat grip formula, just determine how much percent of lateral grip you lose in function of the slip ratio
   

Cheap tricks or cheats :

1. If player apply throttle, just directly add front Y velocity to car
   
2. Disable real front/rear weight calculations. Just decide of a prefixed weight change on acceleration/braking situations
   
3. Gently decrease forces near/after traction circle max value, instead of just cutting it
   
4. Rotate directly car velocity vector by a very small percent of the front wheels slip angle
   
5. Use a linear slipAngleInRadians * someConstant formula for lateral pacejka output
   

Part 5 - Reference formulas and ressources

More content to come...

Reference physics formulas, tutorials and references...

Part 6 - Questions, FAQ, things we don't know

Questions :

1. What is the formula to have a friction ellipse instead of a circle ?
   
2. Where can we find a simple formula for combined long/lat grip ?
   
3. Should we apply a static friction force or something like that or just pacejka ?
   

FAQ :

1. Should i apply forces lateraly to car body or to the wheel ?
   To the wheel.
   
2. More classic question and answers to come...
   
3. What value can i use to decide if i must draw lateral drift skidmarks ?
   
4. What value can i use to decide if i must draw burnout skidmarks ?
   

I am a little bit tired, but i will update with more basics.

I'm looking forward to read your answers and contributions, if anyone interested !

Dude, sorry if my post won't help you, but i don't understand the point of your new thread.
As far as i understand, you are doing a 2D car sim right ?

The problem that you face in a 2D car sim are really different from any 3D car sim so it make your thread evern harder to understand.
Also, we are not just 3 but maybe hundred of people on this forum are trying to get car Physics right.

Also, to be honest, everyone have its own vision about what is fun car physics, what is realistic car physics and what is arcade style car physics.
So there is no easy way to share stuff on it in my opinion.

wow.. huge post.. it'll take me ages to go through it all.
All I can say straight away is that 1ms deltaT is waaaaaaay more than what you would need for a simple racing game, >=1000Hz and you are in the realm of professional simulators and, starting to get in trouble with 32 bit floating point accuracy.

Probably a 100Hz or 200Hz physics rate should be enough if the car isn't too stiff.

EDIT: More notes..

Use wheel distance to CG to calculate weight transfer lateraly and longitudinal. Combine those two.

This is most probably wrong... you don't calculate weight transfer, it should be automatically happening in your rigid body physics

Subsidiary question : is it vital to have proper car suspensions ?

For a simple racing game you can get away with a simple "slider" suspension only going up and down. For a proper sim, you'll need a much more complex and realistic movements but that will also require engineering skills to set it up in the sim and lots of tools to understand where it goes wrong.

Use the powered wheels velocity to determine motor RPMs. Based on player throttle input, and engine torque curve, generate a torque force for powered wheel

You can get away with it, but again, this is backwards thinking, torque goes from engine to wheels, wheel speed is a result, not an input. Once you stick a differential in the mix things get really complicated, proper differential modeling is tricky... but essential for "on the limit and over" driving styles.

Hi !

Thanks for your answers !

Well, indeed it doesn't help that much ^^ Instead of focusing on fun, i know at least a part of the posting people seems to want to have the basic physics right. So knowing if a typical car launched at X velocity should more or less stop in 1 sec or 100 sec might help future beginners to start implementing physics. I know i really had a hard time to get the basics right, and the lack of reference values was a great pain.

AFAIK, most of 2D simulations simulates a part of inner 3D (eg : weight transfer), and as long as you consider driving on a flat surface, things are quite similar. For a beginner starting right away with 3D terrain and car model might be a good thing to make stupid mistakes.

A few weeks ago i asked if a lateral pacejka force should be applied lateraly to wheel body or to car model, and response was not clear to everyone. A LOT of basics things are not well understood by beginners, and we have a few people here who have successfully created full racing games. So again, i think it might be a good idea to have some shareable and stored knowledge on the subject.

As for the "what is fun" part, i guess you are right. But again AFAIK, getting controled drifts and natural car behaviour is kind of what every carsim dev wants,no ?(independant of arcadish/simu considerations)

I haven't been able to find very simple and important car setup parameters, so why not trying at least to share those somewhere ? My max_steer function comes from a 3D game and it works well for my 2D sim ;) I really think we can try to bring light to some dark places, instead of always creating topics to ask something precise and then realize a few answers laters that we have missed other things or that we just didn't think of a key feature. Almost all car related topics end like that. And the only tutorials are the one from marco, gamedev and unity, which i personnaly think are really vague on a lot of key subjects like proper car inputs management or how pacejka works. And PHORs is way too complicated for most readers to implement it i guess. I know i do not want to implement the Maths, altough the reading helped me to understand many things.

Probably a 100Hz or 200Hz physics rate should be enough if the car isn't too stiff[/quote]
Well, the 1000Hz value in test/dev purpose allow us to be sure any instability does not come from there. Objective of the thread is to try to enlight newcomers to the subject. For a game in early prototype stage, the computer can handle it well. And everyone is free to adapt the value to its needs later, but for the scientifical accurate part, i think 1000Hz is doable and a simple value.

Use wheel distance to CG to calculate weight transfer lateraly and longitudinal. Combine those two.
This is most probably wrong... you don't calculate weight transfer, it should be automatically happening in your rigid body physics[/quote]
Sorry, i meaned load transfer and not weight transfer, i offen misuse those two words. My dynamic load transfer happens with acceleration in the car body. So to know the real weight on a body point, i have to find out its distance to CG, and then use long/lat acceleration. As i do not use a physics engine (except for the collision detection part), i code weight transfer as much as simple forces integration. So AFAIK it cannot happen automatically unless i use a real 3D engine and feed him with some values. I get front/lat acceleration depending on current acceleration values, which themselves depends on previous ticks generated forces.
The real weight transfer, which happens when the car CG is displaced occurs indeed automatically as a suspension or an other is going up or down. I'll edit my post to use correct terms.

I believe that by best contribution to this thread is my article about the pacejka formulas, including the interesting debate at the bottom comments:

[indent=1]Facts and myths on the Pacejka curves

In summary, you need these kind of formulas only when developing high-end ultra-realistic vehicle simulation with real tire sets (think on netKar Pro, rFactor, etc). But you are not required at all to use these approaches for developing realistic vehicle physics. These methods are inherited from the automotive industry and it's quite difficult to implement them properly in video games.

In my tests I was able to develop a very fun and realistic vehicle simulation using basic vector math only, with the vehicle reacting properly to burnouts, drifting, brake locks... everything in a few lines and running at 50 Hz.

Forget those numbers and quantities on Edy's Vehicle Physics. That system was developed as workaround for the bad implementation of the wheel component in PhysX 2.8 (nxWheel, used by Unity as WheelCollider). As one of the nVidia developers confirmed me recently, that implementation was cheap and easily tuned for specific applications. My Vehicle Physics package makes the wheel component behave in a barely acceptable realistic way, but none of its parameters has to do with real vehicle dynamics.

I'm now developing a new tire simulation model designed form scratch specifically for video games. It provides a complete tire simulation that reacts realistically on almost all possible situations of the wheel, including static friction and wheel spin. I expect it to be completed by the end of this year.

About the 1ms deltaT subject: in my opinion the problem with this is that the traditional methods are way too dependent of the deltaT. In a regular implementation of slip ratio, the resulting force exerted by the tire could double if deltaT is doubled. So you could find that your simulation works exactly as expected at a specific deltaT only. This is why I'm developing a method that doesn't depend directly on the deltaT. A small deltaT (< 20ms) helps avoiding instabilities at certain extreme situations, but the resulting force doesn't depend directly on it.

Use wheel distance to CG to calculate weight transfer lateraly and longitudinal. Combine those two.
This is most probably wrong... you don't calculate weight transfer, it should be automatically happening in your rigid body physics

Sorry, i meaned load transfer and not weight transfer, i offen misuse those two words. My dynamic load transfer happens with acceleration in the car body. So to know the real weight on a body point, i have to find out its distance to CG, and then use long/lat acceleration. As i do not use a physics engine (except for the collision detection part), i code weight transfer as much as simple forces integration. So AFAIK it cannot happen automatically unless i use a real 3D engine and feed him with some values. I get front/lat acceleration depending on current acceleration values, which themselves depends on previous ticks generated forces.
The real weight transfer, which happens when the car CG is displaced occurs indeed automatically as a suspension or an other is going up or down. I'll edit my post to use correct terms.
[/quote]

actually the two terms are almost equivalent and, as I said, using body acceleration to calculate load transfer is the wrong way of doing it:)

intuition should suggest you that load on a tyre should be influenced by the movement of the tyre, not from the movement of the car body.

In a regular implementation of slip ratio, the resulting force exerted by the tire could double if deltaT is doubled

that doesn't make sense at all. deltaT doesnt even appear in a slip ratio definition how can it influence it? There is no reason for a sim to change behaviour if dT is changed, the ENTIRE point of having a dT in the first place is to make things indipendent of time

Well, thanks everybody for the answers, as always, i am still learning interesting things.

Edy, i am really glad to see you participating in here, your experience is very valuable. Actually i bought Edy's Car Physics for unity, just to be able to look at car setup parameters and to have a better understanding of some of the mechanics. But with the system based on Unity WheelColliders how it really works is kind of hidden + i have trouble reading spanish comments ^^ Too bad my game is javascript and not Unity ^^

Anyway i have read all of your articles and the interesting comments too. Helpful, but it didn't gave me a real alternative to pacejka curves. To be clear i am working with simple curves plotted for 1N i am scaling afterward. I never messed with those complicated parameters and as pacejka just produce some value, it seems clear it is a very small part of a proper driving game.

that doesn't make sense at all. deltaT doesnt even appear in a slip ratio definition how can it influence it? There is no reason for a sim to change behaviour if dT is changed, the ENTIRE point of having a dT in the first place is to make things indipendent of time

Well, it makes a lot of sense to me, actually a lot of articles explain this. Basically if you have 200% slip ratio, and produce 5kN of force for a 50ms timestep, you are stuck with the same force applying for 50ms. With smaller timestep, physics engine actually has a chance to see that slip ratio may have go down to 100% around 25ms, and for the remaining 25ms you will produce a different amount of force for example. You seem to have some experience in car physics (with 2010 posts !), so i guess you already know this and maybe we are not talking about the same thing Or you have eliminated any numerical instability issue in your simulation and just have forgot about it ^^ Anyway it is not that hard to emulate some equivalent to SR with similar results, but improved stability. My lateral forces are quite stable too at 50Hz, the difference is not really noticeable with 1000Hz.

In summary, you need these kind of formulas only when developing high-end ultra-realistic vehicle simulation with real tire sets (think on netKar Pro, rFactor, etc). But you are not required at all to use these approaches for developing realistic vehicle physics. These methods are inherited from the automotive industry and it's quite difficult to implement them properly in video games.

Really ? oO i just learned it. I had the feeling a lot of games (like GTA, or even more arcade games) use the curve approach, even if they tweak it rather than directly implementing the formula. Your framework doesnt seems too much realistic to me, and it's using it right ? I was just plotting simple curves scaled by weight load, and (re)discovered today, that forces do not linearly increase with Fz, thus making proper use of the formula important to me, or at least it is what i was thinking until i read this.

In my tests I was able to develop a very fun and realistic vehicle simulation using basic vector math only, with the vehicle reacting properly to burnouts, drifting, brake locks... everything in a few lines and running at 50 Hz.

Oh man, you just blowed up my entire world ^^ just kidding. I know we can have stable behaviours at 50Hz, but having controled/fun drifts over/under steer with really simple maths, without getting into wheel angular vels or SA/SR, and weight-dependant curves seems quite hard to me without recreating this entire logic out of nothing with math hacks or such things. I'd really love to have a look or even be able to buy such a piece of code (seriously). Right now, my best hope to control the drifts without having a naturally oversteering car is to have better load transfer calculations and to stop to apply Fz linearly after normalized pacejka output. Maybe i am once again very wrong to hope that it will greatly improve car handling and capabilities... :'(

I have the intuition without a little of weight transfer and some dumb but credible suspension and traction circle or at least combined slips you can't have the driving feeling of your red pickup for example : if i brake enough in a corner i am able to produce controled oversteer to turn sharply at 100Kmh in your 90° curves in the city demo.

The best i can do to have "fun" physics with very little code is to directly rotate car and to let the lateral forces of the tire do the rest of the job. Not good enough if i want my player to have car parts and i guess you are suggesting something more sophisticated than this.

actually the two terms are almost equivalent and, as I said, using body acceleration to calculate load transfer is the wrong way of doing it:)
intuition should suggest you that load on a tyre should be influenced by the movement of the tyre, not from the movement of the car body.

Wow, that is really confusing me. What do you mean by tyre movement ? As in the tire going up and down (spring/suspesion) ? Unless there is a bump in the road, AFAIK, acceleration is responsible for load transfer.
Wikipedia is quite clear on this :

In wheeled vehicles, load transfer is the measurable change of load borne by different wheels during acceleration (both longitudinal and lateral). This includes braking, and deceleration (which is an acceleration at a negative rate).[6] No motion of the center of mass relative to the wheels is necessary, and so load transfer may be experienced by vehicles with no suspension at all. Load transfer is a crucial concept in understanding vehicle dynamics. The same is true in bikes, though only longitudinally.

Again, when i read what you say and compare it with my "knowledge" of the subject, i can't stop me of thinking i have clearly messed up something... Please enlight me

I'm now developing a new tire simulation model designed form scratch specifically for video games. It provides a complete tire simulation that reacts realistically on almost all possible situations of the wheel, including static friction and wheel spin. I expect it to be completed by the end of this year.

I'm looking forward to it, but sadly i'd like to have my game runing in alpha stage before that time. And anyway i would still have to rewrite the entire thing in javascript, which i would not be able to do without a lot of detailed english comments everywhere ^^

Actually in my sim everything is fine, except i cannot really combine different behaviours, and it really seem to me everything is VERY weightload related. If i cut a vector using friction circle, it usually makes the car spin very fast. Same goes if too much weight goes to one of the outside front wheels. So have i missed really important things, or am i going the wrong way trying to get more reasonnable load transfer ?
I mean if you can achieve credible drifts behaviours without load transfer or lateral pacejka... I'd really like to know where to look to do it

As always, really looking forward to your answers ! i have spent 6 months reading a lot of docs and trying many things, but i still need to learn A LOT. Main problem is to when you get the basics "right" and it still not fun, is to find out what to try to move forward.

I have seen in a lot of threads, a lot of people trying the same things, learning slowly the hard way, to finally give up or be unsatisfied with their car handling. If i get better understanding of the problems and manage to get my car simulation running fine (failure is not option, the rest of the game is going very well), i would be very happy if sharing that knowledge helps future racing developers.

[quote name='Edy' timestamp='1348758851' post='4984376']
In a regular implementation of slip ratio, the resulting force exerted by the tire could double if deltaT is doubled

that doesn't make sense at all. deltaT doesnt even appear in a slip ratio definition how can it influence it? There is no reason for a sim to change behaviour if dT is changed, the ENTIRE point of having a dT in the first place is to make things indipendent of time
[/quote]



The problem arises when calculating w (angular velocity). If the wheel is in the air, applying torque at the axle results in an angular acceleration a = Torque / Inertia. Then w = a · dT. Thus, doubling dT means double w. Everything is fine to this point: applying a constant torque during twice the time produces twice the angular velocity.

But if the tire is grounded, applying the same Torque at the axle requires calculating the slip ratio and looking up the value in the friction curve in order to get the final force at the tire. And here is it: how to calculate w now? All I was able to find over there is that one must simply calculate w as if the wheel was unloaded, then use the ground speed V and the slip ratio definition to get it. Thus, double dT means more slip ratio. Locking up the friction curve returns a different force at the wheel depending on dT. Of course, the smaller dT, the smaller are the difference among results. This is why many people recommends a minimum of 500Hz for these calculations.

Of course, this is all I was able to find and deduct from the information and source code available over there. Surely there are other methods, but they are either a secret available only for gurus of vehicle simulation, or so complicated that I just didn't recognize them ("not my war, I want it simple"). So I'd really love to hear your point on this specific issue

But if the tire is grounded, applying the same Torque at the axle requires calculating the slip ratio and looking up the value in the friction curve in order to get the final force at the tire. And here is it: how to calculate w now? All I was able to find over there is that one must simply calculate w as if the wheel was unloaded, then use the ground speed V and the slip ratio definition to get it. Thus, double dT means more slip ratio. Locking up the friction curve returns a different force at the wheel depending on dT. Of course, the smaller dT, the smaller are the difference among results. This is why many people recommends a minimum of 500Hz for these calculations.

That makes even less sense.. I read what you wrote several times and it really doesn't wherever you found these info they are just wrong all the way. Your wheel angular speed should be a function of all the torques (and forces transformed to torque) acting on the entire transmission system, from the engine to the wheels. All these are integrated with the same formulas and, unless they are wrong, deltaT won't change the result in any tangible way. You should make sure to double check your sources because the big risk here is you claiming to have a solution to a problem that never existed in the first place but it's just a result of your fantasy.

@PochyPoch .. what you are talking about has nothing to do with slip ratio, it's a "problem" common to every physical simulation integrated in discrete steps..of course a bigger integration time will lead to a bigger error.. it's obvious and it isn't what we were talking about.
Regarding the weight transfer, you are perfectly right.. on a vehicle with no suspension, (100% rigid body and 100% rigid steel tyres) load at one corner is EXACTLY the load transfer calculated analytically from the body's acceleration.. but there is no such a a vehicle.. even for a kart you'll have at the very least consider flexible tyres.. which are actually acting like a suspension.
Even worse with a car, where you have your tyres' springs and then your suspension springs.. so those analytically calculated load are only valid in steady state (ie. NEVER ) .. in every other situation load is a function of all those springs... the easiest and more common way of getting load is to treat the tyre as a spring and get the load from that spring compression... no calculation needed.