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

 

[Alexander Knoll]

I tested it some time agoo, and with hamachi it works well...and this was the onlyest way i got it working...

 

[Mr Whippy]

I play occasionally with Cosmo and it usually works ok for us.

But it doesn't feel like a finished feature yet.

I'd hate to think how slow the FPS would be if a 3rd person joined.

Part of that is optimised content but I still think somewhere that Racer GFX engine isn't optimised properly. Something somewhere feels to just suck resources big time. I'm not sure what it is and until we get PerfSDK working right (I've tried exactly as per Ruud's instructions, though I can't get the same version as him because it's not available), it's gonna be hard to see why we get such shocking FPS.

However you look at it, even on a flat grey track with 10 flat grey cars I get less FPS than Shift 2 with a full grid and proper content

Dave

 

[Stereo]

I think you can set up and play a game if it's hosted and you share your IP with joiners to direct connect... just make sure the firewall is open for the correct ports.

It is temperamental though...

Worked ok on my LAN, with 1 minor note - you have to Shift+R on the host after everyone else has joined, or they're stuck in 'waiting for the green light' unable to move. Haven't tried network multiplayer because synchronizing vehicle/tracks is hard.

With respect to framerate, simulating 10 cars seems to make the physics side of things cut into my framerate - CPU's too busy on that for as much graphics. It's not as bad in multiplayer since it's only estimating where the network player is.

 

[tormento19]

Worked ok on my LAN, with 1 minor note - you have to Shift+R on the host after everyone else has joined, or they're stuck in 'waiting for the green light' unable to move. Haven't tried network multiplayer because synchronizing vehicle/tracks is hard.

With respect to framerate, simulating 10 cars seems to make the physics side of things cut into my framerate - CPU's too busy on that for as much graphics. It's not as bad in multiplayer since it's only estimating where the network player is.

Tried it and went right Waiting for a new beta, or a small fix to switch on some good Racer servers! Many months without news from Ruud..

 

[Raphael Buthmann]

Just the fact of Racer being mono-threaded is extremely gfx unfriend. since cpu acts on graphics too. My gpu is stucked at 45% of use with everything maxxed out , and I get sometimes 46fps , sometime 140...

 

[Mr Whippy]

Yeah I think that can be causing some of the speed issues we have.

Racer seems very sensitive on FPS and on most tracks if you are not running 100fps or so then it's suddenly down at 40fps.

On my system it either seems to be fast or slow, almost like as soon as some specific limit is hit (possibly the processor is starting to struggle), then the FPS shoot right down to about 40fps, but then I can add literally hundreds of more batches and over a gig of textures (more than my VRAM) and I still get 40fps!


So yes, maybe that is one of the core problems. Racer is quite heavy on the CPU so if the CPU is dragging FPS down despite plenty of GPU speed it's not so great.


There are some options in the head of Racer.ini for multi-threading etc, but I'm not sure exactly how Racer manages these things.

If Racer is indeed just single core then there is no wonder FPS are so low for us guys...

I wonder if it's possible to put scene prep for GPU onto a different core to the physics/game engine?!

Hmmmm

Dave

 

[Stereo]

If you go to Ctrl+6 output, "Main Thread Core" + "Physics thread core" (only visible when running multithreaded) tells you where Racer's running

What you'd do is for example,
process.cpu_affinity_mask=3
process.main_thread_affinity_mask=2
physics.async=1
physics.thread_affinity_mask=1

This runs physics on core 0 and the main thread on core 1.
Notably rsx scripts don't seem to work with async physics enabled.

I have seen better FPS from setting the main_thread_affinity_mask - roggel goes from 25fps to a solid 60 (vsync on). Not sure if the async physics helps or not.

 

[Mr Whippy]

Ah ok, might have a play with some of these settings then, thanks Stereo.

Would be nice if Racer could auto-detect this stuff and optimise automatically.

I wonder about the GPU elements that are on GPU though, ideally that could be sent to another core again!?

I wonder how other games deal with all this stuff... I guess coding an application to run across several OS and run multi-threading gets quite heavy, but even for Win users on the now vogue multi-core systems it seems essential for good performance.

In theory my current CPU is no better than the one I had back in 2004 if Racer is only properly using one core

Dave

 

[Mr Whippy]

Wow, nice work Stereo.

Just loaded a 44/45 fps track here and with those changes I'm getting 56/61 fps.
A bit more variation in fps just sat still, but a solid jump!



Though I still feel there are issues with fps in Racer generally.

Ie, I recently turned off shadow map blurring because it seemed costly on my high fps tracks (90fps > 100fps turning it off), but on my low fps tracks it would go from maybe 44 > 46fps... maybe the percentage is about the same but I didn't think it worked like that for the shadow map blurring at least.

I also turn down the sampling to 2 too, rather than 4. Again I can see the benefit of this more on the high fps tracks to begin with, but on tracks that always seem to 'settle' around 45fps on my machine (Roggel etc), then changing these settings doesn't make so much difference.

It almost feels like the fps is a function of something other than the GPU on those tracks... and in this case at least it seems that perhaps it is... with the CPU free'd up the GPU can turn out the frames faster...!

Wheras I bet on the faster tracks the GPU wasn't restricted by the CPU so much.


Hmmmm...

Dave

 

[Mr Whippy]

Uhhh, but no scripts

Good old Racer

 

[Raphael Buthmann]

I'm just waiting a game that uses Cuda+CPU+Graphics.

It would be awesome. LOL

Cuda or OpenCL....well...yeah

 

[camsinny]

So you can use 3 GPUs?
Buying 2 is expensive enough!


Thanks for the settings Stereo, I'll give them a go later on tonight.

On a sidenote:

I recently bought a Fanatec Clubsport wheel:
http://au.fanatec.com/RacingWheels?product_id=266

Feels absolutely fantastic, racer's a little bland when it comes to FFB and I'm prepared to mess around a bit until it feels right, however that's not my issue at the moment.
The Fanatec guys did a stellar job with everything except the LEDs. They don't really work without some middleware:
http://www.fanaleds.com/

It appears to use Outgauge to talk with RoR, but I've no idea how to make it work with racer, anyone with any ideas please chip in!

 

[Mr Whippy]

Yeah, it's strange specular-like light. If I understand normalmapping correctly, the 3 color channels correspond to the du, dv, and normal vectors - texture mapping coordinate system is important to getting it right. It's tricky math to keep in my head, and I forget how Racer does all the rotations.

Shadows are enabled and it's in shadow, so it shouldn't be getting lit up that way. I haven't tested if it's actually coming from the specular term or somewhere else. It's at least relative to the right light source.

I believe the non-blurred area behind the car is 'cause it stops when it finds a 'non-moving' pixel (which is good, otherwise it would blur the car outward), it's just that the ground's moving so fast that it hits those from quite a distance away from the body. It might also be discarding too much of the blur - been a while since I looked at the details.

As far as I can tell, the modifications I made in RC3 did get passed along to RC5, with one exception...
Line 171 of motion_blur.cg was added.

color=i*tex2D(sceneMap,tc0).rgb;

It addresses a real problem with my code but is the source of the non-blurred area. When you comment it out, you get this.

The velocity map isn't quite hitting the edge of the car, so it gets this 'ringing' every so many pixels. I believe it's cause it gets partway between the pixels, which averages out the speeds - one's not moving, one's at 100km/h, so it doesn't think the pixel's slow enough to stop the blur. It does need a more aggressive method but the code above is obviously not perfect either, since it's saying "object is near something stationary; do no blurring at all".

Dropping the last 2 pixels when it hits an edge would be smarter but I'll have to think harder cause my naive attempt at doing that resulted in it dropping the original pixel sometimes, too (resulting in an output of no pixels)

Hi Stereo,

Did you ever get any where with improving this?

I've currently commented it out and it's much better as an overall compromise.

I wonder why Ruud added the extra line because it just made one visual problem that wasn't so bad into an even bigger visual problem that is very bad

Dave