Racer v0.8.19 is out

[Ruud]

It's at http://www.racer.nl/download/racer0.8.19.zip . I won't have much time the coming 3 weeks so hopefully there's enough to play with.

Known issues:
- the README in the zip mentios log-averaging for luminance, but in fact that didn't work as expected, and I'm just adding RGB values now.
- Shadowmapping smCor[] is being worked on to be more stable.

For those who missed v0.8.18, here are the changes since v0.8.17:

v0.8.19 (27-08-10)
------------------
- The cubemap camera position was wildly off, giving incorrect culling of objects in the reflected
environment often. This also fixed the appearance of seams in the cubemap sides.
- Using glGenerateMipmap() while loading textures - supposedly faster than using GLU.
- Switching free shifting and up/down shifting is now automatic. The default mode is still
stored in the data/controls/presets files for the initial gear.
- Auto exposure downsampling is now down without mipmaps but FBO's instead
(data/renderer/fullscreen_shaders_hdr/luminance_downsample_*.cg). Mipmaps was not working ok.
- In Ctrl-2 you can now see the luminance and RGB values of the rendered image. This to debug
sky values (the values shown represent a kilolux value).
- Auto-exposure is now working ok, so the TOD editor now also has an exposure factor next
to direct exposure (only useful without auto_exposure). This factor is multiplied with the auto exposure calculations, so even if the auto exposure is trying to get a nice lit image, you can bring it down at night (purposefully under-exposing).
- Used Stereo's ToneMap function to desaturate dark colors. Also added a blue-shift for night scenes.
- Cloud color is multiplied with lightAmbient (sky color) in the sky shaders, so the clouds are now
more visible and don't need 'clouds 7' hacks.
- Auto exposure 'steps' setting has been replaced by 'time_per_sample'; it used to be framerate
dependent.
- Controller lock can now be specified (data/controls/default.ini). Used it on a G27, setting lock
to 900 in the controls file and in the Logitech Profiler software. Setting it lower in Profiler just gives a mild software-controlled lock which is not too useful, so I just leave it at 900.
See data\controls\presets\logitech_g27_racing_wheel_usb.ini for an example (joystick0.lock=900).
Set the car.ini's steer.linearity to 1.0 preferably. Now, the steering lock will match that
of the wheel directly.
Racer caps the steering lock to what the car can do (car.ini's steer.lock), so for this feature
you really need a capable (900 degree wheel), otherwise you won't be able to make the degrees required for the car to turn fully.
The default controller lock is 0, so people with less capable wheels can still play (probably setting linearity for the controller to around 0.5). In that case, the full range of the controller maps to the full range of the car's steering wheel.
- Per track TOD loading; the track can contain a tod/ directory. Curves that are not defined
are loaded from data/renderer/tod.


v0.8.18 (20-08-10)
------------------
- The Lobbyserver wasn't updated to use the new ENet version, so older version could connect
but were refused, and newer versions couldn't connect. Fixed.
- Autoexposure formula revised to exposure=gradient/luminance+offset. Thanks to Colin Pan.
It's much better but somehow the scene luminance doesn't seem to be calculated correctly
for non-power-of-two resolutions (glGenerateMipmap).
- Added a 'loading' or 'busy' indicator (data/images/loading_*.tga and the loading.indicator_pos setting)
- Rain was invisible in bright times of the day
- Some particles were dark as a result of the switch to klux lighting
- Tonemapping (in hdr.cg) used a 0.1 factor - removed that and for auto_exposure this means
gradient should be set to ~1.0 instead of ~10.0 (exposure=1/luminance).
- Added special.ini parameters under 'sun': azimuth_offset (rotation wrt North),
year, day, month, latitude, longitude and timezone. The sun XYZ TOD curves disappeared.
See also http://www.racer.nl/tutorial/newtrack.htm#sun
- Added 'sun azimuth <x>' command to change north angle live.

 

[luthobu]

Thanks, but no go.. at all (cg).. but no-cg seems to work fine.
Maybe I should just stick to no-cg.. *shrug*

Fri Aug 27 16:56:17 (INFO): [noqapp/3356] --- application start ---
Fri Aug 27 16:56:17 (INFO): [noqapp/3356] 2 processor(s); setting affinity to 0x3
Fri Aug 27 16:56:17 (INFO): [racer/3356] Racer version: 0.8.19 (Aug 27 2010/14:43:17) - customer: Internet
Fri Aug 27 16:56:19 (INFO): [racer/3356] DGPUShaderManager::Init() Geometry shading is not supported on this card (ATI?).
Fri Aug 27 16:56:19 (WARN): [racer/3356] DGPUShader:Load(data/renderer/shaders/empty_f.cg): CG ERROR : "The profile is not supported."
Fri Aug 27 16:56:19 (INFO): [racer/3356] WorldRenderer: you have an ATI graphics card (ATI Technologies Inc.). Working around some long-term bugs.
Fri Aug 27 16:56:20 (FATAL): [racer/3356] Exception 0xC0000005, flags 0, Address 0x004BAE83
(this dialog text is stored in QLOG.txt)

OS-Version: 6.1.7600 () 0x100-0x1

0x004BAE83 d:\source\trunk\dev\src\libs\world\auto_exposure.cpp (line 116): WorldAutoExposure::Create()
0x004C5243 d:\source\trunk\dev\src\libs\world\renderer.cpp (line 487): WorldRenderer::GetProperties()
0x004B72E6 d:\source\trunk\dev\src\libs\world\scene.cpp (line 165): WorldScene::LoadSettings()
0x004237AF d:\source\trunk\dev_racer\src\lib\rmanager.cpp (line 805): RManager::Create()
0x004032A8 d:\source\trunk\dev_racer\src\mrun.cpp (line 1554): Setup()
0x0040384E d:\source\trunk\dev_racer\src\mrun.cpp (line 1900): Run()
0x004014EA d:\source\trunk\dev_racer\src\main.cpp (line 235): main()
0x00401563 d:\source\trunk\dev_racer\src\main.cpp (line 242): WinMain()
0x0053A02B f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (line 263): __tmainCRTStartup()
0x74E33677 [kernel32]: (filename not available): BaseThreadInitThunk
0x77159D42 [ntdll]: (filename not available): RtlInitializeExceptionChain
0x77159D15 [ntdll]: (filename not available): RtlInitializeExceptionChain

 

[Mr Whippy]

Looks like some good fixes there Ruud.

I've been noticing the broken envmap issues more recently and was going to mention it but it seems it's fixed, yay!

Also good news on the steer lock for 900deg wheel users!

Also great news on the exposure fixes, and then a small correction factor for fine tuning if needed.

And good news on the clouds fix (would be cool to try those normal mapped clouds soon too!)

And finally tod per track is a nice addition...!




Hope you have a constructive three weeks!

Dave

 

[Some1]

Very good release!

Is it possible to change, how fast the exposure adapts? Right now, it takes about 200 ms to change the brightness level, but human eyes take quite a while to adapt I think...

 

[Mr Whippy]

I think renderer.auto_exposure.filter_gain=0.05 was the value to change, but it's done elsewhere now it seems.


Few quick feedbacks.

Interior shadows are now nice, yay!

Outside there is a weird issue at a longer viewing distance where the car shadow is lagging behind the car and updating only a few times a second, so at 100mph it's lagging behind maybe 20m before being re-drawn.

Much like LOD which is biased for FOV, should the shadow step distances also work like this so that a car approaching a narrow FOV camera from a long way away gets good shadows in it's small angle of view?

My FPS seem to have dropped a bit (maybe 5-15%). Does the Racer development team have a 'benchmark' scene that can be used to quickly check the FPS change with graphics settings/shader/shadow changes etc?


The weird SMD camera offset issue seems to have gone (bad offsets in 0.8.18)


The bloom looks really nice!


Exposure control is still not ideal. It needs to weight more for the ground, or less for the sky... somehow. Driving along and my eyes will expose for the road above all else, so although there is a bright sky up there, my priority is the road! If my eyes prioritised the sky while driving I would end up crashing often
This issue mainly arises with a relatively low sun (ie, anything but summer months at my latitude) and driving towards it.



Generally positive moves forward! Nice work!

Dave

 

[Stereo]

Just a minor thing but could we specify the shadow model separately from what is displayed?

Just using the RX-7 as an example, the interior is basically a stripped version of the exterior (it also has better quality textures on the dashboard). Anything that's not on a line of sight from inside the glass was removed.

It obviously won't cast the right shadows since bottom 1/3 of the car is gone, and the roof is inaccurate since it's only got the lining.


Since it appears this version's lasting a little longer I may try to work out what's wrong with chrome/glass shaders this week too. They're definitely not correct but I need to do a side by side with an old one to see what's wrong.

 

[MitchVL]

Outside there is a weird issue at a longer viewing distance where the car shadow is lagging behind the car and updating only a few times a second, so at 100mph it's lagging behind maybe 20m before being re-drawn.

"It's not a bug, it's a feature !"
set the "shadowmapping.profile0.splitrenderjump" values to 0 in racer.ini, this costs frames though

Some code-optimizations have been made today, which led to a 20% performancegain on my computer (On Ruud's computer slightly less.
I don't know if the optimizations made it to this release though... Ruud?

 

[KS95]

Some code-optimizations have been made today, which led to a 20% performancegain on my computer

Wahoo! It's so nice to hear that! xD

 

[Stereo]

Heh, managed to blow out the sun to #INF, which caused a bit of an exposure issue.

The black spot is actually the infinitely bright reflection of the sun... which makes the exposure level 0 and thus overexposes up to the limit (I'm not sure why it doesn't darken).

I'm not really sure what should be done to prevent the sun being infinitely bright, though...


I've made some progress on the glass issue, just need to optimize the code and I'll post a suggestion.



EDIT:
Okay, modification to dyn_standard_reflect_window_f.cg:

  shadowColor=FresnelMix(shadowColor,envColor.rgb,Kr,fresnel);
  // throw in glass stuff
  shadowColor.rgb += (1-baseCol.a)*envColor.rgb*Kr; // boost reflection where material's more transparent
  float retAlpha = min(baseCol.a*fresnel/fresnelBias,1.0f); // add alpha by fresnel
  //shadowColor = diffColor.rgb;

First and last lines are present in the original, insert the 3 intermediate lines.

// outColor.a=baseCol.a;
outColor.a=retAlpha;

Replace instances of the first line with the second line (should be two).


Also, in car.shd, the glass material should have something along the lines of

  fresnel
  {
    bias=0.2
    scale=0.8
    power=3.0
  }

Problem with chrome was on my end, so ignore that I've fixed the offending texture.

 

[DavidI]

Noticed a bug, if theres a ghost car on the track 'L' key turns ghost car's lights on & off instead of your car's.

Also, driving around Broken Springs, the collision forces can explode, the lambo at times can launch into space. Now THAT would add some excitement to your shopping trip! Hit a pole, and suddenly here comes jupiter, there goes mars. Darn, the eggs exploded.
It may in part be due to the nose of the Lambo getting wedged under the gate or fence bars and exploding out, as it doesn't happen all the time only sometimes. In real life, the nose of the Lambo, the post, or both would exhibit some degree of give (more likely the Lambo's nose giving $k worth of give hehe), whereas in Racer they are undeformable objects with no give.

 

[Mr Whippy]

Uhhh, I'm confused.

Isn't glass now using:

vf_glass
{
vertex_shader
{
file=dyn_standard_reflect_window_v.cg
}
fragment_shader
{
file=dyn_standard_reflect_window_f.cg
}
}


shader_windows~vf_glass
{
cast_shadow=0
reflect=1.0
layer0
{
blendfunc=blend
map=windows.tga
}
layer1
{
map=$trackenvmap
}
}


As per the Lamborghini Murcielago shader?


This seems to be working ok here fine, even looking through the glass at my track decals and so on, interior and the exterior shadows working as expected etc. I thought this was 'the way' to do glass now, also thus avoiding the nasty dotty finish that is apparent using alpha to coverage?!



Mitch, as per the shadow stamping delay at a distance, how much FPS cost/gain are we looking at? Is it worth setting up a benchmark scene to determine the costs associated with these different things? I'm sure already this version is slower than the last one, and this time delay issue wasn't evident on the last version either... so it *seems* like we have slowed down the update on far objects AND lost fps this time... was this in return for better quality shadows in interiors and smoothing the split boundaries etc?

I'm still seeing banding at steep angles, which isn't always because of a low sun, but can also be because of the glancing angle down the side of a car which is then self-shadowing itself.

Looking forward to these shadows being finalised and optimised, then we can test the speed against the old system to see if we have gained in FPS and visual quality

Dave

 

[Stereo]

It's more about what the window is reflecting than what the structure of the shader is. The default Lambo shader does need some work (glass frames are 100% transparent instead of being 100% opaque) but I guess that's more a specific car issue than a shader problem.

Glass especially at high angles goes near 100% reflectivity - you don't see through it at all. The default shader doesn't do this, it maintains transparency at any angle. Unless it's in front of something dark, you don't pick up the reflections.

Top is mine, bottom is default. It's more meaningful in action, I guess - but easier to just try it out than to mess with uploading something to youtube.

 

[Mr Whippy]

Hmmm, what other settings is the Lambo using? Reflect = 1 to get the full reflection at glancing angles? (not even sure if that is needed, just copying what Ruud has used)

Also I'm using ~ 230 rgb for the diffuse channel of the glass and the same for the alpha channel... the standard Lambo may be different.



It's hard to tell here because it's partial overcast but full sun and sharp shadows, but I've just had a look outside and my Z4 glass can't 'look' like your new glass shader... it's surprisingly transparent in real life, but also reflective. Yours looks too opaque while gaining that reflective punch.

The Lambo pic below you posted (Racer standard) looks wrong though I do agree, but I think that is a function of the bad texture settings. Try pumping the glass parts to about 230rgb and 230alpha and I'm sure it'll look much more natural.
Also check reflect=1 in the shader!?


Not sure why it makes a difference etc, but here on other cars (with interiors that you can see through the glass (the old Audi S3 someone released a while back, quite nice with good shaders!)) it's looking really quite good with the settings out of the box, but with whiter brighter textures

Dave

 

[Stereo]

I didn't touch the Lamborghini at all so it may not be the most suitable.

The Aronde's glass shader which I took more time back in 0.8.7 getting real numbers to look "right" goes something like

vf_glass
{
  vertex_shader
  {
    file=dyn_standard_reflect_window_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_window_f.cg
  }
  fresnel
  {
    bias=0.2
    scale=0.8
    power=3.0
  }
}
shader_glass~vf_glass
{
  sort_offset=10
  reflect=0.8
  shininess=20
  specular=0 0 0 1
  layer0
  {
    map=glass.tga
      blendfunc=blend
  }
  layer1
  {
    map=$trackenvmap
  }
}

The Aronde's glass texture is a dark greenblue though - what I think should be consistent with a glass block of sufficient thickness, the 'color' of the glass.
I think the envmap's sunspot is enough and additional specular is too much but that might be opinion. It's really nothing complicated here.


Reflect=1.0 in general seems to be bad, I think because the diffuse light is not being removed by it anymore.

That is, the old sequence:
light = lerp(ambient + diffuse, reflect)
the new sequence:
light = lerp(ambient, reflect) + diffuse*shadowmap

Since diffuse doesn't fade out when reflection hits 1.0, you end up with extremely bright reflective glass (like the Lambo).

 

[Mr Whippy]

Gah, getting confused now.

What each channel does is confusing.

Alpha seems to control reflection strength, and rgb seems to control opacity?!

But then as you approach white alpha it suddenly goes opaque anyway, despite rgb being set to black.

Black rgb + black alpha = no reflection and totally clear.

White rgb + white alpha = reflective and opaque.

White rgb + black alpha = no reflection and totally clear.

Black rgb + white alpha = reflection but very straight on (glancing is still nice reflection), and opaque.


So erring towards black alpha seems to make it see through, so thats good for glass.

Not sure then what rgb does, but it also seems to be best erring towards black!?


I guess then that alpha is doing transparrency, and the rgb is the tint of the glass?!


But using a dark alpha for transparrency, and a dark diffuse for the colour tint (what 'colour' is glass haha), and it just looks really bad. Grrr.

Dave

 

[Mr Whippy]

I didn't touch the Lamborghini at all so it may not be the most suitable.

The Aronde's glass shader which I took more time back in 0.8.7 getting real numbers to look "right" goes something like

vf_glass
{
  vertex_shader
  {
    file=dyn_standard_reflect_window_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_window_f.cg
  }
  fresnel
  {
    bias=0.2
    scale=0.8
    power=3.0
  }
}
shader_glass~vf_glass
{
  sort_offset=10
  reflect=0.8
  shininess=20
  specular=0 0 0 1
  layer0
  {
    map=glass.tga
      blendfunc=blend
  }
  layer1
  {
    map=$trackenvmap
  }
}

The Aronde's glass texture is a dark greenblue though - what I think should be consistent with a glass block of sufficient thickness, the 'color' of the glass.
I think the envmap's sunspot is enough and additional specular is too much but that might be opinion. It's really nothing complicated here.


Reflect=1.0 in general seems to be bad, I think because the diffuse light is not being removed by it anymore.

That is, the old sequence:
light = lerp(ambient + diffuse, reflect)
the new sequence:
light = lerp(ambient, reflect) + diffuse*shadowmap

Since diffuse doesn't fade out when reflection hits 1.0, you end up with extremely bright reflective glass (like the Lambo).

Hmmmm, do you get much diffuse from glass? I thought it didn't really diffuse because a, it was highly polished, and b, has very low opacity.

If you remove reflections, even with lots of light around, glass can essentially be invisible, hence walking into glass doors.
Saying that glass has diffuse response and that reflection = 1 is a bad setting, seems a bad direction to go in.
If we want things to respond realistically they need to use real numbers, and glass is a mirror at 90deg (as is anything even slightly off lambertian response, just holding my matte looking white paper up to the sky, against the blue sky it's a sharp blue line, and against the white clouds it's a sharp white glow)
For almost ALL materials that use the envmap, they should really use reflection=1, and use the fresnel terms to adjust the response of the reflection. At 90deg as said, almost everything is a mirror, and gives off 100% of the light that is incident back at you (ie, ~ 100% reflection strength)


I agree, "sharp" specular has no place when the HDR sunspot is around in the envmap... it's handy for simulating soft reflections though, but that doesn't seem needed for most glasses anyway



I've been struggling with this mixing with the car paints generally. It feels like the underlying paint impacts the intensity of the envmap that goes over the top. Ie, the environment can be white all around (white box lighting), but with a strong sun light at one side... the lit side of a pure black object reflecting the envmap appears fairly correct, but the shadow side still seems to show a 'dark' reflection, despite the reflection being the only thing in the scene (since the black object will pick up no light, only the envmap reflection will show) and it having equal intensity all around the car.
It's almost like the envmap is being 'illuminated' by the incident light, be that intense diffuse on the lit side, or the darker ambient on the unlit side.

To me it just feels wrong. I'm not sure how or why but after 15 years of working with 3d graphics and photo-realistic rendering etc, I'm struggling to find the way Racer deals with mixing the reflection on the unlit side hard to believe right now.

I might well use my unbiased Maxwell renderer at work, along with some real photos (all when I get time) to show that the reflection response is independent of illumination intensity...
I guess a difficulty is that ultimately, for many materials, diffuse response is the same as the reflective response, they are both the same thing in practice. Maybe the fresnel term needs to have a built in adjustment because diffuse is still present at glancing angles in our system, rather than it disappearing "in theory" and becoming part of the fresnel reflection!?


That may well be the problem. We are tying different systems in together and they don't mix well basically, because each one is kinda doing part of what the other should be.
In theory ALL Racer materials should use the envmap, but some should have it blurred, with values like 0.00001, 0.95, 100 for the fresnel, so it's super dull except for the very edge which has a reflection approaching mirror right around the edge.


Gah, it gets silly really. But I think generally the fresnel mix is bad. It seems to be relying on some colour underneath it (diffuse especially) to give it some strength which is just wrong?!
It should simply exist as it's own entity independent of the underlying surface... if we need to correct for the issues of inaccuracy of our simulation of light, then thats fine, so if that means capping the reflection strength at 0.95 for example, so be it
But limiting it now while the mix may still be bad (imo) seems wrong.


Hmmmm

Dave

 

[Stereo]

Just fooling with photo comparisons now, couldn't simulate the sunlight perfectly (near sunset is tricky) but it comes close.

The colour change near the horizon wasn't really coming out well, and I'm cheating a little on the autoexposure (edited it to overexpose by quite a bit, otherwise the sun just burns out the picture since it's visible over the car)

Needs some fiddling with the texture map, this is about 32 rgb which is way too bright. A good quality black paint definitely seems to be 1/2 or maybe even 1/3 this brightness, at least when it's shiny.

I'm really gonna have a hard think about how litColor and shadowColor mix with envColor, I don't think the current lerp(shadow,env) + lit is correct.

Anyway, the glass seems to fade into whiteness ok, obviously the open window is missing. Unfortunately the glass surrounds on the RX7 are part of the glass texture so a generic shader isn't gonna look good all around.


Looking closer at the RX7 model like this kinda distracts me cause I see the flaws a lot more in the model than in the rendering :/ Wheels definitely could be a little smaller letting it ride lower though.

 

[Mr Whippy]

Hmmmm,

Still not getting to grips with the sun intensity values nor the clouds values.

Right now if I set my sky texture alpha to be black, with large white spots over it (for clouds), and set diffuse to be white too, in Racer the clouds are nowhere near white, they are a feint blue. Even using my best texture modified so the clouds alpha is white where they are solid and fluffy, and darker where they are thinner, and then using a desaturated map for the rgb, the clouds look nothing like the original picture the texture is based off.

It seems to me that clouds = 7 for example, is still needed to get a cloud looking like it should. I'm guessing this a logic issue in the shader, and how we want them to be used/processed.
I'm hoping that for a newer version we abandon the current clouds and move to a system of normal mapped clouds on the texture, with alpha for density perhaps. The current system just looks pants and is letting down the graphics. It's also making developing anything but a clear bright sunny sky rather difficult. I really want to test materials on an overcast sky but it's hard to simulate one right now at all well.




Secondly, sun_intensity.crv is missing from the tod folder, but it is visible in the tod editor. Is this on purpose? Are we meant to be editing this curve any more?

It seems you really need this to be around 10-20% of the sun_diffuse intensity to get a natural responding sky though. This is tough to set again because most of the time we have clouds that add whiteness to the sky, but we can't really depend on that right now because clouds go blue not white in the current Racer system, compounding the issue of everything looking far too blue!


It is often helpful to look at what other programs do, Racer is currently doing weird things. The 3d program Maya for example, has a much more elegant system of user inputs that are intuitive and sensible to have.

Hmmmm

Looking forward to any improvement here as I'm really struggling with anything but perfectly clear blue skies

Dave

 

[Mr Whippy]

Just fooling with photo comparisons now, couldn't simulate the sunlight perfectly (near sunset is tricky) but it comes close.

The colour change near the horizon wasn't really coming out well, and I'm cheating a little on the autoexposure (edited it to overexpose by quite a bit, otherwise the sun just burns out the picture since it's visible over the car)

Needs some fiddling with the texture map, this is about 32 rgb which is way too bright. A good quality black paint definitely seems to be 1/2 or maybe even 1/3 this brightness, at least when it's shiny.

I'm really gonna have a hard think about how litColor and shadowColor mix with envColor, I don't think the current lerp(shadow,env) + lit is correct.

Anyway, the glass seems to fade into whiteness ok, obviously the open window is missing. Unfortunately the glass surrounds on the RX7 are part of the glass texture so a generic shader isn't gonna look good all around.


Looking closer at the RX7 model like this kinda distracts me cause I see the flaws a lot more in the model than in the rendering :/ Wheels definitely could be a little smaller letting it ride lower though.

Thats looking pretty good now

32rgb is about 12% reflectance if 0-255 is equal to 0-100% reflectance.

http://www.squidoo.com/LRV

Some nice info there.

Blackest black paints is 5% or so, white is 85%, some yellows 80-90%

I'd say your average black car paint is in the region of 10% imo... it'd be good to get some real data here, but ime, sub 10% starts to look quite unreal for a car paint.

Right now, for most textures, I'm taking what "looks" real, and then adjusting the levels so that the darkest point is about 20rgb, and the lightest 225rgb, simply because very few things naturally have values outside that range.

It's important for realism, especially inside our increasingly 'real value' rendering environment, to use real values as much as possible

Dave

 

[Ruud]

Nice gfx there, although CSM seems off? (specular under the car on the road?)
Take care when stating '10%' and such; there's a 'gamma' issue there. Camera pictures are in gamma corrected format; you take a picture, the camera does gamma 1/2.2. Then on your computer you output it, the monitor does gamma 2.2 and it looks ok again. In Racer, every shader is doing linear lighting. So we'll need to start specifying whether a map is gamma'd or not; diffuse images are mostly gamma'd down (from a camera). Bumpmaps are generated so need NO changing.
Also, in the ToneMap, I do a gamma of 2.2. But hm, the display already does 2.2! Currently reading on Uncharted 2 lighting (Hable_John_Uncharted2_HDRLighting.pptx on google), and the first 40 slides or so are about gamma! Interesting stuff.
So I'm trying to get rid of the gamma in the tonemap. It does make things more flat, but somewhere at 13:00 things do look nice (just edit data/renderer/common/hdr.cg and comment out the c=pow(c,gamma) ).

But that also means the input diffuse textures must be un-gamma'd really, or modified in Photoshop to be linear instead of gamma'd. But as you can read in the Uncharted2 powerpoint; halfway gray looks like 187 in RGB, not 128. Funny stuff like that.

Reflections and glass will get their share of time when I'm back at work; I have a car with a sphere body, where it's easy to test. It might depend on the shader though.