Lots of weird things happening in Racer physics.

[Mr Whippy]

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

 

[fsr]

I've found the donuts to be a pacejka (slip angle) issue. Lower b0 to 1 or 1.1 and it's much better...

Working on the drift Supra I've also isolated a few issues. The main one being combined slip and slip angle. Even though the current pacejka might have it's limitations, these problems were not nearly this bad with older versions of Racer. The tires actually feels way better back in 05xx betas than the latter ones.

If I should try to explain the problem, it's like the combined slip curve flattens at some point. The more longitudinal grip you take away by either locking up or by wheelspin, the less lateral grip you should have. However, it's like when you reach a certain slip ratio, it no longer affects lateral grip. For me, that makes my drift car straighten up/understeer when I'm flooring it in fifth, spinning the rears at 200kmh+. Trust me, a real car would not straighten when you do that!

My way around this problem at the moment is to set a high optimal slipangle for the rears (0.26). This sort of moves the effect to a degree of slip that I hardly reach, but it's still there...

Another issue I've noticed is body inertia. I'm running values three times higher than normal to get normal behavior. I'm not sure if it's the inertia calculations that are off, or if this effect is caused by something else and the increased inertia just dampens some other bug, but with "normal" inertia values the car is almost undrivable. Still, this may not be an inertia issue, but that's the "fix" I found.

 

[Alex Forbin]

Ruud has stated elsewhere that Pacejka breaks down at high slip angles and that he's looking at other tire models. Possibly a brush style which is also the one I like too.
I must admit, I've never seen the effect that Dave shows, where the front tires get stuck.

Alex Forbin

 

[Mr Whippy]

But as FSR said, I can't really remember some of these issues rearing their heads in older versions of Racer.

Adjusting the optimal values does change some stuff, but I'm not sure how/why. They do influence smoke generation and when sounds play too. I'd prefer these values to be calculated or generated on the fly by Racer, rather than being fixed values. They change quite a lot in the pacejka player at high loads and diverse cambers.
That alone might be the reason many things are weird feeling at the limit of the pacejka?


I believe the inertia tripling to get normal behaviour, is sensible to dampen out the flicking back issue, but I think the flicking back issue is because the tyre forces at high slip angles/ratios are mixing badly too. You just seem to get a HUGE dose of lateral grip flicking the tail the other way when you correct a slide, almost like the lateral damping isn't there.
The transition point just seems immediate. Maybe when we used to define the lat/long damping coefficients we did a better job than Racer is? Is Racer even doing them properly?


Then there are the braking wheels not actually braking issues, as per my original post/video. That isn't pacejka related. It's just a new addition to fix a problem that wasn't really a problem unless you sat watching cars when stationary for minutes on end, and now it's resulted in loads of weird transition behaviour, when starting from stopped, but also with locked wheels.

Ie, stood still, clutch in, full brake, full throttle, dump clutch, and the front wheels just spin as if your not braking at all. No braking is even seen. How can Racer be even half realistic when brakes don't brake?


There are some big fundamental bloopers creeping in and a new tyre model won't fix weird things like not working brakes

I'm positive for the new tyre model and it's possibilities, BUT, I'm worried that there are big issues, similar in nature to the old RC height bug, or the only recently fixed CofG bug (which wasn't really fixed, more the offset feature nullified by making everything have no offset)... all were around for years, we all knew something was a bit fishy, but they were ignored.

I think Racer is getting to a point in it's maturity that when we know things are a bit fishy or just plain wrong, they need proper fixes... *especially* coming up to v0.9... these finals so far come along every six years or so, so it's a good idea to get this one REALLY solid.


For me, if it means rolling back the most recent 'fix' (which I call a 'break'), which is the floaty cars when stood still 'fix', so we get back proper working brakes, then that is a reasonable thing to do. All I can do is keep making it show dodgy car behaviours. Before the fix, all I saw was a car float very slowly when stood still over a minute or two, but no dodgy behaviour when the cars were actually moving.

Just a frustration as it shows Racer is broken, and as soon as Racer appears fallible, you question if problems are your values related or just bugs.

A few of us appear to have spent a week or so with this to no avail with nicer realism, using old 89 pacejka and new MF5.2. That isn't ideal if no one can create a car.ini they will be happy with moving into v0.9...


I know it's a time of transition, but this braking wheels not actually braking thing is a perfect example of why we need to slow down with these physics changes a bit.
I'm happy to test things but many of these things are done with little information to help us check the issues etc etc... and we might just end up with a pile of interacting bugs and have no idea where the problem is.
For years we wondered if our pacejka was the cause of dodgy handling on some cars with reasonable geometry settings, but no, it was a dodgy CofG offset implementation.

We really need to get past this type of Racer, and get into a solid way of improving and checking physics changes moving forward. One at a time, well documented, and tested lots before new changes are made, so each one is assured to be reliable and working before adding more fuel to the fire

Dave

 

[Stereo]

Then there are the braking wheels not actually braking issues, as per my original post/video. That isn't pacejka related. It's just a new addition to fix a problem that wasn't really a problem unless you sat watching cars when stationary for minutes on end, and now it's resulted in loads of weird transition behaviour, when starting from stopped, but also with locked wheels.

Ie, stood still, clutch in, full brake, full throttle, dump clutch, and the front wheels just spin as if your not braking at all. No braking is even seen. How can Racer be even half realistic when brakes don't brake?

I don't have the separate axes (stuck with a mouse for now) but I've noticed that the gears have trouble when the wheels are already moving the wrong way - eg. the car's rolling forward in reverse, or the wheels are just spinning, I need to brake down to 0 before the throttle will do anything. It seems like the clutch should be able to start from any original wheel speed to the engine speed, but either it's not applying right or just not working.

I guess this is what you mean with the donuts? (note F-lat-2,3 are near zero, the car completely stopped rotating for a second)

Dropping b0 from 1.35 to 1.0 made this much less a problem, but also seems to limit the SA to around 30 degrees, which is fairly odd to drive. As soon as it's exceeded, huge lateral forces push the back of the car into line.

If I increase max_slip_len in racer.ini, it goes back to the original behaviour, where it stops about every 180 rotation.

 

[FiftyOrange]

I've tested the problems mentioned, and also have all of them. I've also noticed the inertia issue, and my initial thought was that it could also be down to the CoG, as well as the CoG issues themselves..?

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.

I get this too. Because I drive a Holden Clubsport.

 

[Cosmo°]

Once again I have to agree with Dave on this - we're all used to and (up to a point ) happy to find reasons for odd behavior, but it just gets frustrating if things change without notice or adequate documentation given.

Since the welcome additions of summer 2008, plenty of odd bugs turned up that took a lot of testing and repeated inquiries to get a hold of. Few of them were as obvious as the recent differential issues where you notice the effect right away.

Ruud has mentioned that the priority for v0.9.0 are to be the graphics. They are quite well developed by now and only a few oddities remain to be fixed (say, night skies not being completely unlit for instance). As such, it would make sense to concentrate on Cg and all that has to do with it, while leaving physics for the time after that.

The "fixes" we got recently, merely blurred the original issues while introducing new problems at the same time. Like Dave, I'd rather go back a step or two with differentials, low speed floating etc and have a proper, fresh go at that stuff when v0.9.0 is out and everybody can concentrate on fewer things instead of squeezing them in for that illusive final

 

[FiftyOrange]

Have a final, something we're supposed to develop reliable quality content for, with major flaws in the very foundations of the physics?

 

[Cosmo°]

Well, I won't restrict myself to a final version when newer betas will be released. So, as long we have progress and improvement in those areas, the version number is of little interest to me

Ruud decided a while ago that for v0.9.0f the focus lies on visuals and that's fine. Just now the situation is that he still did a little something here and there on physics, but that turned out to be giving us more trouble than good.

Right now we can choose between an open differential, a fully locked one or a selection of broken ones that magically spin the wheels in opposite directions. Under that light, I'd rather not have "those" differential types around for the final.

It's no good adding features and fixes on top of a questionable structure - ie, introducing fudge factors for low speed behavior instead of looking at why braking is implemented as a "rearward facing force" instead of a friction principle.

There are enough examples of this, but the point is that in order to get things working Ruud needs to be able to focus on them and share the relevant information with us so we can efficiently and quickly test and confirm functionality.
If it always takes us a month or a year (as in the CoG offset case) to get anywhere because we have no idea what has actually been done behind the scenes, then that is a real problem for content creators.
If it means trading static for dynamic stability, in this case warping of a standing car versus skid behavior of a moving vehicle, I'd rather be driving

 

[DavidI]

I don't see other sim's having similar tradeoff's between static & dynamic stability. I don't have the same issues with cars standing still in GT5, x-plane doesn't have planes float around on the tarmac. Does RFactor have similar issues?

I'm also wondering whether it's going to be worth the effort of releasing 090 content. So 090's a graphics update, then we will get physics improvements, and some time after that Ruud's going to move Racer from Cg to OpenCL.
I can only assume that OpenCL will break a lot of the Cg we have, as that is what has happened previously with major improvements in Racer.

 

[FiftyOrange]

I don't see other sim's having similar tradeoff's between static & dynamic stability. I don't have the same issues with cars standing still in GT5, x-plane doesn't have planes float around on the tarmac. Does RFactor have similar issues?

I'm also wondering whether it's going to be worth the effort of releasing 090 content. So 090's a graphics update, then we will get physics improvements, and some time after that Ruud's going to move Racer from Cg to OpenCL.
I can only assume that OpenCL will break a lot of the Cg we have, as that is what has happened previously with major improvements in Racer.

Where's the button to agree with this post?

 

[eschefo]

Some questions to this discussion,
first is, why this thread are not in "Racer problems & fixes" or "Racer physics"?
second is, as I'm relatively new (a year), Which versions are bad versions? I use 0.8.8 and doubt to load one of the newer. Are all the newer worst?
third is, that in this year with RACER, I see more graphics changes than physics changes, and I think the goal of RACER is that we can experiment with vehicle dynamics. For example, is curious that the brakes go red with hot but there are no effect in braking force. Graphics over physics.
I hope physics were improved in future vesions.....

 

[DavidI]

Where's the button to agree with this post?

There used to be one, dunno.

I suppose the question really is, what is so FINAL about 090 final? As I see it, after 090, near future updates to both physics & graphics will break a lot of 090 content again.

 

[FiftyOrange]

0.8.8 is a good version to go with. I still keep a loaded copy of 0.8.7 because it's the last one that works flawlessly for me.

Trouble is, if Ruud works on physics, a lot of stuff gets broken, bugs from previous fixes arise, and it all gets a bit messy, as it is currently, and it takes a lot to fix - then there's the issue where we say what we want is more graphics options. So the graphics are looked at, again, a lot of stuff gets broken, but while physics have to be fixed, it's easy for Ruud just to dismiss graphics issues as just being outdated content; update the Murciélago and f**k all the content that was released last month.

 

[Cosmo°]

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.

 

[Some1]

I suppose the question really is, what is so FINAL about 090 final? As I see it, after 090, near future updates to both physics & graphics will break a lot of 090 content again.

Well, the new final is important for the modders. So they can finally release something that works and looks good. Also, the final should be tuned to work on most computers while having, of course, minimal system requirements etc.

With the rate that new betas are released and this change so rapidly, we can never release content that would be usable at least for a while.

Each new feature in Racer brings new bugs, things that worked previously are broken etc - you know how this is.

I remember a 4-5 years ago, new betas came out much less frequently and modders had the time to finalize their content for (usually the latest) Racer.

 

[Cosmo°]

It's true that when there were fewer releases for a given time frame, content creation was also more of a steady process. On the other hand, I remember sitting there over some bug, sometimes for half a year, not getting anywhere because of this lack of response and dialog with Ruud.

Perhaps this points us to a release schedule where every 12 months or so a final comes out, which consists of the findings and improvements of the regular development betas that are more frequently released? People who don't want to bother working things out can use that and the others might enjoy better driving or nice visuals for a while (as well as dreadful bugs ), before everbody catches up again for the next final? It wouldn't change much for Ruud, other than using our feedback to put together those features and fixes into said final version, that were proven to work, maybe once a year.

Maybe we already have this - we as the community can simply post a thread with recommended versions and that's it. A few betas back, many of us agreed that the we happy with the state of things and we called it a final candidate - but then more "fixes" came and we're back at square one now.

This might as well be a classic "have the pie and eat it" scenario - either you want progress (a moving target), or stability (means not getting the latest features)... but:

Each new feature in Racer brings new bugs, things that worked previously are broken etc - you know how this is.

This is the problem we need to avoid. There will always be teething issues at first, but we need to look at the implementation of new features and how to deal with bug behavior properly. It shouldn't be normal to have this one step forward, two steps sideways and one-and-a-half steps back case.

 

[Alex Forbin]

I definitely DON'T want to go back to the "good old days" of an update every 6 months (or less) I've been very happy with the way things have been progressing in the last year. 9.0f is relevant only in the fact that is will have a basic feature set that people can develop for. I'm a bit concerned that we haven't had a release in over 2 weeks now.
I think the reason we see previous bugs cropping up time and again, could be nothing more than the fact that this is now a 10 year project, that's a LOT of coding/revising. Maybe it's time that Ruud brought up some of the old issues from the past that were merely patched or not fully understood and let us try to find definitive answers once and for all.
As far as the issues that Dave is having, I have not run into these myself. Since I haven't I would expect the problem to be in something that I don't normally use such as...
ABS
traction control
engine mapping
launch control (this will randomly cause the rear wheels to spin like mad even with the engine off, reset is the only fix)
4WD ( I do in fact use this some, but only for 4WD and not for AWD)

As far as developing for a moving target goes, we could have an adopt-a-car scenario where you picked a car to keep updated. This would somewhat eliminate the "bugs" on our end and not slow down Ruud with trying to figure out if the problem is his or if we just dropped the ball. If someone got tired of working on a car all they would need to do is find a new foster parent for their baby.
I just really don't want to fall back into the stagnation that we were in for a few years, I don't think Racer would survive it again.

Alex Forbin

 

[Mr Whippy]

I just think quick fixes that don't get a proper checking, are not ideal.

Ruud has fixed things before, but they were not right, and had bugs that took years to spot. The issues were often simple, just no one spotted them.
That is down to us to spot them much of the time, but it needs to be made easier for us to spot them by Ruud offering us either a really good problem/change heads-up, so we can check out the fix properly and make sure it's working.

I'm all for rapid improvements, but we need REALLY good information now to help us spot if fixes were done correctly.

A good chunk the reason little content is made is because people spend weeks or months trying to make their content work despite problems with Racer. FSR's drift car is finished as far as I can tell, but he is going around in circles trying to make the physics right... same here with my M3 revised for V0.9, and the Murcielago, revised for V0.9. Both do weird things and I'm just not happy with them. MF5.2 is an option to solve the issues, but then MF5.2 doesn't seem to be implemented properly or fully yet, or has bugs in there.


You only need to check the changelog to see what has been spotted or fixed or re-worked to see LOTS changes. If even 10% are fixed with bugs still evident, we have a big pile of bugs still sat in Racer that we need to spot to get fixed.

It's a good job that the CofG bug have been fixed, it was as big a problem for future content as the old RC height bug. The use mesh hits working now offers loads of improvements for content.

We need to actively find problems and fix them when we find them. The solution to streamlining that right now, running up to v0.9, is for Ruud to keep us really well informed of what he is changing so we can check it, and NOT to add anything new, without telling us how it's been added in respect to other things, so once more, we can check it (ie, this floaty drifty tan force reduction thing for brakes/spinning wheels seems a bad implement and it's just breaking lots of things around 0 wheel speed (check my other YouTube videos))


We just need some order to the chaos. We can check from one version to the next shader changes (just go read them), and by doing so I spotted quite a number of issues as versions got changed... but physics we can't do that, and as changes pile up pinpointing bugs becomes a HUGE task.
We could be more efficient and remove bugs much more easily if we simply had a bit more structure to the changes, ie, info on what they are, why they were broken, how the fix has been implemented etc, so we can check them with controlled tests.


Ultimately WE need to check for these bugs, because Ruud misses lots of them. I just think we can help each other out by structuring these checks/changes better to streamline physics development
Personally I'd rather be making content and setting it up well, than spend entire weekends driving around in circles tweaking racer.ini coefficients and using silly numbers in my ini to try pinpoint problems in MY numbers, when the issue might just be a minus sign in the wrong place at Ruuds end

Dave

 

[KS95]

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.

Yes! We need some better documentation, not every big topic seems to be covered properly, and what is, isn't done very well!