Racer v0.8.19 is out

Ruud · Aug 27, 2010

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.

Mr Whippy · Aug 31, 2010

Ruud said:
I've not tested/corrected auto_exposure.enable=0 yet (so that the original exposure.crv would be used). Perhaps each camera must have an exposure correct, so we get: finalExposure=autoExposure*todExposureFactor*cameraExposureFactor to get inside shots tuned.

It's not really that the exposure in any given camera is wrong per se, it's the dynamic behaviour generally that is poor.

Even if you could set the exposure to be right facing say north, as soon as you turn into the sun then that exposure setting is no good... it's the dynamics that need to be looked into, so when you are heading into the sun it doesn't black out the track, and when heading away from the sun it doesn't white out the track (or err in that direction)

You could almost do with putting limiters on exposure. Even if the sun is in shot you would never try expose for it with your real eyes, so limiting to say 50kLux is probably ample, and any values above are just clamped. Then the other way, values under a certain level are probably best clamped since you will never try 'see' them...

Hmmm

Dave

boomer541 · Sep 1, 2010

Thanks for all the info on page 4 everyone, I've got a lot of stuff to try out.
These are the pixs that show what I get with ver 0816 - 0819 currently and I'll try to change settings to get what DavidI got.

Mr Whippy · Sep 1, 2010

Open the console and type...

sun ambient 50

Do the shadows get any more intense?

Then reset and try

sun diffuse 0

That should kill the sun light and boost any ambient there is. I take it you are using TOD values (ie, time = xxxx) in the tracks special.ini?

Try altering the TOD curves, Ruuds defaults are massively stark defaults with very little ambient strength around higher sun positions, which really kills out ambient influence in the times of day you are showing...

Dave

Alex Forbin · Sep 1, 2010

Everyone try changing your gamma in hdr.cg and see what you get...

Code:

// Gamma correction (pow(2.0))
  const float gamma=1; <<----------------- from 2.0
  c=pow(c,gamma);
  return float4(c,1);

It made a huge difference for me, shadows are no longer an event horizon and ambient levels are near normal, I don't even mind the auto exposure now.
Speaking of auto exposure, I have mine set to...

Code:

  auto_exposure
  {
    ; If enabled, calculates luminance of the scene and automatically adjusts the 'exposure'
    ; It then overrules any exposure setting from track special.ini files or the script 'exposure' command
    enable=1
    ; Time per luminance sample (increase value to improve framerate)
    time_per_sample=100
    ; Exposure is calculated using: gradient/sceneLuminance+offset (this was changed in v0.8.18)
    offset=0
    gradient=1
    ; Minimal exposure
    min=0.0
    max=0.8
    ; Gradually change exposure with a Kalman filter
    filter_gain=0.05
  }

Now if we can just get motion blur back.

Alex Forbin

camsinny · Sep 2, 2010

Thanks Alex. Looks a bit better.
I guess this is where a screen calibration screen would be good since I'd assume that's what this is relating to.

On an unrelated matter however - how come on the alpha_to_coverage stuff now I can see wireframe?

Alex Forbin · Sep 2, 2010

camsinny said:
Thanks Alex. Looks a bit better.
I guess this is where a screen calibration screen would be good since I'd assume that's what this is relating to.

On an unrelated matter however - how come on the alpha_to_coverage stuff now I can see wireframe?

I agree on the screen calibration, there seems to be quite a difference between cards and monitors.

I'm not showing wireframes on my alpha_to_coverage. Try this shader...

Code:

shader_tree1~vf_standard_transparent
{
  layer0
  {
    map=tree1.tga
    alpha_to_coverage=1
    depthwrite=1
    alphafunc=gequal 128

  }
}

Alex Forbin

boomer541 · Sep 2, 2010

Thanks to Mr. Whippy for pointing me in the right direction! The ambient and diffuse were set wrong, getting good shadows now but a bad sky on carlswood. The 3 files that control the sky are: special.ini, track.shd, and tod folder. It would be appreciated if some body would post those for a good sky on carlswood so I can see what I'm doing wrong, thank you.

camsinny · Sep 2, 2010

Alex Forbin said:
I agree on the screen calibration, there seems to be quite a difference between cards and monitors.

I'm not showing wireframes on my alpha_to_coverage. Try this shader...

Code:

shader_tree1~vf_standard_transparent { layer0 { map=tree1.tga alpha_to_coverage=1 depthwrite=1 alphafunc=gequal 128 } }

Alex Forbin

Try it on say a car though, a windscreen...
A tree you probably won't see it on since there should really only be 1 or 2 quads which won't have edges in the middle of the face.

Mr Whippy · Sep 2, 2010

Changing gamma isn't the solution.

This is, I'm sorry to semi-rant, the problem with using Carlswood for anything. It doesn't really represent any kind of reality in it's settings from what I can tell. A combo of bad texture intensities mixed with not the best TOD curves and so on. It all adds up to things just looking wrong.

If you create your own TOD curves and track with sensible settings, then you will see that things actually look fairly nice.

I posted some curves for TOD in another thread, which are still good right now if you remove the exposure curve and sun position curves for now. Also set lat/long to 50deg north ish and 2deg west ish, and use a day/month/year around mid August in tracks special.ini

gowhippy.com/racer/tod_clear.zip

gowhippy.com/racer/tod_partial_cloud.zip

The TOD clear has quite stark shadow levels, but a totally clear day does. Partial cloud version is much more natural looking!

Dave

Some1 · Sep 2, 2010

Mr Whippy said:
This is, I'm sorry to semi-rant, the problem with using Carlswood for anything. It doesn't really represent any kind of reality in it's settings from what I can tell. A combo of bad texture intensities mixed with not the best TOD curves and so on. It all adds up to things just looking wrong.

As long as there is no alternative, everybody are still using it... I think, we the community, should either come up with a brand new Carlswood-like compact track that would feature intensity-correct textures and good lighting with TOD and convince Ruud to switch it as the default track in future Racer releases, or fix Carlswood's textures and lighting!

Alex Forbin · Sep 2, 2010

Dave:
Certainly, Carlswood is long in the tooth now and I'm all for a new track especially if Some1
is volunteering. That being said, I get good results with gamma set to 1 on all tracks. I don't know why having it set to 2 should be considered correct. I have never been able to get as nice of a result even when using your curves so I think it's more of a hardware difference issue.

Some1:
I regularly drive on your factory test track, just for the fun of it. It has realistic detail and a great track layout. If you get a chance look at the Mafia 2 demo, they did a great job on the graphics and the city is undoubtedly the best to date.

Alex Forbin

luthobu · Sep 2, 2010

Never heard of Mafia 2 before. Saw a cpl vids on youtube, and it looks amazing..
I can imagine that something like that would be nice for racer. Still, it is in a
different league.. it has peds peds and traffic, and the trees and grass look
fantastic. I like the idea of environments better than just plain closed curcuits,
though I admit that both Monza and Monaco are among my preferred tracks.

Ruud · Sep 2, 2010

Alex Forbin said:
Dave:
That being said, I get good results with gamma set to 1 on all tracks. I don't know why having it set to 2 should be considered correct. I have never been able to get as nice of a result even when using your curves so I think it's more of a hardware difference issue.

Read up this one: http://cmpmedia.vo.llnwd.net/o1/vault/gdc10/slides/Hable_John_Uncharted2_HDRLighting.pptx
Very interesting, first 100 pages or so are for gamma. The conclusions:
- we need to specify whether an image is in linear (1.0) or camera-gamma (0.45). Bumpmaps and other generated maps should probably be linear, but diffuse (albedo) maps are mostly taken a camera, thus in gamma 0.45, which is flatter than what you want.
- the gamma conversion in hdr.cg needs to be dropped (notice that gamma=1 is exactly the same as doing nothing: pow(x,1) = x).

In that case the clear-sky TOD curves of Dave might be ok all of a sudden. However, it does look a bit flat, but that's because the textures are then suddenly under-gamma'd. There's a hardware option (using *SRGB* for the image format) that will define a texture as being defined as SRGB, which has a gamma 0.45 (lighter and less contrast). I think I'll turn that on by default, so you'll then have to adjust your track.shd to have something like:

shader_body
{
layer0
{
image=body_diffuse.tga
}
layer1
{
image=body_bump.tga
format=linear
}
}

Otherwise the bump would create weird normals, instead of keeping (0,0,0.5) as the 'unchanged' normal (Z in texture space).
So prepare to have gamma set to 1. Read the PPT on why. Also, the PPT talks about filmic HDR tonemapping which hopefully maps ok to Racer. Not sure where 'exposure' comes in exactly though in the shoulder-curve.

camsinny · Sep 2, 2010

Well gamma should be at 2.2 or at least IIRC. Though that may just be your monitor and not the image the monitor displays...hmmm.
There's a reason behind that but I'm not sure what it is...

W.R.T the new track - I'd be happy with something like Forest Club. I really like that circuit. Plus if it's not a real circuit it'll stop people from complaining about how it's not 100% like the real thing.
FWIW I'm more than happy to chip in. If we can get 3 or so people committed I have a SVN we can use to create the track. Food for thought.

camsinny · Sep 2, 2010

Well gamma should be at 2.2 or at least IIRC. Though that may just be your monitor and not the image the monitor displays...hmmm.
There's a reason behind that but I'm not sure what it is...

W.R.T the new track - I'd be happy with something like Forest Club. I really like that circuit. Plus if it's not a real circuit it'll stop people from complaining about how it's not 100% like the real thing.
FWIW I'm more than happy to chip in. If we can get 3 or so people committed I have a SVN we can use to create the track. Food for thought.

Ruud · Sep 2, 2010

Gamma is 2.2, but that's your display. See slide 22 from the PPT.
But the input diffuse textures are pre-processed by the camera to display correctly on a monitor that applies gamma 2.2 to its linear input. All lighting calculations in Racer are linear; but the input textures are currently gamma'd by 0.45. If we modify the input textures (hardware supported) then those are stored in memory linearly.

Mr Whippy · Sep 2, 2010

So the problem currently is that in processing, our textures are rendered darker against the lighting they are exposed to, than is expected? Or with a variance in contrast too?

All I need to know is what work flow to use and I am happy I think. I'll generate textures where the whitest white part of them is around 90% of the 8bit dynamic range, and the darkest around 5%, and then we can go from there?

I'll have to DL the BIG pptx file at home and have a read of it.

Thanks

Dave

Alex Forbin · Sep 3, 2010

Ruud said:
Read up this one: http://cmpmedia.vo.llnwd.net/o1/vault/gdc10/slides/Hable_John_Uncharted2_HDRLighting.pptx
Very interesting, first 100 pages or so are for gamma. The conclusions:
- we need to specify whether an image is in linear (1.0) or camera-gamma (0.45). Bumpmaps and other generated maps should probably be linear, but diffuse (albedo) maps are mostly taken a camera, thus in gamma 0.45, which is flatter than what you want.
- the gamma conversion in hdr.cg needs to be dropped (notice that gamma=1 is exactly the same as doing nothing: pow(x,1) = x).

In that case the clear-sky TOD curves of Dave might be ok all of a sudden. However, it does look a bit flat, but that's because the textures are then suddenly under-gamma'd. There's a hardware option (using *SRGB* for the image format) that will define a texture as being defined as SRGB, which has a gamma 0.45 (lighter and less contrast). I think I'll turn that on by default, so you'll then have to adjust your track.shd to have something like:

shader_body
{
layer0
{
image=body_diffuse.tga
}
layer1
{
image=body_bump.tga
format=linear
}
}

Otherwise the bump would create weird normals, instead of keeping (0,0,0.5) as the 'unchanged' normal (Z in texture space).
So prepare to have gamma set to 1. Read the PPT on why. Also, the PPT talks about filmic HDR tonemapping which hopefully maps ok to Racer. Not sure where 'exposure' comes in exactly though in the shoulder-curve.

An interesting read there Ruud. I think you have a good plan according to the ppt. I don't know if the filmic will look good or not, judging by his pictures of the apartment it seems to black out the details in the area of the bar.

Would it be better to have the linear option as part of the bump shader since it's always going to be linear?

I wasn't a big fan of the idea of exposure control since it seems to make all lighting subjective and we're having a tough time nailing down lighting as it is, I do think that it will be a nice addition in the end though, since going from dark to light areas looks more natural with it.

The AO is something else I'm uncertain of. On one hand I do see the need for it for grounding the cars but the old ground shadow seems to work well enough for that. ( I just heard Dave scream, LOL)

Alex Forbin

boomer541 · Sep 3, 2010

Tried Alex Forbin exposure settings and everything went way dark, so I'll just stay with no auto exposure.
Got gyral to work very nicely after fixing 265 shaders, do have one problem with a mesh having 2 textures in the same place which caused flicker.

Alex Forbin · Sep 3, 2010

boomer541 said:
Tried Alex Forbin exposure settings and everything went way dark, so I'll just stay with no auto exposure.
Got gyral to work very nicely after fixing 265 shaders, do have one problem with a mesh having 2 textures in the same place which caused flicker.

View attachment 28636

You need to change the gamma too for it to work right. It sounds like Ruud has a solution coming though.

Alex Forbin