Direct lean and auto/manual rider lean L/R

[HornetMaX]

That topic (http://forum.piboso.com/index.php?topic=998.0) raised a few interesting comments concerning a well known situation (bike suddenly losing the front while mid-turn or exiting the turn). After a few tests, I'm convinced there's something wrong going on with auto rider lean L/R.

User chwiej commented this:

Same here.I'm almost giving up.Original bikes are not that bad but it still happends.I play with direct lean on (the only way with wireless xbox 360 controller).I noticed that if you turn off automatic L/R lean off,the problem is gone.WHAT IS GOING ON?It is really annoying,I tried playing with deadzones, smoothing and linearity and nothing seems to help.The other option is to turn off direct lean,but then steering got a huge delay,bike feels like a boat all over the track.I think its a physics problem( virtual rider or automatic lean).

I did a quick test tonight: Mallory 1978 (very good surface, short tracks with few turns for maximum repeatability) on the 600 bikes (4cyl), with my xbox 360 pad.

First with my usual settings: direct lean on + auto rider lean L/R ON
Then with : direct lean on + auto rider lean L/R OFF

Very surprisingly, having auto rider lean L/R OFF changes a lot: the bike movements are less "jerky", the bike reactions look closer to the real thing. It is as if the "jerkyness" of having direct lean ON was coming from the auto rider lean L/R.

Question for Piboso & co: having direct lean ON or OFF will alter the "signal" seen by the algorithm responsible of the computation of L/R rider movements 9when auto rider lean L/R is ON) ?
Alternative formulation: switching direct lean OFF inserts a filter between he joypad output and the virtual rider input. Does this filter affect the input of the auto rider lean L/R too ?
Is it possible that the rider is simply moving (leaning L/R) too fast ?

From what I see it seems that many cases of "losing the front for no special reason" seems to come from the auto rider lean L/R.

Something like: you're leaning right, rider leaning right, you want to pick up the bike. If auto rider lean L/R is OFF, you pick up the bike no problem. If auto rider lean L/R is ON the rider leans too quickly in the opposite direction and in doing so it upsets the front (can't say how, maybe hanging on the handlebars he puts too much effort on the front tire that was already at its limit, don't know) and you fall.

With direct lean ON and auto rider lean L/R OFF, the bike seems slower (compared to direct lean ON and auto rider lean L/R ON) to go from full leaning left to full leaning right, no matter how fast you move your two sticks (one fr the lean, the other for the rider lean). Slower but still very reasonably fast compared to reality I'd say.

As I never play with direct lean OFF I can't comment too much on that situation: I can't say if switching auto rider lean L/R to OFF gives a better feeling or not.
If somebody want to give it a try and report ...

MaX.

[BOBR6 84]

Dont know if this helps.. With direct lean OFF and rider L/R AUTO.. the virtual rider puts too much pressure on the bars when going from full left lean to full right lean.. Or even upright! So its like counter steering whilst fully cranked over.. So the front washes out!

Adjustable steering damper might help calm everything down!

Also without knowing how gpbikes is made (i never will) with physics etc.. Id say move most of the virtual rider influence on the handlebars to the footpegs!

[Hawk]

I absolutely agree with your conclusions Max.....

Klax is one of the few riders to ride a bike totally manually, and when I talk to him about dodgy corners and the front end slipping away, etc, etc, he comes back and tells me that he feels the track is okay. So there must certainly be some kind of issue with the virtual rider and it's inputs to the steering. It's very frustrating at times.

But having said that, for sure rebuilding track surfaces seems to calm down the adverse effects of the virtual rider inputs that seem to be causing the front end to break away on certain corners. Which makes me think it could be the virtual riders response to the collision detection model that is often derived directly from the track surface mesh. Or probably a combination of both virtual rider issues and track surface issues?

BTW... Off topic, but I thought I'd mention it - I can guarantee repeating a core.exe: I just ride over a gap in a track surface(usually at track surface edges) and get a core.exe. from my experience when rebuilding track surfaces, there are many many gaps in the track meshes, most of which you wouldn't normally notice because they are so small and can only be seen at certain angles.

If you want to try it Max, come out of the hairpin bend on Mallory Park 1978 and on the right hand edge of the track as your approaching the last bend you will see were the grass verge ends and a tarmac section starts, there is a gap there at the track edge which if you ride over it you will get a core.exe for sure...... I'd have thought Piboso could use an error catch routine to allow the routine to continue if this condition is detected?

HawK.

[HornetMaX]

But having said that, for sure rebuilding track surfaces seems to calm down the adverse effects of the virtual rider inputs that seem to be causing the front end to break away on certain corners. Which makes me think it could be the virtual riders response to the collision detection model that is often derived directly from the track surface mesh. Or probably a combination of both virtual rider issues and track surface issues?

Could be, but as it seems to happen much less with auto lean L/R OFF, the potential problem seems to be more localized in that part of the virtual rider (I mean auto lean L/R).

BTW... Off topic, but I thought I'd mention it - I can guarantee repeating a core.exe: I just ride over a gap in a track surface(usually at track surface edges) and get a core.exe. from my experience when rebuilding track surfaces, there are many many gaps in the track meshes, most of which you wouldn't normally notice because they are so small and can only be seen at certain angles.

Yeah, that's a known problem. But then, there should be no "balck holes" on a properly built track so can't blame GPB too much for that: the GIGO principle (Garbage In, Garbage Out) is universally applicable

If you want to try it Max, come out of the hairpin bend on Mallory Park 1978 and on the right hand edge of the track as your approaching the last bend you will see were the grass verge ends and a tarmac section starts, there is a gap there at the track edge which if you ride over it you will get a core.exe for sure...... I'd have thought Piboso could use an error catch routine to allow the routine to continue if this condition is detected?

It's not sure, as this kind of things (collision detection) is handled by a third party library (ODE, Open Dynamics Engine) and he may not want to mess with that code.

MaX.

[PiBoSo]

It's not sure, as this kind of things (collision detection) is handled by a third party library (ODE, Open Dynamics Engine) and he may not want to mess with that code.

MaX.

Tyre -> terrain collision is scratch-made for greatly increased accuracy.

[HornetMaX]

It's not sure, as this kind of things (collision detection) is handled by a third party library (ODE, Open Dynamics Engine) and he may not want to mess with that code.

MaX.

Tyre -> terrain collision is scratch-made for greatly increased accuracy.

Ach, I should I've added an "I think".

Anyway, even better then. Any thought on the above stuff ?

MaX.