Lots of weird things happening in Racer physics.

I'm not sure about any one else, but I'm struggling so much with Racer recently.

For example, the changes to static behaviour so cars didn't drift around as much when left idle, seemed to introduce more fudging factors and damping factors etc, which has actually cost us in dynamic accuracy.


The behaviour there was never an issue in past versions of Racer, but it's there now.

Then we have the differential issues that seems apparent, and perhaps even pacejka mixing issues.


With racer.ini dbg_car max_slip_len=6, ALL my cars can be driven through bends with the wheels pointing forwards and just drift. Keep turned in and floor it, and the car just drives through the bend perfectly well once the car assumes a certain drift angle.

If I try catch the slide, then I can add lots of opposite lock on, but when it corrects the result is a spin-out that is impossible to catch in the other direction. The car will never slide out with the max_slip_len near 6.
Increasing that value to 8 or 10 improves the behaviour of slides, but that background pushing 'understeer' is always there after a certain angle of slide is met.

I'm not sure if this is pacejka or differential related.


We also get the odd behaviour when doing a donut that we can draw a spirograph pattern from above with our skidmarks. A repeating surging then stopping pattern that may happen in real life in some rare cases, but it just seems the wrong behaviour (hard to explain)

Many cars now can't even do a donut, instead they just push the nose of the car around as if the front has zero grip, or the differentials generate more grip than is possible, and so overcome the front grip and push the car around.
Even if I apply some front brakes to try stop the front wheels rolling, they push over the floor and allow the car to move, rather than stay tied into the road forcing the back to spin about them.


I'm not an expert, I've not delved into the physics and maths and stuff. It's just not correct behaviour when the physics falls down on such simple tests as in the video above.

If these simple static tests fail, then it makes you have to question the dynamic reliability of Racer too, where it also feels to be a bit wrong.


In my view this is a recent thing. LOTS of physics things seem to have been changed recently and we are starting to see big holes appearing in Racers reliability.

Personally I'd rather have a car that floated about a bit when stood still, than the new and much more concerning issue exhibited in that video (and the others I posted on YouTube relatively recently)


Just worrying that coming up to v0.9, graphics are getting really good, but physics are being kinda broken as we move forward and we either will have to wait longer for v0.9 to refine the new physics changes, or get v0.9 coming out with bad physics.
The risk is we have something like the old 0.49 issue where roll centres are all out by about 50cm because of a bug, so all our v0.9 content is just wrong in a years time and needs re-working.


Hmmmmm...

Clearly not easy to program this stuff, but maybe we need to roll back a bit physics wise in some areas to what feels more solid and reliable, for v0.9 at least?


Dave
 
I must correct something in my earlier post, the problem I was having with launch control is NOT the problem. I think it may be related to the braking issue since it only does it at very low speeds. I only have it on 1 car however. Still investigating...

Alex Forbin

P.S. Why is friction_road set to 1.7 in the default car.ini? Why is it even IN the car.ini any more it's all handled by Pacejka and the special.ini for the tracks, right?
 
Alex, it sounds like you're experiencing the latest features of locking differentials in Racer :) They appeared with the slow speed floating "fixes" and depending on which of the recent betas you use, appear at higher or lower locking settings. So, in case you're using a type=3 differential for example, that's the most likely place to start looking for the source of auto-spinning wheels.
 
Alex, it sounds like you're experiencing the latest features of locking differentials in Racer :) They appeared with the slow speed floating "fixes" and depending on which of the recent betas you use, appear at higher or lower locking settings. So, in case you're using a type=3 differential for example, that's the most likely place to start looking for the source of auto-spinning wheels.

You got it. I was using a type 2, once I changed to type 3 the problem disappeared.

Thanks
Alex Forbin
 
type 1 viscous diffs also do weird things. I think ALL diffs are doing something weird, be that because the diffs are buggy, or through these weird wheel damping near 0 rotational velocity things.

I'll post a video shortly, which shows me spinning rears on grass, fronts braked on the asphalt. When I release the throttle, the rears get braked, but then kind of have a 'wound up' energy slowly releasing. If I now release the brake the car drives forward a few feet with this 'wound up' force.



It's just a bit weird.

It's probably not helping people do donuts etc either... I've found that the fronts just get pushed around really easily when trying to donut, almost like the front wheels have no weight over them and so a donut results in pushing understeer rather than a spin about the front wheels pivot.
Braking the fronts doesn't help, as we have seen in my earlier videos, they just spin anyway at low speeds, or just slide over the surface as if the front tyres are greased :(


These weird behaviours just don't fill me with confidence that everything else is working as it should.

Personally I think we should go back to the old drifty when stood still behaviour and get back proper wheel stopping/braking behaviours, then look a bit harder at how to solve the drifty when stood still problem without breaking everything that requires low wheel speeds :)


Dave
 
Here's another example of recent additions gone wrong:


The 613 would fly away magically as soon as a gear was engaged while standing still. I've been behind this problem for about a month now, on and off. Could not get another car to do the same, could not stop this one. It's the same version you guys downloaded here. All you need to do in order to get this effect is to have autoclutch disabled in racer.ini.

The reason for this behavior is the high rumble_amplitude setting in the engine setting - who would've guessed? Ruud suggests a setting of "5000" (moon calories? strength of an average fly?), but this already lifts the car up. When using a value of 20000 as in this case, the vehicle simply floats away. Zero it out if you like to keep your feet on the ground :)

This is exactly what we don't need now, closing in on v0.9.0f.
 
I'm not saying to choose between static and dynamic now, once and for all. Just that for this upcoming final version, I'd rather have less problems due to "shot from the hip" bug fixes, which introduce more issues than they correct.

Low speed driving or standing behavior is also of interest for me, be it for ordinary parking maneuvers, offroading or else. However, to be realistic I'd prefer a proper solution for this, not for Ruud to squeeze in something that is poorly documented and creates side effects simply because truth be told, he'd rather be dealing with the Cg system for the time being.

In my view, "v0.9.0f" is a mind game - people say they're waiting to work on stuff until it's out, but there's no reason to wait and not help discovering how stuff works right now. The shader logic hasn't changed much in quite a while, suspension curves have been working OK for almost two years now (fixed in early 2009, after initial misunderstandings), and the list goes on. How many of the new releases do you see using a decent amount of the stuff that's been available to us since at least 2009? What percentage is original content in the sense of not blindly copying questionable default code? Is it unclear how to use it? Does racer.nl's documentation confuse you more than it explains anything? We've all been there. So post about it here, let Ruud and everybody else know, that's what the community is there for.

When v0.9.0f comes out, I'll download and use it of course. When the next beta after that comes out, v0.9.0f is no longer going to have much relevance for me. If v0.9.0f is supposed to contain a working and usable Cg environment that can remain stable for some time, we're close to achieving that. If Ruud wants to focus on physics after the release of v0.9.0f, then I can live with the kinds of issues for v0.9.0f. They aren't new, nor as frustrating to actually development content with compared to what we got just recently, where a lot of things were seemingly just thrown in and blur our vision of what's really going wrong. These things need the same attention that Cg has gotten in the last years and in my opinion it's unrealistic to expect Ruud to pack it all into v0.9.0f and make it work faultlessly.

When you look at some of the bugs that turned up in those past two years, many times you have to stop and wonder how something like the CoG offset issue can happen in the first place. Is it just a sign error, a typo somewhere? Is it a factual issue? How long has it been around and what changed did we make to our vehicles to counter the effects? What else is going on? What does Ruud mean when the changelog says "force XYZ limit changed", what was wrong with it before?

A while back, Dave and I were pulling our hair out over cars magically gettings stuck in the air, just over the ground. As you might know, it turned out to be the sky.dof flag setting had changed and influenced our vehicles. Let that sink in for a moment if it's news to you. There was no hint for that anywhere about flag values changing and only persistent and creative trying brought us the solution.

That is a similar situation to what we have been dealing with lately, when Ruud mentioned having two kinds of differential sections working and seemingly disabling the one for braking fixed something... I'm not sure about that, but it's hard to figure out and just makes me suspect more of the same waiting to turn up.

If you will, I'd rather get v0.9.0f over with and then work on these points, if that's what it takes to motivate everybody involved, Ruud as well as the community.



One last point to end this rant - graphics and physics aren't opposite poles in a simulation project. Virtual realism includes both in equal shares (and a few more slices of audio etc). Sure, if I was forced to choose between them, I wouldn't have to think for too long. The only reason we splice it up is so it remains workable. Both depend on a solid understanding of physics as well as programming and it simply makes sense to say the next months will be mostly spent on one or the other. Just need to avoid opening the can of worms that is mixing it up with "simple fixes" inbetween. I'm guilty of encouraging Ruud to do this now and then, as are a few other members. This is where communication is key, because Ruud has the masterplan (hopefully), he knows when and how something is feasible and when postponing makes more sense.

Racer is a longterm project - over ten years already after all - so compare it to commercial titles that have been in the making for half a dozen years or more. It's normal having to update content during such a long time period and it's not going to stop me, knowing it'll eventually have to be redone in a year or two. With that said, dealing with problems should be done with an eye on the long run as well.
I almost passed over this little post...
LOL I started a rant-a-thon didn't I? (All proceeds to the QLD flood appeal).

My point in asking what's so final about 090 is that 090 won't be bug free, Ruud's already said he'd revisit physics et al after 090 Final. Then sometime after that Cg's moving to OpenCL.
As far as I can see 090 will be essentially nVidia only version that while it looks good doesn't drive well, and later beta's will break cars when physics is improved and cars & tracks when we move to openCL based shaders.
I suppose for me it doesn't really matter, track content should last a while (it's going to take time to fix the physics I feel)
 
BUT, loads of these weird bugs have been introduced to slightly reduce the floating when stood till bug.

OK, the floating is an issue, but right now Racer is in a worse 'physics' state for going anywhere near a 'final' because of that change.

I'm just saying if we step back a notch to what is ultimately a better physics version, we can step right back forward again to these new buggy ones post v0.9.
At least then v0.9 has a bit more reliability for content creators :D

Hmmm

Dave
 
On automatic damping, you can set dbg_car.auto_damping to 0 to do your own car.ini based damping: wheel0.tire_model.damping_predict_lat for example.
Only lateral damping is done; the longitudinal is commented out in the code.

The current damping is calculated as follows:

w=car->GetWheel(i);

// Lateral damping
L=w->GetRelaxationLengthLat();
M=car->GetMass();
// Calculate cornering stiffness for nominal load
w->GetPacejka()->SetCamber(0);
w->GetPacejka()->SetSlipAngle(0);
w->GetPacejka()->SetSlipRatio(0);
load=weight; // From earlier weight distribution, around weight/4
w->GetPacejka()->SetNormalForce(load);
w->GetPacejka()->Calculate();
C=w->GetPacejka()->GetCorneringStiffness();

// Estimate damping
gamma=sqrtf(L*M/C);
dampPredictLat=gamma;


@Dave: I've been away for a week so little happened, but the wheels getting stuck I couldn't reproduce. I am running 0832 where before my holidays I added this:

- Differential could become unstable when the 2 wheels got opposite reaction forces.

As for Cg vs OpenCL; I don't see use for OpenCL for quite some time, but perhaps GLSL. Still, the transition from Cg to GLSL would be small; just the extension (perhaps automatically converting shader names from .cg to .glsl).

You can fetch the Racer with that differential fix at http://www.racer.nl/download/racer0832a.zip

I understand the concerns; we're going through a similar process at Cruden, where we want to focus more at stability rather than feature set, moving more slowly as indeed, each added feature seems related to its own can of worms.

On the diff; we had a bunch of internal discussions on the diff locking behavior. We take our example from Milliken's Race Car Vehicle Dynamics book, pg 742 (from the top of my head). If either side has a force negative relative to the other side, the diff acts as an open diff. Still, it's funny how the graph seems to cap at a maximum force, and it's not entirely clear whether the graph should just continue or that a maximum force really exists.

On the friction_road variable; I've taken that out of default/car.ini; it was indeed obsolete.
 
As for Cg vs OpenCL; I don't see use for OpenCL for quite some time, but perhaps GLSL. Still, the transition from Cg to GLSL would be small; just the extension (perhaps automatically converting shader names from .cg to .glsl).

I understand the concerns; we're going through a similar process at Cruden, where we want to focus more at stability rather than feature set, moving more slowly as indeed, each added feature seems related to its own can of worms.

This is reassuring.

On the diff; we had a bunch of internal discussions on the diff locking behavior. We take our example from Milliken's Race Car Vehicle Dynamics book, pg 742 (from the top of my head). If either side has a force negative relative to the other side, the diff acts as an open diff. Still, it's funny how the graph seems to cap at a maximum force, and it's not entirely clear whether the graph should just continue or that a maximum force really exists.

I know what happens when you reach maximum force. The diff housing explodes and there's oil and metal everywhere. Hope this helps :thumb:
 
On automatic damping, you can set dbg_car.auto_damping to 0 to do your own car.ini based damping: wheel0.tire_model.damping_predict_lat for example.
Only lateral damping is done; the longitudinal is commented out in the code.

Even with the v0.8.32 .exe file qlog says that both longitudinal and lateral damping_predict are unused - what is correct now?
 
Even with the v0.8.32 .exe file qlog says that both longitudinal and lateral damping_predict are unused - what is correct now?

From what Ruud posted, it looks like the method for defining the lat damping has changed.

wheel0.tire_model.damping_predict_lat

wheras old content has.

tire_model_front
{
damping_predict_lat=
}
tire_model_rear
{
damping_predict_lat=
}


So we probably need to put in the right reference.


Thanks for the post Ruud. It sounds like there might be a problem, or there might not be, but I guess time will unearth it if it is there.

What happened to damping predict long? Not needed, or done automatically?

Is the auto lat *length* using a single value, or calculating one on the fly? (looks static as the damping value when set to auto doesn't change)


Super last, can the optimum slip ratio/angle values be automated? They change alot under load change and camber changes, and so setting them with static values seems not so ideal.


Maybe the problem is that all these auto values just need to be a bit more dynamic?

Thanks

Dave
 
THX Ruud...this 032a feels a lot better than the 031!
Oh..donuts with faked AWD via Salisbury diff at the rear with 50N Preload...waaaaa what a fun!
screenshot020.jpg
 
mmm, donuts...

hey DF, you have the strange skidmarks I get occasionally, u can see in places its like the skidmark 'mesh' flips in places, leaving a triangular weird pattern occasionally
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 313 15.5%
  • < 2 years

    Votes: 213 10.6%
  • < 3 years

    Votes: 209 10.4%
  • < 4 years

    Votes: 157 7.8%
  • < 5 years

    Votes: 271 13.4%
  • < 10 years

    Votes: 234 11.6%
  • < 15 years

    Votes: 151 7.5%
  • < 20 years

    Votes: 118 5.9%
  • < 25 years

    Votes: 89 4.4%
  • Ok, I am a dinosaur

    Votes: 261 12.9%
Back
Top