Racer v0.9.0 RC5 released

[Ruud]

Get it at http://www.mediafire.com/file/zdn8i0kntl3h579/racer0.9.0_rc5b.7z
[URL edited at 16-11-2012, 17:07 for some bugfixes]
Get a racer.exe/pdb bugfix at from http://www.mediafire.com/file/ny6a8gju5oaracb/racer090rc5c_exe.7z (which fixes that braking with locked wheels would give extra force instead of less).

A note about the audio: a bit more is planned to add to audio. Mainly an extra 'noise' sounds for each surface when going off the AI line. Then there's also an idea to use understeer & oversteer values to select samples, instead of taking skid values per wheel, since understeer sounds different from oversteer. Experimental a bit though.

Enjoy!
Ruud

Changelist:
- Ctrl-I now inverts debug readout colors (it used to roll through the debug readout views)
- Onyx compiler improved with bugfixes, type-casting.
- Onyx pointers (hm).
- Onyx now supports float const ('const float x=0.5'), while, for and do-while.
- Onyx supports basic yielding of scripts (coroutines, triggered each frame).
- Onyx internal function abs(), sqrt() added.
- A default Cg shader is created for materials without an explicit shader. To avoid black materials.
- car.ini's now accept wheel<n>.pacejka.negate_camber. Some TIR files/coefficents out there
seem to reverse camber (inverting influence on Fy tire forces). This option inverts camber sign
as it goes into the Pacejka formulae.
- lighting.cg no longer adds Ks (specular) to the ambient term.
- .f32 file support for textures in .shd files; future development for sky colors.
- Added $water_reflection texture map for shaders, in the same way $mirror exists. This works with renderer.water.*
to render a mirror image of the scene into a 2D reflection map, which can be used for a water shader.
See also water_f.cg/water_v.cg in data/renderer/shaders.
To be elaborated.
- The default debug text color is now white again.
- Timing is passed to the Cg shaders in TrackEd for some animations.
- Explicit low LOD steering model removed; use the model LOD available for the regular model (steer.model) (in car.ini)
- Car cameras can explictly turn the steering wheel on or off (camera<n>.steering_wheel=0 or 1). The default is 1 (added to data/cars/default/car.ini).
See also http://www.racer.nl/reference/carphys.htm#campos
- Number of materials in a track raised to 6000 (from 4000) for some nasty import tracks.
- TrackEd's generate template shader generated '<unnamed_QObject>' for unloaded textures.
- Added engine.shifting.cut_ignition in car.ini; instead of cut_throttle=1, you can leave throttle open and cut
part of the ignition instead. A value of 0.5 for example will output 50% of engine torque to the clutch/gearbox/wheels,
so is smoother while shifting.
- Autoclutch during shifting linearized; it was now squared, making for a less smooth experience.
- New combined slip method for tire forces; #7. From Pacejka's book, the Similarity method. Does not require
optimal_slipratio and optimal_slipangle anymore. More info on http://www.racer.nl/reference/wheels.htm#tireforces
- When the tire left the surface, slip angle and ratio were reset to 0. This was not realistic for a bumpy surface,
since you lose a lot of traction when the tire is bouncing a bit. Now it keeps on tracking slipAngle/Ratio.
- Different fonts (Eurostile)
- Added dyn_standard_bump_ao_f/v.cg shaders for ambient occlusion map (much like the mix shaders really).
- After all these years, on Win7/64bits with 32-bits Racer, got PerfKit working with PerfKit v2.2.0.12166 from nVidia ('debug 6 1').
- Added 'float serverTime' uniform for Cg shaders to get (an estimate of) the multiplayer server time. To sync vertex shader effects across multiple PC's.
- Added active differentials basics using Onyx. See http://www.racer.nl/tutorial/differentials_active.htm
- Added a global 'lowpass' DSP option. Mainly used for testing for a future 'muffle' parameter per car to soften incar sounds.
- Added track audio per surface (in special.ini). If not defined, the default global surface type audio is used.
See http://www.racer.nl/reference/tracks_surfaces.htm

------------------------------------------------------------------

Bugs (currently known specific to RC5)

• Gearbox shift times not working properly, step from 0 > 1 clutch position over the time rather than smooth linear transition.
• Water reflection not rendering, needs clarification on functionality.
• Qlog discrepancies (I'll let Boomer clarify those.
• Odd console readouts about tyre slip angles or something popping up (same goes for gearbox manual/auto setting, doesn't need to be console displayed imo)
• PerfSDK not working as advertised, broken?
• Multiplayer joining to IP's seems glitched, the person joining has their brake stuck on and are unable to shift
• The Multiplayer Lobby does not let you connect, and subsequently let you host, despite the right ports being forwarded. (Anyone else experiencing this bug?)
• The particles pop-out of existence at the end of their specified lifetime instead of fading away smoothly. It would be nice to have some better control over the fade-in and out over the lifetime of the particle since tiresmoke starts out thick and opaque then disperses and becomes more transparent over time, while gravel or dirt fades in a bit at first then eventually fades away.
• Smoke flickers in the reflections, as though it's missing every other frame.
• Replay bugs: No smoke effects, ghost car is left on track.
• The starter sound plays all the way to the end of the sample instead of stopping when you let off the starter.
• Ghost doesn't work on endless tracks.
• track special.ini: timeline.point_to_point=1, timeline.auto_return=0 - The auto_return setting doesn't seem to work here. I have a point to point track and the car resets 3000ms (3s) after crossing the finishing line, but I don't want it to.
• No reflection in the Racer garage when selecting a car.
• The unsprung weight apparently applies a downforce, try making a 150kg rear axle with the front
  suspension lighter and the car will act as though it has high downforce when jumping off of a ramp.
• If the wipers are set to rotate in opposite directions then the intermittent position does not rotate back and forth smoothly. It snaps back.
• In RC5c at least, the camera bug is still evident, and on Carlswood (spline based cameras) you can often get stuck so you can't get back to the in-car camera view which is really annoying! - Courtesy of Dave

 

[Mr Whippy]

Thanks Ruud.

I'm really liking this new tyre mixing. The old problem of snappy corrective lock during slides seems to have halved in severity and now feels more natural...
Now that other weird behaviour has been fixed I'd say this new mixing has generally tidied up a lot of the out-standing 'weird' behaviours with tyres and got them feeling really good!

You can really start to enjoy some limit driving now, it's still snappy when you go too far but if you do try catch it it feels more realistic when it returns to straight ahead.
Also donut/burn-out type behaviours feel more consistent with what we see in real life from similar car types!


That sea/ocean shader sounds interesting, I can't wait to see it in action. I'll wait until someone else shows us how it works first though...



A great release I think, thanks again

Dave

 

[Mr Whippy]

Hmmm, downloading new one now...!

Dave

 

[Mr Whippy]

Hmmm, seems a bit better, but it's still braking at 1.2g peak ish, then staying up near 1.3-1.4g when it fully slips.

It should really be dropping off a fair bit. Again, acceleration I'm getting sub 0.5g when accelerating off the line with loads of slip, or 0.7g when doing it feathering the throttle.


For some reason under braking I still seem to 'keep' my grip and not fall off optimum slip ratio.

Front brakes even fully locked now don't seem to get SR above 0.99, while rears go to SR 1.00.

The front SR also appears to drop to around 0.95 just before stopping, over the last half second of a skid to a stand-still.

Also I seem to notice the wheels still rotating when locked up, they always did that since we 'fixed' the floating while standing still issue (not sure the fix was ideal imo), but the fronts seem to spin noticeably vs the rears which are spinning slower and almost can't notice it.


One bug fixed, another appears


Generally moving in the right direction, it does feel better, but this braking thing and spinning 'locked' wheels doesn't fill me with confidence that Racer physics are actually moving towards a more realistic solution


I still get some weird behaviours if I brake while spinning wheels up etc, like they have a rubber band drive-shaft that stores energy... and all this seemed to begin back when we stopped making cars 'float' when stationary... is all that code/damping starting to interfere with things??




Hmmmmmm, look forward to a fix that combines the nicer feeling tyres with tyres that are realistic when you lock them up

Dave

 

[Stereo]

Hmmm, seems a bit better, but it's still braking at 1.2g peak ish, then staying up near 1.3-1.4g when it fully slips.

It should really be dropping off a fair bit. Again, acceleration I'm getting sub 0.5g when accelerating off the line with loads of slip, or 0.7g when doing it feathering the throttle.

One thing to keep in mind is 2 vs. 4 wheels slipping - when braking by throwing a RWD car into reverse, I see SRs of -1.5 as it smokes the tires up, and -0.5g or so. (and then the car does an end over end, so that it's driving backwards in the same direction it was facing forward, and everything settles down)
The same car, under normal acceleration pulls about 0.4g with tires slipping, and about -1.0g with brakes critical, -0.8g when the front wheels lock up.

The same in the Murc's 4wd gives a peak of about 0.7g accelerating while slipping, and -0.7g when in reverse (although slipping less than when accelerating).


Observation of the wheels when jamming it into reverse while doing 100+km is interesting too - they almost immediately get down to 0, speed up to maybe -1km/h, and then stay at that speed until the car's moving quite slowly, at which point they spin up as normal, given wide open throttle.

 

[Alex Forbin]

The water shader is really a sea/ocean type indeed. Actually, the water displacement requires a lot of work to use a couple of noise layers. They are mimicked in C++ to be able to do water height detection. Anyway, that's another story. ;-)

There's an updated (full version) at http://www.mediafire.com/file/zdn8i0kntl3h579/racer0.9.0_rc5b.7z

That fixes the trackcam sequence, the braking bug and has a TrackEd with visible buttons.
The braking turned out to be a small (but relevant) change in slip angle calculations; for wheel velocity, it took angular velocity*radius, instead of velocity above the road. That does not work nicely when blocking the wheel, which was what gave the big slip angle when blocking the wheels.

So the water shader doesn't work yet?

Alex Forbin

 

[Mr Whippy]

One thing to keep in mind is 2 vs. 4 wheels slipping - when braking by throwing a RWD car into reverse, I see SRs of -1.5 as it smokes the tires up, and -0.5g or so. (and then the car does an end over end, so that it's driving backwards in the same direction it was facing forward, and everything settles down)
The same car, under normal acceleration pulls about 0.4g with tires slipping, and about -1.0g with brakes critical, -0.8g when the front wheels lock up.

The same in the Murc's 4wd gives a peak of about 0.7g accelerating while slipping, and -0.7g when in reverse (although slipping less than when accelerating).


Observation of the wheels when jamming it into reverse while doing 100+km is interesting too - they almost immediately get down to 0, speed up to maybe -1km/h, and then stay at that speed until the car's moving quite slowly, at which point they spin up as normal, given wide open throttle.

I've just done a test using a script to keep the SR's at certain values by switching brakes on/off.

These are my results:

-11.017mss at 0.11sr
-11.072 at 0.12sr
-11.0671 at 0.13sr
-11.0396 at 0.14sr
-10.93 at 0.15sr
-10.961 at 0.16sr
-11.001 at 0.17sr
-10.888 at 0.18sr
10.77 at 0.19sr
-10.839 at 0.2sr
-10.426 at 0.22sr
-10.55 at 0.24sr
-10.152 at 0.26sr
-9.985 at 0.28sr
-10.196 at 0.3sr
-10.171 at 0.35sr
-10.017 at 0.4sr
-10.4792 at 0.45sr
-9.999 at 0.5sr
-10.122 at 0.6sr
-10.232 at 0.7sr
-10.359 at 0.8sr
-10.027 at 0.9sr
-13.598 at 1sr

I'm not sure if this is fair, it is hard to test, but why should I get a near flat response irrespective of SR from 0.11 > 0.9... and then as the wheel approach 'stopped' it gets all that extra grip?

They were all 90mph to 0 stops in neutral jamming the brakes hard (very strong brakes so near instant activation of the script)

Confirmed values in SR readout and system variable readouts.




My hunch.

Something is going wrong. I have a feeling Racer deals with 'stopped' wheels as special cases, so when you stand still and things the car doesn't float off (cars used to drift around after 10mins or so, maybe 5m away from where they were!)
But I have a feeling that system is interfering in dynamic situations and wheels simply do weird things when they have to pass near the "0" velocity states...

I'm not sure of course, but we've all been driving Racer for years, and seen bugs come and go and fixes come and go, and I was never happy with Racer in some regards since that 'floating car' fix came in.
Lots of odd behaviours with wheel forces winding up and stuff appeared.

Just the other week I had set a dynamic script for brake balance and if I did a burn out while holding the brakes on, after stopping the burn-out and releasing the brakes the rear wheels would spin the other way at high speed for as long as the burn-out lasted!

Some seriously dodgy stuff is sitting under wheels near 0 speed and brakes, and I'm not such a big fan of that if it's costing us realism in dynamics.

Racer isn't about sitting still watching a car float around very slowly, it's about dynamic realism



Considering pacejka curves usually drop off after SR 0.12 ish, the result should be a sudden increase of SR to ~ 1.0 and the resulting drop-off as shown in pacejka player, usually around 10-15% of deceleration rate.

Going UP almost 30% is just completely wrong no matter how you look at it.


Dave

 

[Mr Whippy]

Just tried it in 0.8.44 of Racer with the same car/pacejka.

Get up to almost 1.1g when braking harder and harder, and then as soon as I breach SR 0.13 ish the brakes lock, my deceleration drops to about 0.865g, and as I slide at SR 1.0/0.999 (on the front/rears) all the way to a stand-still it stays at about 0.86g deceleration.

So I can brake at about 1.1g peak if I keep around 0.12SR, as soon as I go over it, the tyres lock up and go to SR1.0, and I lose about 20% of my tyre braking force.



It's just wrong now. There is no doubt about it.

Dave

 

[Ruud]

Hmmm, seems a bit better, but it's still braking at 1.2g peak ish, then staying up near 1.3-1.4g when it fully slips.

It should really be dropping off a fair bit.

Could you mail me the car? I'll have a look at it after I get back... (perhaps earlier, since it might affect my visit in fact ;-) ).

BTW I tested this with 'debug 1' as the readout to check SA. As SA was getting high upon braking, I got extra lateral tire forces. The locking scheme then looks at Fx & Fy, takiing the length and creation a force vector of -wheelVelocity*(Fx,Fy).length, so pointing it backwards. But as SA grew, I got Fy>>0, which meant a *higher* total force when blocking.

 

[Alex Forbin]

Also I seem to notice the wheels still rotating when locked up, they always did that since we 'fixed' the floating while standing still issue (not sure the fix was ideal imo), but the fronts seem to spin noticeably vs the rears which are spinning slower and almost can't notice it.

Dave

I actually had someone that doesn't normally drive Racer mention that the other day. I
dismiss a lot of things with the assumption that I'm seeing things no one else will.
I still say that a model that doesn't allow for energy dissipation through friction/heat will be a compromise.
Hopefully this can be integrated in the new brush model tire.

Alex Forbin

 

[Mr Whippy]

OK, fresh install.

Set lambo brakes to braking_factor 1 all round, 5000 front, 3000 rear for max_braking force.

Drive down drag strip, hit brakes, lock up wheels, 1.4g deceleration. Obviously turn ABS off for all testing!


Now set the front brakes to about 1900 and rears to about 1700 so they just lock up at full braking at the front, and you can only hit around 1.1g before locking up... and when you do lock up, the g's stay about the same.
Fronts locking and rears at about peak slip ratio.


NOW, if you up the rear brakes so they lock up too, about 1900 brake force at the back, then when you finally lock up all the wheels (SR of the rears rise up to near 1), then the g's move slowly up from -1.1g to about -1.3g as the rears finally approach SR1.0.


So it seems that the forces are shared both front and back (not a bug effecting just the front pair or something). Ie, add more tyres at near SR1.0 and you get improved braking performance vs if those wheels are at optimal SR.

Fronts SR1.0, rears SR0.1 = 1g
Fronts SR1.0, rears SR1.0 = 1.3g



I'm not sure if I'm going mad here but I thought it was almost the fundamental basics of tyre physics that if they go beyond optimal slip ratio you lose grip and reduce braking performance.

Load up the same car in an older version of Racer and suddenly we get the behaviour we expect again. Tyres running SR over optimal and you tend to stop about 15-20% less effectively! Not 30% more effectively.


It's as plain as day on all cars. Lock up all the wheels hard and you get oodles of deceleration. You won't notice it if you run ABS or don't run strong brakes, but that is hardly a reason for it to be ok. It's fundamentally really really really really really wrong

Dave

 

[Alex Forbin]

This might help on the water shader...

Fri Nov 16 16:18:09 (WARN ): [racer] Game has no camera component - can't render water reflection [rscene.cpp:3438 / RScene::RenderWaterReflection]

Alex Forbin

 

[boomer541]

A couple of bugs:
Qlog error:
RCamera: camera1's offset and offset_to are too close - move them apart [rcamera.cpp:332 / RCamera::Load]
My camera code
camera1
{
name=Drivers Seat
offset
{
x=0.389
y=-0.300
z=0.100
}
angle
{
x=0
y=180
z=0.000000
}
follow
{
pitch=0
yaw=1
roll=0
}
model=0
wheels=1
fov=70
}

Any idea whats wrong? I get the same on other key cameras as well.

Replay >>>>> Don't

Thanks for the update Ruud!

 

[Ruud]

OK, fresh install.
Load up the same car in an older version of Racer and suddenly we get the behaviour we expect again. Tyres running SR over optimal and you tend to stop about 15-20% less effectively! Not 30% more effectively.

With older, you also mean 0.8.44?
I just redownloaded both 0844 and 090rc5 and tested like this:
- Lambo car.ini: abs.enable=0, max_braking added a '1', so wheel_front.max_braking=12100 and wheel_rear.max_braking=11620.
- Same car.ini: set braking_factor to 0.5 for all wheels (I moved it to 0.8/0.2 in 090RC5b to avoid the Lambo flipping every time you brake).

I then:
- drive on the dragstrip (Shift-P) upto 100 on the dial
- brake
- I look at gforce_lon and with Ctrl-1 at Grip2/grip3.

My results are the same with v0844 and 090rc5 really: grip goes up from +/- 1.2 to full lock (SR=-1) to grip=1.6, although it sometimes seems erratic a bit.

So really the same base problem (force increasing with SR=-1). The difference is that in v0844 I also see slip angles increasing a lot, which explains the force increase there (since with full lock, force=-slipVelocty*pureForceLength).
In 090rc5 that slip angle increase was fixed, but it still does it. I'll look into that further today...

But I don't really see a change when doing this test between 0844 and 090rc5.

[EDIT] When trying combined slip model 2 (void) things restrict to ~1.0 grip at locked braking, hm.

 

[Mr Whippy]

But in 0844 you can't brake to a stop faster by slipping all four wheels. You have to moderate the brakes to get optimum slip ratios and stop at near 1.1g. If you brake too hard and LOCK UP all for wheels I get 0.8g deceleration or so.

Same car in 9rc5b and you can just lock up and stop almost 20% faster!


I'm not sure why you can't see a difference, I'm changing back to the old racer.exe, racer.pdb, and racer.ini files to do these tests.




I'm guessing you have spotted that a problem exists, it's just isolating it?


Thanks

Dave

 

[Ruud]

It seems in v0844 you should also have the problem, but I tracked the problem down in 090rc5. Get the latest racer.exe from http://www.mediafire.com/file/ny6a8gju5oaracb/racer090rc5c_exe.7z

Two things I've found:
- slip angle got negated in combined slip when braking (slipAngleEq=slipAngle/(1+SR), and SR<0).
- The tanh trick to reduce braking torque when the wheel is already standing still worked on all car velocities. This meant at high velocity, locking the wheels would start reducing brake torque, which would give a jittering ABS-type of thing. First I took it out completely, but with big brakes that gives jittery wheels when braking hard when standing still. I re-inserted it, but modified it to work only at low velocity (<1m/s).

Now, I appear to get correct behavior again; high deceleration, but when braking very hard, grip goes back to ~1.0-1.1 (note that 'grip0-3' is just F-tire/load, so a bit like effective 'mu').

 

[Mr Whippy]

Sounds great Ruud!

I'll test this afternoon as much as I can and report back.

Lets hope this is finally fixed now

Cheers

Dave

 

[Mr Whippy]

All obvious stuff seems remedied.

Funny that in some regards it doesn't feel much different now to how it was pre new-mixing... there is a subtle improvement in some behaviours.

I think now some fundamental problems are fixed we can hopefully start to tune the coefficients available for lxal and lyka etc, to try get the behaviours we expect when the tyres get pushed out of their optimum ranges



Seems the cameras have gone back to car/track/heli/disco/track cycle again, so we have two track camera instances in the cycle here.

Obviously one of the fixes you made earlier didn't make it into this latest version





PS, I do seem to now have that old surge behaviour back where I get a little pause every second and FPS dip about 30% at each little pause... it's kinda annoying...
Is this due to the change back from the higher priority on the processing?

Is there any way I can change this back to how it was? It pretty much makes Racer a novelty rather than a usable sim/game when it's jerking like that during actual racing.

I've upped priority a step at a time and it kinda reduces the strength of the surges but they are still there.

Hmmmm


Dave

 

[KS95]

Just to add what was pointed out in another thread, I haven't tested in RC5 yet but I imagine it's still there. It's near impossible to reverse when on grass, it just won't move unless you give it revs and drop the clutch, lol. Have noticed this in many cars.

 

[Stereo]

Just to add what was pointed out in another thread, I haven't tested in RC5 yet but I imagine it's still there. It's near impossible to reverse when on grass, it just won't move unless you give it revs and drop the clutch, lol. Have noticed this in many cars.

In the Simca that happens even on pavement, whatever force is stopping the wheels overpowers the engine when trying to start reversing. I'll have to test for it in 0.9.0RC5. (edit Yep, still present in RC5c.
Switching over to debug 8 gives a hint... the autoclutch might not be trying very hard. It's strange behaviour though - it's like the clutch and throttle are both getting cut, cause RPMs don't rise even though the clutch is 80% slipping.

The capital letters of the new font look like they get cut off a few pixels early on my PC.

 

[Cosmo°]

The reversing issue seems to be related to the differential as well - vehicles that show this behavior are - from my testing so far - using either type=0 (open) or type=1 (viscous). Switching to type=4 (locked) for example always cures the problem (tested on various cars including the Aronde, Tatra 613...). Manual or automatic clutch don't make a difference here.

Differential response has changed noticeably with the combined slip updates, in general the slip limiting types are opening earlier and/or are less likely to lock up. Not sure yet if this is good or bad, more testing required.

I'm also seeing the framerate fluctuations Dave reported.

boomer mentioned replays - the first time I recorded a replay last night it didn't work (picture was stuck on the first "cut" mark for the duration of the selected length), but loading the replay file again from the menu made it work and all other attempts afterwards as well.

The qlog error on camera position is bogus and boomer mentioned it some weeks ago already, I guess some internal check is using the wrong camera type reference?

I'm not so keen on the new font for readability reasons as well, what was wrong with the old type, apart from being old