Racer v0.8.17 is out

Ruud

RACER Developer
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
 
In Carlswood I turned off cast_shadow on most 'floor' materials to speed up the shadowmap render pass. That is the issue here it seems. Turning it back on for the 'road' in Carlswood also gives these issues. I should raise the smCor[] values indeed. Still, using cast_shadow=0 is possible for most materials (and faster!).

Ruud, have you considered drawing track objects and moving objects into two separate shadow map and update the track one by a longer interval, and check them both in the main render pass?
 
Gahhh :D

Hehe, I knew it wouldn't be obvious :)

CTRL ALT S would be a nice feature to save them all.

Sorry about the confusion! v0.8.18 has Ctrl-Shift-S to save all (changed) curves.
Also don't bother too much with the sun; there has always been a year/day/month NASA calculation in it, I'll add day/month/year in special.ini and let that do the sun path, in combination with a 'what's_north_rotator'.
As for the splits, I noticed the smCor[] was quite off when turning the Carlswood road shader back on to casting shadows. Here's what I use:

splitdist0=10
splitdist1=50
splitdist2=200
splitdist3=600

and

const float smCor[SM_MAX_SPLITS]={0.0004,0.0002,0.0006,0.001};

Not tested this with interiors though. One day we might go back to screen-based CSM though, but it's too soon to tell (and gets back the MRT problems).
 
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.
Code:
  float desat = 0.66*(1.0-exp(-(color.r+color.b+color.g)))+0.34;[/QUOTE]
 
Might improve that a bit by weighing r/g/b; in television that was 0.28, 0.59, 0.13 but I've read weighings upto 0.07 for blue. Still, makes the B&W a bit nicer.
 
Yeah, found a helpful reference on another forum.
Georges G said:
Yes, it looks strange, but it isn't. If you look at real measures, primary colors and gray scale, you will find blue Y near 30% gray Y, red Y around 50% gray Y, and green Y around 80% gray Y. And if you sum those three Y values, you obtain 100% white Y value (a little less if you sum the three gray levels). But if you add 30%+50%+80%, you do not have 100%, you have 160 ! What's wrong ? In reality, it's simple. Between those two scales, percent levels and Y levels, you have a gamma factor. This factor in 0.45 in a sense, 1/0.45 in the other (the famous 2.22 gamma).

Red is 0.213, and 0.213 ^ 0.45 = 0.499, ie 50%. This is it

In the other sense: 30% ^ 2.22 + 50% ^ 2.22 + 80% ^ 2.22 is near 100% (90% more exactly: this is it too ).

Clearly, Y value for Red is 0.213 * YWhite. To obtain white, you send a RGB value (255,255,255). To obtain a gray whose Y measured value will be 0.213 * YWhite, the RGB triplet has three identical values which are 255 * ( 0.213 ^0.45 ), ie (127,127,127) in Rec709 (in Rec601 it is very little different). Pure red is of course (255,0,0), and measured Y value for both colors must be the same (not absolutely perfectly, because we do not have decimals in RGB triplets...). For intermediate saturations, well, it's some little maths

I hope it will make it clear now

Georges
I'll have to think about what's going on here in terms of the expected output. I know I saw the 2.22 gamma adjustment somewhere in the Tonemap function, so maybe the 30/50/80 figures should be used ahead of that.
 
Sorry about the confusion! v0.8.18 has Ctrl-Shift-S to save all (changed) curves.
Also don't bother too much with the sun; there has always been a year/day/month NASA calculation in it, I'll add day/month/year in special.ini and let that do the sun path, in combination with a 'what's_north_rotator'.
As for the splits, I noticed the smCor[] was quite off when turning the Carlswood road shader back on to casting shadows. Here's what I use:

splitdist0=10
splitdist1=50
splitdist2=200
splitdist3=600

and

const float smCor[SM_MAX_SPLITS]={0.0004,0.0002,0.0006,0.001};

Not tested this with interiors though. One day we might go back to screen-based CSM though, but it's too soon to tell (and gets back the MRT problems).

Ah cool I'll give those a go!

Also worth me trying turning off the shadows on the main track surfaces since they don't really cast shadows.

However, I am working on a track where it does self-shadow a little bit, at times, over the larger area of the terrain. I'll have to see how Racer deals with this... it's the same track with the use_mesh_hits issue so I'll have to remember to forward it to you soon!


Thanks

Dave
 
I know what it's meant for...And I know we used to have the torque reaction bit in the engine settings...but there's a "new" one since 0.8.9

Documentation on racer.nl doesn't say how to use/implement it.
http://www.racer.nl/tutorial/engine.htm#rumble

Ah, no problem. Just add this to the engine section of your car.ini (I placed it just after engine torque)...

torque_reaction=0.59
rumble_amplitude=20000
rumble_maxrpm=6000
cylinders=8
cylinder_angle=90

If you use fewer cylinders (4) it will shake more obviously.

Alex Forbin
 
Yeah, found a helpful reference on another forum.

I'll have to think about what's going on here in terms of the expected output. I know I saw the 2.22 gamma adjustment somewhere in the Tonemap function, so maybe the 30/50/80 figures should be used ahead of that.

Hmm, definitely gives an interesting tint to the scene.
Code:
float4 ToneMapHDR(float4 color,float exposure)
// Exponential (more contrast than L=L/(L+1)
// Used in Racer v0.8.17+ for lux light unit
{
  float3 c;
  // desat
  float desat = .5*color.r+.8*color.b+.3*color.b;
  float4 cdesat = desat;
  color = lerp(color,cdesat,exp(-0.06*desat));
  c=1.0-exp(-0.1*exposure*color.rgb); // do we want alpha to be 1 for sure?

  // Gamma correction (pow(2.0))
  const float gamma=2.2;
  c=pow(c,gamma);
  //c*=c;
  return float4(c,1);
}

5:30 AM, exposure around 2.0
left: this
right: original HDR tonemap
screenshot004zf.jpg


May not be more "camera correct" but it definitely gets that early-morning vibe better to me. By around 8am the sun's bright enough that the two look very similar.

Red and white car paint is a good scheme for this :p really brings out the extremes.

edit: cleaned up code a bit with lerp.
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 344 15.6%
  • < 2 years

    Votes: 235 10.6%
  • < 3 years

    Votes: 231 10.5%
  • < 4 years

    Votes: 175 7.9%
  • < 5 years

    Votes: 295 13.4%
  • < 10 years

    Votes: 256 11.6%
  • < 15 years

    Votes: 163 7.4%
  • < 20 years

    Votes: 124 5.6%
  • < 25 years

    Votes: 99 4.5%
  • Ok, I am a dinosaur

    Votes: 285 12.9%
Back
Top