Racer v0.9.0 RC5 released

Ruud

RACER Developer
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
 
I can drive on grass with clutch control perfectly.

My Z4 will roll backwards or forwards without any throttle just like, err, real life, just bring it up slowly and away I go. Same ease on grass or asphalt or auto-clutch on or off.

I can run it open, or viscous at a low setting like 5.




As per the camera but, I'm not sure how costly it would be but part of me would like to define the camera as the one you want, rather than it being inferred from the properties you expose to it.
If that can be done cheaply then it makes sense imo. Otherwise it'd be like having the differential settings not set by the 'type' setting, but set by which fields you entered or not.

Makes sense to define the diff specifically, so why not cameras? Hmmmm... :)


As per the font, it looks ok to me generally, it's a readable nice font in design circles. It's just too small, or doesn't scale down well in this application.


Cheers

Dave
 
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.
...
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.
...
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?

The cam selection might have been since I'm now working on my home PC, and had trouble updating the source from work. That's fixed now.

I do have the FPS dip here on my ATI card as well. I've swapped over the racer.ini from my development environment, and here that gives a MUCH cleaner FPS signal.
Try 'graph 0 200 manager.fps' while running Racer to get a nice view of what's going on.

I'm attaching my racer.ini that gives me the smooth fps; I'm running out of time at the moment to figure out the exact change that is responsible (perhaps multiple?). Perhaps you can find it (I'm away for a week). Try that racer.ini instead of your current racer.ini and see how that does, then use 'inidiff' to track the changes.

[EDIT] Did track it, seems to be the mirror texture.enable=1?! Hm.
 

Attachments

  • racer_ini_stablefps.txt
    69.7 KB · Views: 1,115
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.
Huh, interesting. The open differential's even worse - the Aronde has a good chance of failing to get moving even when doing a clutch dump at full throttle.

Since we have the option for active differentials now I'm gonna play with those a bit, see how they handle this problem.
EDIT: An open active diff has the same issue, so I guess it's coming somewhere behind the diff outputs, in whatever handles diffs with a locking torque.

Did notice an inconsistency in the 'torque out ratio' - when both wheels have torque in the same direction, the ratio's always larger than one (divides higher torque by lower torque), when the wheels have torque in the opposite direction, the ratio's dependent on which wheel it is. ie. for out0 torque 400, out1 torque -200, it's a ratio of -2, for out0 torque -200, out1 torque 400, it's a ratio of -0.5.
GFIEa.jpg

Reverse gear has an overall ratio of -20.96, which is why 48 at the clutch is -1007 Diff torque in.
 
The cam selection might have been since I'm now working on my home PC, and had trouble updating the source from work. That's fixed now.

I do have the FPS dip here on my ATI card as well. I've swapped over the racer.ini from my development environment, and here that gives a MUCH cleaner FPS signal.
Try 'graph 0 200 manager.fps' while running Racer to get a nice view of what's going on.

I'm attaching my racer.ini that gives me the smooth fps; I'm running out of time at the moment to figure out the exact change that is responsible (perhaps multiple?). Perhaps you can find it (I'm away for a week). Try that racer.ini instead of your current racer.ini and see how that does, then use 'inidiff' to track the changes.

[EDIT] Did track it, seems to be the mirror texture.enable=1?! Hm.

Hehe, toggling mirror in Racer here and it doesn't seem to make the 'heart rate monitor' effect go away.
Not done much testing here but the FPS readout shows the issue very nicely, thanks!

Hehe, SVN updating issues?

I'll have a play and see if there is anything I can do to smooth the line and then let you know if I find it!






I'm driving around on my grass on Elvington fine here with the Simca Aronde, the only thing I've done is turn auto-clutch off (so it can stall) and it doesn't stall.

Set off in 1st slowly, reverse very gently with only slight throttle feathering.

Just done a burn-out on grass in 1st and reverse.

Hmmm, using open diff in reverse does seem to pose a problem though haha :D

The Simca does seem to be using the wrong diff entry too, but even swapping for the right bits and pieces it won't work too well.

So yes, deffo an issue here somewhere!








My 2p/thoughts again on these recent bug-fixes or fixes of fixes that fixed things :)

A long time ago Racer cars would float around when stood still. Some people had an issue with this but for me personally, I couldn't give two hoots. Racer is a driving sim, not a parking sim.

Yes it suggests stuff isn't right when weird things like floating 15m down the road every 5 minutes happens with the car switched off, but personally I knew that when it mattered, when wheels got in motion, stuff worked.

But since the day this issue was fixed (not sure how exactly), we seem to have had a stream of weird issues related to wheels doing odd stuff when stopped/changing direction.



For example.

My rwd car with viscous diff (low setting around 5)

Reverse back end onto grass.

Front end on tarmac.

Put in reverse.

Apply foot brake.

Clutch pedal down.

Rev balls off car, dump clutch.

Spin rear wheels in reverse, with fronts holding still on tarmac.

Now clutch in, release throttle. Let everything settle.

Now release brake.

Weeee, rubber band drive-shafts and a load of stored energy comes from nowhere :D



Now back when we got rid of 'floaty' cars I was VERY suspect about all these weird problems that suddenly began happening.

I posted loads of examples on YouTube of car tyres/wheels just being weird. I remember Ruud added the tanh brake fix to try alleviate one of the problems, and that today was causing issues with braking (now only comes in at under 1m/s)
Clearly some of the impacts of the floaty fixes are still with us today, and even things added to fix problems the floaty fix brought with it (ie, the tanh one) are showing up as things that need reviewing now!

Despite fixes we still see weird things, as this example above proves. And no doubt as time goes on I'll just spot more examples like above appearing in testing. Can't reverse a car on grass with an open diff, that'll be floaty fix related I bet!

There is something fundamentally fishy going on.


Part of me would really like Ruud to re-visit and sense-check what he did back when he 'fixed' floaty cars, because whatever it was in my opinion was done in haste and done badly!

Back to floaty cars or a proper fix to this issue is what I'd like to see :D




All in the most constructive sense possible of course. Ruud does a great job, but that 'fix' those years back does seem to have haunted us since.
To have it finally wrapped up and that dark chapter of funny wheel behaviours gone would be nice :D


Cheers

Dave
 
The Simca does seem to be using the wrong diff entry too, but even swapping for the right bits and pieces it won't work too well.
Did spot one definite contributing factor - gearbox.gear0.inertia=0.9 was way too high. Set it more like 0.07 and there's enough torque to get over whatever the hump is around 0 on pavement. It's pretty obviously a lot worse in R than 1 though, in terms of getting started moving.

And yeah it's using differential{} instead of differentials, fallback lets it work normally so I hadn't realized it needed to be updated.

On grass/gravel, the diff torque brake reads higher, and is flipping signs depending whether the wheel's going forward or backward. Probably the extra braking is why it's tougher to get it moving, and rapidly changing signs in a 200 N-m force might not be a good thing.
 
I tried Ruud's racer.ini and indeed, it gives smoother framerates. So, half an hour of going through each relevant difference between my standard racer.ini and his, I can safely say that at least here on my PC auto_exposure is the culprit behind spikey performance.

Here are some of the interesting results:


max_anisotropy=8 -> 65~70fps; =16 -> 85~89fps (not a typo, higher value gives higher framerate)

auto_exposure.time_per_sample=100 and auto_exposure.enable=0 -> 85~89fps; =1 -> 74~91fps (spikes!)

auto_exposure.time_per_sample=500 and auto_exposure.enable=0 -> 65~70fps; =1 -> 75~103fps (more spikes!)

motion_blur.velocity_map=1 and motion_blur.sample=4 -> 91~95fps; =8 -> 85~90fps

motion_blur.velocity_map=0 and motion_blur.sample=4 -> 97~103fps; =8 -> 92~96fps


note: I'm running fs_filter1=bloom_shadows_f.cg instead of the standard _blur version, so the last two lines surprised me a bit.

edit: Obviously I tested this with consistent car/track/camera combination and placement, fresh starts of Racer inbetween and mostly two separate attempts to get these numbers.
 
Oh the sadness. Crash as default..

Sat Nov 17 23:10:04 (INFO ): [racer] Crash detected - attempting to recover some data before displaying the crash dialog [main.cpp:97 / crashProc]
Sat Nov 17 23:10:05 (FATAL): [racer] Exception 0xC0000005, flags 0, Address 0x63E60AEE
(this dialog text is stored in QLOG.txt)

OS-Version: 6.1.7601 (Service Pack 1) 0x100-0x1

0x63E60AEE [nvoglv32]: (filename not available): DrvPresentBuffers
0x63E6075C [nvoglv32]: (filename not available): DrvPresentBuffers
0x636653A5 [nvoglv32]: (filename not available): (function-name not available)
0x63DD985C [nvoglv32]: (filename not available): DrvPresentBuffers
0x6364B90F [nvoglv32]: (filename not available): (function-name not available)
0x6364BB39 [nvoglv32]: (filename not available): (function-name not available)
0x6364C816 [nvoglv32]: (filename not available): (function-name not available)
0x6367192A [nvoglv32]: (filename not available): (function-name not available)
0x636718B7 [nvoglv32]: (filename not available): (function-name not available)
0x63CC8648 [nvoglv32]: (filename not available): (function-name not available)
0x6367177C [nvoglv32]: (filename not available): (function-name not available)
0x63CD1548 [nvoglv32]: (filename not available): (function-name not available)
0x63CD20A5 [nvoglv32]: (filename not available): (function-name not available)
0x63CD271E [nvoglv32]: (filename not available): (function-name not available)
0x6371987E [nvoglv32]: (filename not available): (function-name not available)
0x004528E6 d:\source\trunk\dev\src\libs\d3\dtexture.cpp (line 853): DBitMapTexture::FromBitMap()
0x00452B53 d:\source\trunk\dev\src\libs\d3\dtexture.cpp (line 749): DBitMapTexture::DBitMapTexture()
0x0046C05B d:\source\trunk\dev_racer\src\lib\rmanager.cpp (line 1720): RManager::Create()
0x00403816 d:\source\trunk\dev_racer\src\mrun.cpp (line 1830): Setup()
0x00403FD1 d:\source\trunk\dev_racer\src\mrun.cpp (line 2234): Run()
0x0040161F d:\source\trunk\dev_racer\src\main.cpp (line 271): main()
0x004016A3 d:\source\trunk\dev_racer\src\main.cpp (line 278): WinMain()
0x0059D32B f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (line 263): __tmainCRTStartup()
0x762133AA [kernel32]: (filename not available): BaseThreadInitThunk
0x778B9EF2 [ntdll]: (filename not available): RtlInitializeExceptionChain
0x778B9EC5 [ntdll]: (filename not available): RtlInitializeExceptionChain [%s]
 
auto_exposure.time_per_sample=100 and auto_exposure.enable=0 -> 85~89fps; =1 -> 74~91fps (spikes!)

auto_exposure.time_per_sample=500 and auto_exposure.enable=0 -> 65~70fps; =1 -> 75~103fps (more spikes!)
It looks like FPS goes down when you increase time per sample?! I imagine that's due to restarting Racer and it running less effectively though (there's an ongoing bug on multicore processors that sometimes it chooses poorly) .The auto-exposure calculation's definitely one thing that can cause spikes though; I set it to 5000) which makes it slow to react but good enough for most purposes, and also doesn't hurt the framerate much.
 
It looks like FPS goes down when you increase time per sample?! I imagine that's due to restarting Racer and it running less effectively though (there's an ongoing bug on multicore processors that sometimes it chooses poorly) .The auto-exposure calculation's definitely one thing that can cause spikes though; I set it to 5000) which makes it slow to react but good enough for most purposes, and also doesn't hurt the framerate much.

Good catch - I did wonder about this too, but must've had some rotten luck because even now, restarting a few times it went at lower framerate quite often for both settings (and several times in a row when I made the first run of measurements and couldn't get a high framerate). "Normally", framerate is indeed at 98~103fps with either setting and enable=0 it seems.
 
One thing is to understand the flow of the tire forces: the only inputs to tire forces are really load, slip angle and slip ratio (let's ignore camber for a moment). Load seems ok.
SR and SA are sliding values (not instantaneous) to account for relaxation length. So with the rubberband thing, check Ctrl-1's screen. SR can be seen to grow to 1.5 when dumping the clutch. It seems to have a hard time getting back to 0; if you release the brakes at this stage, you'll get the SR=1.5 jolt until SR=0.
Not that it is realistic, it's just easier to track what's going on.

The diff's a bit of a separate story; with an open diff, nothing really happens, there is no locking so it's like there is no diff. Hence the finding that an active open diff doesn't change anything, because there really isn't any.

More investigation after next week!
 
I do the same thing Cosmo/Stereo, I set my update speed to about 3s or so for AE and it's just as good most of the time... possibly more like the human eye a bit rather than super fast.

As I said in the past though, digital SLR cameras had good metering years back, even when processing speeds were really slow.

I wonder if there is a way we can have metered type AE where we have say 16 on-screen points and one is sampled every frame, and then every 16 frames we have a rough idea of the composition of the scene, then we look it up against a reference library of exposures vs meter images, and choose the appropriate exposure to use?!

Not sure how you'd go about it but it seems sensible to use something more like what cameras use rather than simply taking the single point value of intensity for the scaled down view?
At least with metering across many areas of the screen, if you have a bright single spot you can tend to ignore it more for instance, or a super dark spot etc...


Any way, that is a job for another day I guess :D


Dave
 
Me
It looks like FPS goes down when you increase time per sample?! I imagine that's due to restarting Racer and it running less effectively though (there's an ongoing bug on multicore processors that sometimes it chooses poorly) .The auto-exposure calculation's definitely one thing that can cause spikes though; I set it to 5000) which makes it slow to react but good enough for most purposes, and also doesn't hurt the framerate much.

I don't use autoexposure at all since it give me very strange lighting that's impossible to correct.

Alex Forbin
 
Ruud what could be possibly wrong in your development cycle that causes bugs that were just fixed to re-appear?
Not complaining, just wondering since it's bound to be a PITA for you.

The camera cycle problem is back in the newest version.

Alex Forbin
 
boomer: Ah, that is actually "the other" recent replay bug, where the replay will start briefly but stop playing after a second or so. You simply have to press play (onscreen menu, or P on your keyboard) in that case and it will work. It only turned up a few versions ago, maybe v0.9.0 onwards?
My previous reply was on the fact that I couldn't record a replay properly on the very first attempt with the new Racer beta. After setting my cut markers and pressing record, the image was stuck on the first frame, audio ran through the length of the selected clip, but the .avi file was indeed just a stationary image. Sorry for the confusion, boomer.
 
Ruud what could be possibly wrong in your development cycle that causes bugs that were just fixed to re-appear?
Not complaining, just wondering since it's bound to be a PITA for you.

This was due to our office switching to fiber instead of ADSL, after which my home PC couldn't update SVN anymore (source). So the small fixes inbetween weren't there yet on my home PC.

I've uploaded my latest exe (which should include the camera fix again since SVN is working again) at http://www.mediafire.com/file/3tkacnke4bqr42o/racer090rc5d_exe.7z
 
Thanks for correcting that awful version 090rc5c Ruud!

I'll try again Cosmo.

Minor Qlog error:
Loading screen image (data/tracks/ring2002_cold_day/loading.jpg) doesn't have power of 2 dimensions - may stretch [ui.cpp:72 / rrFullScreenTexture]

1024 x 768 IS a power of 2!

They must be square, ie. 1024 x 1024, etc.
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top