Racer v0.8.17 is out

[Ruud]

Really experimental. v0.8.17 has a TOD editor (as already posted in the 'TOD editing' thread). The curves are not too great though, if somebody can fix them.

v0.8.17 is at http://www.racer.nl/download/racer0.8.17.zip

Known issues:
- Existing tracks don't work correctly wrt lighting. The lighting unit is now kilolux (kilo to preserve precision). So at night the lighting can now really be dark, with exposure making it visible still. More info on lux at http://en.wikipedia.org/wiki/Lux
Once the TOD curves stabilizes to a nice default, the new lighting will hopefully not change anymore for v0.9.

Changes:
- Revise TOD/lighting scaling - the base lighting unit is now kilolux. Direct sunlight is
around 32-130 klux, skylight 10-25 klux, moonlit night=0.001 klux
(see also http://en.wikipedia.org/wiki/Lux)
The curves are not too great yet, but the nice thing is that the car lights vary
from day to night.
- Mie/rayleigh combination mix reverted to the original paper; slight change of color,
but this blends the world objects more nicely into the sky with some mie.
- Removed specular curves from TOD editor - it's now copied from the diffuse curves
- Revised split distances and smCor[] in constants.cg once more.
- Also using 4 splits now, with splitrenderjump<x> so it's faster even than 3 splits without jumps
- New white styling

v0.8.16 (11-08-10)
------------------
- Mirror texture was 8-bits, now HDR (16-bits)
- Mirror uses data/renderer/fullscreen_shaders_hdr/mirror_hdr.cg to handle HDR->LDR while painting
so it looks as intended
- Sparks didn't render right when used with a mirror or live_track=1 (prevModelViewProj)
- TOD editor using 'edit tod' for exposure. Horizontal=0000-2359, vertical=variable.
The editor jumps live to the time you're editing. It replaces a number of variables
that were hardcoded/constant. The future will see per-track tod support.
- Revised split distances and smCor[] in constants.cg

 

[Mr Whippy]

Wow, sounds cool Ruud!

Can't wait to try with real kLux values... another toy for the shopping list will be a light meter that can meter the wide ranges needed! Dynamic range probably being more important than super accuracy here!


Thanks

Dave

 

[Eholov]

Thanks for new version, Ruud!
I have few problems:
1. Don't correct reflections
2. Only Carlswood working fine with last Racer

 

[gtpdzbiz]

The introduction of Lux is really great~ Though the bloom and auto exposure need some tweaking to make it work...could I use exposure value in the bloom_filter_f shader?

 

[Mr Whippy]

I guess that auto-exposure will generate a "value" automatically where we normally input it, and that should be sent to the bloom shader as some kind of scaling variable?!

Either way, I'm excited

Dave

 

[gtpdzbiz]

I guess that auto-exposure will generate a "value" automatically where we normally input it, and that should be sent to the bloom shader as some kind of scaling variable?!

Either way, I'm excited

Dave

It will be used as a threshold to determine how much light will bleed into nearby pixels...but what's more important is to set up good auto exposure parameters and select a decent Tonemap function...which is pretty tricky.

 

[QuadCoreMax]

Here's a link for everyone interested how Shift shaders are coded.
The pack includes :

1. All shaders
2. Some shaders cache
3. Materials in binary (look at bottom for quick understanding)
4. All Textures of Lotus Exige

We use to create a mtx file (plain text) which holds all textures paths + shader params/techniques from the bmt files. Still, huge issues for wheels shader for example...& tremendous headache !

Hope, some of you, will take the best out of it & fit it somehow to Racer.

http://www.megaupload.com/?d=TS2MV9NT

 

[Stereo]

what's more important is to set up good auto exposure parameters and select a decent Tonemap function...which is pretty tricky.

Hmm... I guess this will let us model "human eye" views more accurately - shift from full colour to b/w as the light levels drop below what the cones can pick up. Eg. auto-exposure of a moonlit night with the headlights off.

Should be interesting to see what we can make from this.

 

[Mr Whippy]

Hmm... I guess this will let us model "human eye" views more accurately - shift from full colour to b/w as the light levels drop below what the cones can pick up. Eg. auto-exposure of a moonlit night with the headlights off.

Should be interesting to see what we can make from this.

I guess that would be cool in what are currently fullscreen shaders (fs_filter), then we can hopefully start to define camera types and have different effects through them.

Ie, car driver views can utilise an 'eye' type camera etc

Dave

 

[Mr Whippy]

Hmmm, I have a bit of a bug, it's happening on all my tracks (Dunsfold, Snowden Moor and Elvington, so not limited to flat tracks or hilly tracks)

I don't

I'm clearly seeing the splits, like big boxes from above, and it is a repeating moire type pattern. It's not evident on Carlswood which is why I am thinking it's something I am doing wrong... but on ALL my tracks?

Hmmm


Also, shadows on car interiors look really poor too, they have done since we moved to the different type of CSM shadows from the original ones... personally, looking back, they seemed to be just as fast and generally better looking more of the time!? OK the new ones are nicer in up-close screenshots, but these moire patters and interior shadowing reduced to being really poor looking, offsets the benefits... for now at least

Dave

 

[Stereo]

I'm not sure what the solution to this would be but it seems like the shadows are not working well across polies? The edges are pretty clearly visible, and the shadow intensity is essentially constant inside each poly.

Maybe it needs to be moved in the vertex/fragment process so the per pixel normals can somehow be incorporated?

 

[MitchVL]

Mr. Whippy and stereo. You have to play a bit with the splitcorrections defined in constants.cg.
raise the values a bit until the artifacts disappear.

The current CSM implementation is faster and better than the old one. You just have to tweak it to match your setup ... We could just set the splitcorrection high by default i guess. something to think of for the next releases.

 

[Stereo]

Thanks for the pointer, had to raise the first smCor by about 40x (0.00001 to 0.0004) before the effect went away. Pushed up the second value too since it didn't seem to have a big impact on fps.

Also stumbled on another problem, I guess... track cameras and car cameras aren't centering the shadow maps in the same place. The track cams will fairly often be dropped to the 3rd split near the car, which updates every 15 frames (results in shadow trailing the car for a quarter of a second), while I can zoom as far away as I want on the car cams and it sticks to the first ones.


Hopefully pick up a pseudo auto-exposure soon, the white car's really causing trouble depending which side the camera's on. And late at night, the headlights on/off mean the difference of about 20 times the exposure. The auto_exposure in racer.ini doesn't seem to work anymore after TOD changes, it just drops to the minimum immediately.

 

[camsinny]

Hopefully pick up a pseudo auto-exposure soon, the white car's really causing trouble depending which side the camera's on. And late at night, the headlights on/off mean the difference of about 20 times the exposure. The auto_exposure in racer.ini doesn't seem to work anymore after TOD changes, it just drops to the minimum immediately.

I'd say this has to do with the fact that now the exposure range is different. Something to fix for the next version I guess. Is the filter you're working on just a fs shader?

Can't wait to play with this when I get home. Thanks Ruud and Mitch!!

 

[Stereo]

Really it's a different ToneMapHDR method (in hdr.cg) to fiddle with.

To kill saturation at night I have this stuck in, before the exposure level is applied.

  float desat = 0.66*(1.0-exp(-(color.r+color.b+color.g)))+0.34;
  color.r = desat*color.r + (1.0-desat)*0.5*(color.g+color.b);
  color.g = desat*color.g + (1.0-desat)*0.5*(color.b+color.r);
  color.b = desat*color.b + (1.0-desat)*0.5*(color.r+color.g);

As the color approaches zero, desat goes to 0.34, which mixes them at 0.34 + 0.33 + 0.33 (almost unsaturated). Could probably do with some messing with constants to get an appropriate light level for colours to fade, though.



At least for the diffuse/ambient.rgb, it would be nice if the TOD editor used a log scale. It's impossible to edit the night-time values ingame because they're all less than 1 pixel from the bottom of the graph.

 

[Mr Whippy]

Really it's a different ToneMapHDR method (in hdr.cg) to fiddle with.

To kill saturation at night I have this stuck in, before the exposure level is applied.

  float desat = 0.66*(1.0-exp(-(color.r+color.b+color.g)))+0.34;
  color.r = desat*color.r + (1.0-desat)*0.5*(color.g+color.b);
  color.g = desat*color.g + (1.0-desat)*0.5*(color.b+color.r);
  color.b = desat*color.b + (1.0-desat)*0.5*(color.r+color.g);

As the color approaches zero, desat goes to 0.34, which mixes them at 0.34 + 0.33 + 0.33 (almost unsaturated). Could probably do with some messing with constants to get an appropriate light level for colours to fade, though.



At least for the diffuse/ambient.rgb, it would be nice if the TOD editor used a log scale. It's impossible to edit the night-time values ingame because they're all less than 1 pixel from the bottom of the graph.

Is that per-pixel?

Ie, objects in the headlights will still colour properly because they are illuminated well? Yet surroundings look de-saturated?

Dave

 

[Mr Whippy]

These seem to have removed the lines for me (1600x900)


const float smCor[SM_MAX_SPLITS]={0.0005,0.0007,0.00085,0.001};


BUT, there are still some artefact issues as the car drives towards a camera the camera is on top of the pattern that normally isn't evident from the car in the distance, it is feint but visible. Not a show stopper though.

FPS went from 55.5fps default at start position, to 54.5fps, so not a huge hit.

The accuracy of shadows on the car appears to change though... hmmm.

To get the track looking good, the car looks much worse imo, and to get the car looking nice, the track looks horrible, AND the issues are not resolved on interiors, they still look totally pants vs the old method... in the above examples the interiors look either bad and lots of lines with the defaults, or with the new values I have used accuracy has fallen right off with light leaking in all over the place.


I'm sorry to say it, but they might be faster, and accurate within the scope you optimise them for, but generally they are, imo, worse than what we had back in say 0.8.10... in 0.8.10 default install I'm getting 62fps and the shadows are almost as accurate as the best case above, but without the weird patterns all over the track, AND interiors look good, rather than just fuzzy messes.


I'm sure it can all be fixed, but it's not more accurate or faster yet, or better looking. What was the reason for actually changing again

Dave

 

[gtpdzbiz]

Hi Dave,

There is a value in renderer/constants.cg, called "iSqrtSamples", change it to 2 for some performance boost~should also reduce some filtering artfacts

 

[Mr Whippy]

Is there any reason these variables are not scaled wrt resolution etc?

I know it's not massively important right now for it to be perfect out of the box, but it seems like a lot of work is needed to get things looking even half right, while the first few CSM beta's had rather intuitive and good looking settings out of the box!


Just struggling with trying to set things up here. They have a huge impact on track and car apparent intensity as you can see, so I'm also wondering which 'view' is accurate to calibrate lighting with. The patterned one or the clear one?!

Hmmm



Just had a play, the iSqrtSamples helps a little bit, but the liney patterns only seem to go away with the other numbers changing to bigger numbers like 0.003 etc...

The iSqrtSamples number can go as high as 12, and hurt FPS lots, but interiors still look really bad, with shadows failing to work nicely around the bodywork and pillars and steering wheel, and generally looking bad.



I just feel like we have moved backwards with these. If there are good settings, can someone please post them for me

Dave

 

[Stereo]

Is that per-pixel?

Ie, objects in the headlights will still colour properly because they are illuminated well? Yet surroundings look de-saturated?

Dave

Yeah, this is applied per-pixel in bloom_shadows_f.cg, so headlights pick up normal colours. The night-time TOD curves need some work though, right now mine is very pink past 1am or so, to the point where this can only compensate so much (car is still a bit pink, just not excessively so)

float desat = 0.66*(1.0 - exp(-0.05*(color.r + color.b + color.g))) + 0.34;
Adjusting the constant here to a lower value (eg. 0.02-0.10 seems about right) will make the scene more gray - I haven't really fiddled with what seems appropriate yet.