Racer v0.8.23 released!

[Ruud]

An important one.
Troubles expected with this one:
- linearity of the steering wheel (you for one now need to specify the wheel lock in the setup screen before starting to judge things)
- a new parameter ('sunny') in most fragment shaders (any typos?). For a simple 'overcast' type of thing where you allow less sun to shine through.
- dbg_car.flip_tan=1. Perhaps a major breakthrough on the physics end. Where I always used a tan(SA), it might have needed to be atan(SA). Ouch, we're going to test this on our high-end sims later today, see how it feels (easier to do than with a G27).
- steering controls are now in degrees, rather than normalized. How about center_squeeze (and related) for Mz reduction near 0? Haven't looked at that yet.

The download: http://www.racer.nl/download/racer0.8.23.zip (67Mb)
Then get the latest exe flip_tan bugfix (only exe): http://www.racer.nl/download/racer0.8.23b.zip
(5Mb)
*after some testing, it appears than dbg_car.flip_tan should be 0* (the older situation)

The changes:
- Steering revised quite a bit - the controls for steering left/right now use degrees, instead of being
normalized. This changed some things inside the physics engine to use rotation more directly.
The idea: set your controller's lock correctly. With cars that have a steering lock that is smaller
or equal to that of the controller lock, the steering is direct (1:1). If a car has more lock defined
in its car.ini, linearity will be applied on the controller's steering output (now in degrees) to let it
use the full range of the car's steering wheel (linearity=controllerLock/steerLock).
This all targeted a bit for 900 degrees where you no longer then have to tweak for a lot of cars.
The controller setup screen is being worked on to visually check the lock (press F5 twice in the setup
screen to show the 'Wheel' page).
- Controller lock is now saved in the setup screen.
- A new important physics tweak is available: dbg_car.flip_tan. Defaulting to 0 (the v0.8.22 behavior),
setting it to 1 modifies the slipangle calculations for each wheel to use atan() rather than tan().
The tan() has been in there for a long time, to stabilize high slipangles. But, tan() makes values
worse as they grow, instead of flattening them like atan(). So, this needs to be investigated;
probably it has quite an influence on slipping behavior (with big slipangles).
- bloom_shadows_f.cg accidentally had bloom turned off
- Flare Cg shaders tweaked for nicer looks (alpha changes)
- log file position group added 'lap' (ASCII format)
- Added motion_blur.stencil option - use 1 for the old projected shadows, 0 for shadowmapping (faster)
- Added dev.nvidia_perf option that will try to access nVidia PerfSDK counters if installed.
Install an instrumented driver for this to work.
- Added a profile debug page (Ctrl-6, may have to press twice for the 2nd page) to see some nVidia performance counters.
I must say it bluescreened my XP machine more than once, so be careful with instrumented drivers.
- Added envmap.live_track.frames_per_update for more live track mapping control
- Fixed some tough render engine bugs that messed up Z-buffer usage (mirror on made the screen flicker)
- Generic models weren't transforming; fixed.
- Added wiper modes (off/interval/normal/fast), use 'w' to switch to the next mode (see also Ctrl-4 for the current mode)
- dyn_standard_bump_reflect_f.cg now also lets bumpmap alpha affect specular (next to reflectiveness)
- Sky_f.cg and sky_daynight_f.cg modified so clouds=1 now gives the normal effect (and does not raise
cloud regions to 175 klux!)
- A track's exposure in special.ini is now correctly used as the initial exposure (no more starting
with white, then coming back to a normal exposure if you set this one to a nice value; like 0.02?)
- Fixed a bug in the fresnel calculation in dyn_standard_bump_reflect_v.cg, which gave bad looking
reflections.
- Selecting Bloom/Shadowmapping from the menu gave problems with undefined 'gammaFactor' errors.
- Surround Gaming mode camera aspect fix (director mode)
- A surface's 'grip_decline_driveline' now defaults to 0 (was 1). Fixed issues with grip declining by default.
- Panorama shader's extinction now uses 'scale' Cg parameter instead of hardcoded value (5). Add 'scale' to
your track.shd file.
- Backfire would sometimes not work. This and a bunch of other uninitialized data fixed.
- 2D elements in the render engine could mess with motion blur blending (OpenGL state cache).
- When bloom was on, the aliased buffer was anti-aliased twice! (for bloom and at postprocessing)
- blur_alpha didn't work; the fullscreen shaders didn't output correct alpha. Using a bit of blur_alpha now
by default (0.3).
- Auto exposure sampling did an anti-alias pass; now it uses a previously anti-aliased result (faster).
- Dropped config.exe for now - anybody using it actively? Most should be settable ingame.
- Added 'sunny' in special.ini (tracks); 0=totally overcast, 1=super sunny. For ground objects.
Needs to be added to all fragment objects though. Also adds script cmd 'sunny <x>' to set it live.

 

[Mr Whippy]

The Link does not work Dave

Some cameras have a "focus point", meaning that the all the detail is not always on the foreground, otherwise, some track cams would look like crap.
That is probably related with your issue.

Hi Mitch, the link should work now?!

As for the issue, this is with all cars so far that are just your basic 'behind car' kinda view.


Standard Racer Lambo, default camera offset to left a bit to make it clearer.




I've got samples at 0 and blur 0 there, but looks the same with those reverted to original settings.


Is the focus point in these cases the null point of the car? Seems a common problem for all cars I've tried so far. Blurred behind, sharp in front.


Still don't get the logic any way, shadows behind the camera are not seen anyway so why even render them at all?! Confused

Dave

 

[MitchVL]

Ah yes, the shadow drops just on the line where the 2 smallest splits come together.
raise splitdist0 in racer.ini until the problem dissapears .. 1-2 meter should be enough since it's just on the outside of the shadow

The camera heading works perfect when working with incar views though

 

[Mr Whippy]

Won't raising the split distance reduce the quality of the shadows within that split though?

Also, it doesn't seem to be working still. I've gone up to 20m, and 40m, and it's not changing things here


Ideally, the first split (split0) should be just enough to cover most cars, so 10m seems ideal, 5m car should have 2.5m front and back... on a car taking up most of the screen from a behind view, on 1920px wide screen, that seems to give about 1px of shadow map for about 1px on screen for the cars shadow, or there about. Perfect.


It seems bad logic to increase split distance to cover the fault of a feature that is designed to save fps, but that is giving worse results in doing so. You could just keep the old split distance, not use the effect in question, and use a smaller shadow map instead to save fps.


Surely the feature is buggy if 10m split0 isn't enough to cover the Lambo which is about 2m x 4.5m in size?!

Dave

 

[Mr Whippy]

Hmmmm,

Where are split distances drawn relative to cars and so on? Is it a square floating in space perpendicular to the sun, about the focal point? (ie, the cars null point?!)

Also, are smCor values just for track cams, or do they work for interior ones too?


Lastly, I get nice shadows on interiors with split0 of say 3m, in ideal situations.

However, in a low sun, the nearside A pillar can be casting a shadow on the offside door interior that is clearly from split1, while the rear view mirror is casting a shadow on the same door interior that is clearly from split0.
How can a split0 of 3m not entirely cover a car interior?

I'm sure it's probably not as simple as that, but I'm curious so I can work out how best to set these values. For interiors it seems ideal to get the split0 *JUST* big enough to cover your average car interior, so maybe a 2m cube tops... although I guess trees outside that 2m box will cast less sharp shadows, but I think that is more ok.


Hmmmm

Dave

 

[DavidI]

Some general info I found interesting, HAWX2 using tesselation in DX11 is designed to have a maximum of 1.5million poly's per scene. Theres something to aim for.

 

[boomer541]

Ruud,
My shdow settings which work very well. I get a peoblem with the baja causes the ground grass to flicker which uses the vertexcolor shader. The baja doen't cause the sufaces on carlswood that use vertexcolor to fliker. Is there somethng wrong with the vertexcolr cg? The car headlights need to be independant of tod curve values, set with emission in shader!
constants.cg
const float gammaFactor=1.3; // was 1.25
// Shadow mapping
#define SM_MAX_SPLITS 4
#define PCF_NUM_SAMPLES 16
const float shadowMapSize=2048.0f; // Should be the same as in racer.ini was 512
const int iSqrtSamples = 2; //sample quality, should be 2,4,6...etc 2 or 4 is recommended
const float smBlurAmount=0.0f/1024.0f; // Amount of shadowmap texture blur (resolution dependent)
// smCor for trackcams
const float smCor[SM_MAX_SPLITS]={ 0.0005,0.003,0.0025,0.003 }; // best
racer.ini
profile0
{
; outside car
; nr of splits used, each split takes one extra render loop (3 should be enough)
splits=3
; texture resolution; MUST match that in data/renderer/common/constants.cg!
mapsize=2048
; split distances 0 - 3, each distance higher than the previous one; now in data/renderer/common/constants.cg? (not true probably)
splitdist0=30 ;30
splitdist1=150 ;60
splitdist2=500 ;300
splitdist3=1500 ;500
; the amount of frames to skip to increase performance
splitrenderjump0=0
splitrenderjump1=0
splitrenderjump2=0
splitrenderjump3=0
; offset the framecount for jumping frames
splitrenderoffset0=0
splitrenderoffset1=0
splitrenderoffset2=0
splitrenderoffset3=7
; debug mode (paints splits)
debug=0
; size of the debug polygons rendered
dbgsize=128
}
profile1 the same as profile0

 

[MitchVL]

Won't raising the split distance reduce the quality of the shadows within that split though?

Also, it doesn't seem to be working still. I've gone up to 20m, and 40m, and it's not changing things here


Ideally, the first split (split0) should be just enough to cover most cars, so 10m seems ideal, 5m car should have 2.5m front and back... on a car taking up most of the screen from a behind view, on 1920px wide screen, that seems to give about 1px of shadow map for about 1px on screen for the cars shadow, or there about. Perfect.


It seems bad logic to increase split distance to cover the fault of a feature that is designed to save fps, but that is giving worse results in doing so. You could just keep the old split distance, not use the effect in question, and use a smaller shadow map instead to save fps.


Surely the feature is buggy if 10m split0 isn't enough to cover the Lambo which is about 2m x 4.5m in size?!

Dave

It would reduce the quality a bit, but if you raise the distance 1 or 2 meters it would be hardly noticable. Even the second spllit gives good shadows through fences..
Because of the shadowmap blending, a 10 meter split will actually start blending at 4 meters from the center (the last meter at the edges blends with the next shadow map)

Setting split sizes and corrections is not an exact science, i like the current settings a lot?
If these settings don't work for others, the values can be tweaked.

And the camera heading is perfect for incar views, and that's normally the preferred camera when driving.
If you want a perfect Shadowmapping solution, i'm sorry but i don't think it exists

for interior shadows,
there will always be somewhat of an angle in the direction of the shadowmap or the car, so if you think about it, a small split will not always suffice. a split of 5 meters should be good i feel.

 

[Mr Whippy]

Yeah, 5m for interior splits seems ideal for good coverage. Does smCor factors apply for interior camera profile too?

The shadowmapping solution is a hard one generally I will agree, the work that is going on is truly very impressive when you watch things like GT5 and NFS HP, and see how good Racer has got it.

However, that isn't to mean we should just be happy at every point, pushing things and being critical has got us where we are now


Any chance the camera heading can be turned off for external view profile then? It is hurting the visual appearance of any car in any screen shot here... spin the camera round to the front of the Lambo, and the shadow is soft at the front, and sharp at the back.
For interiors it seems silly to render high quality shadows out of your view, so that makes sense.


I upped the split0 distance and it's still there... could you send me some values that definately DO work at your end and that I can try?

Last thing, is there any reason the shadow definitions/constants are split between constants.cg and racer.ini? Is it not time for shadows.cg to hold all these? (just makes it easier for us to swap settings and stuff)

Thanks

Dave

 

[Stereo]

I don't really like the CloudCoverAlpha function (as mentioned if clouds=0.0 it returns 1/0 which just makes the sky black, and if it gets rendered onto the envmap everything goes crazy)

This is what I wrote instead, I'm fairly happy with it over the range of clouds= 0 to 1 on Carlswood's map (the brightness needs direction work but that's in sky_f.cg,)

float CloudCoverAlpha(float a,float clouds)
// Calculates alpha for cloud cover parameter 'clouds'
// Multiple your sky cloud color with this to get affected by the 'clouds' parameter.
{
  // original
  // return saturate(1.0/clouds*(a-1.0)+1.0-(1.0-clouds)*0.7);
  return pow(a,1.0/(clouds+0.001))*pow(clouds,0.5);
}

Used Wolfram Alpha to plot the difference between the two.
Original (note values under 0 height are truncated to zero, not sure how to plot that):

Mine:

x = clouds, y = texture alpha

 

[Mr Whippy]

Hmmm, how does the clouds go on with alpha, since that is a linear space information lookup.

Should we also set linear=1 in the shader?

Diffuse colour is kinda irrelevant too, because we are passing that more for shading. Personally I think the diffuse channel rgb should be normals so the clouds get lit properly by the moving sun ...leaving alpha for coverage. Is that in sky_f.cg?

Ruud


Good work there though Stereo, clouds=0 should be just atmosphere, not blackness, and clouds=1 should be the highest we ever need

Dave

 

[Ruud]

I does work on my pc but when:

...2) I switch shadow mapping off game is running with 60-70fps and crashes while pressing ESC (1024x768, fullscreen)

3) with shadow mapping on, all non-cg cars are dark or black

4) at non-cg I get over 400fps :]

5) What happened with config.exe ??

2: does it give a stacktrace? A dialog?
3: Racer requires Cg. That's why v0.9 is so important - all content must be upgraded to use Cg. Can't do without, since shadowing won't work etc. Even if that would be accepted, a flood of messages like 'bug found: shadowing doesn't work on car X' will occur. We need to start fresh with updated content.
4: Indeed, but the gfx look like crap. ;-)
5: From the readme, most should be settable in-game. It's a pain to keep config uptodate, since it just does an average graphics level, which impacts multiple settings. So as you tweak racer.ini settings, it won't be able to keep up anymore. It might need to turn into a tool to reduce graphics so you could run, but that's also doable with a .bat file (with 'ini' commands).

 

[MitchVL]

Does smCor factors apply for interior camera profile too?
The smCor applies to all profiles for now, because of the angle correction, it should work nice in most cases

However, that isn't to mean we should just be happy at every point, pushing things and being critical has got us where we are now
Thats true, but there goes a lot of time in perfecting details, and sometimes its just not worth it.


Any chance the camera heading can be turned off for external view profile then? It is hurting the visual appearance of any car in any screen shot here... spin the camera round to the front of the Lambo, and the shadow is soft at the front, and sharp at the back.
For interiors it seems silly to render high quality shadows out of your view, so that makes sense.
Yes, maybe there should be some kind of setting per camera that disables this behaviour. Thats something to look at in the future.


I upped the split0 distance and it's still there... could you send me some values that definately DO work at your end and that I can try?
Strange ! There are two splitdist0 in racer.ini, are you sure that you are adjusting the right one? you should be adjusting profile0.splitdist0

Last thing, is there any reason the shadow definitions/constants are split between constants.cg and racer.ini? Is it not time for shadows.cg to hold all these? (just makes it easier for us to swap settings and stuff)
Some data is needed on the CPU too, so we could throw everything on the CPU, but then we would have to pass it to the GPU afterwards and using constants on the GPU is faster...
With the SmCor tweak, the only things you should be tweaking are in racer.ini (and still maybe the mapsize in constants.cg, but i assume that nobody is playing around with that)

Thanks

Dave

message too short !

 

[Ruud]

Hmmm, looks like lots was changed in atmosphere.cg,

// Take out a bit of green
RayleighColor.g*=0.8;
RayleighColor.a=0;

That is commented out, explains the greeny skies I'm getting.

And a * 0.9 factor here... I guess this is on the green channel?

Indeed, I should be online 26 hrs/day. ;-) I've modifed the 0.9 back to the 0.8 factor again. It was modified since it saves a multiplication at the end, since you're multiplying with v3InvWaveLength already. So it was faster, an optimization.

 

[Ruud]

We are not doing bad, but car self-shadowing isn't as good as it was in 0.8.22 with the same splits imo.

The shadowmap heading is an odd one, it's impossible to check since if you turn to look the other way, the shadow is now re-drawn with more quality haha.

I couldn't seem to get the blurring turned off with 0.8.23, like there is always some built in?


I also think the split distances turn off shadows too soon. Can we not have a global slider for shadow distance/quality?

Blurring needs to be thought out better too. The default is very soft, which is ok for a soft ish sun, but on a bright clear day shadows need to be sharp, and they look better sharp with no blurring with 1024 maps imo


+ the mie/ray issues above, with greeny sunset mists, clearly shows something wrong there. Will be hard to tell how it's all working until these issues are fixed

Dave

Shadowing is a b*tch I'm afraid.
blur=1 vs blur=0 does work on my machine. With 1024-2048 shadowmaps you may see it mostly when getting closer, or with steep light angles. The constants.cg contains 'iSqrtSamples', which is the amount of sampling when blur=1. Setting it to 0 may not work.
I've taken out the 'smBlurAmount', which was 0 anyway.

The shadow distance would be very difficult; each change in the split distances means tweaking the smCor[] array! The response may be linear, but as Z values are not stored linearly on the gfxcard, it probably isn't. So a shadow distance slider would be very hard to get right. I'd think it might even be different on nVidia vs ATI cards, also if it forces things like a 32-bit Z-buffer.

Shadowmaps are always soft - they start to be blocky & suck if not softened. More detail just means a bigger shadowmap. And we're trying to make shadowmapping faster, it's already just about the current bottleneck.

 

[Ruud]

Hmmm, looks like lots was changed in atmosphere.cg,

// Take out a bit of green
RayleighColor.g*=0.8;
RayleighColor.a=0;

...
Ahhh nice, using atmosphere.cg from 0.8.22 and it's all pretty again. Lighter in the distance, but still misted in the near distance, giving much more sensation of depth of the terrain you are looking over

I've diff'ed the 2 versions and the only change should be the 0.9 -> 0.8 factor in v3InvWaveLength...

 

[Mr Whippy]

message too short !

Ah cool, thanks for those clarifications Mitch!

Splitter per camera sounds good for the effect in question. Just seems a shame to lose quality to cover up a fault with a feature that is meant to save fps. Kinda a win lose situation. Tying it to the shadow profile for interiors only sounds like a plan though

Pretty sure I'm messing with the right split with regard to the shadow being half-res behind the car. I'll install a new Racer folder and check with 0.8.23 out of the box.
I don't think it's as obvious with blurring on, but I've turned it off. The shadows are MUCH sharper up close for the split0 without blurring (could be blur per split perhaps, seems it's not really needed for the closest one... hmmmm)
Blurring the split0 when the atmosphere is hazy though, makes sense.
Just seems a cool effect to get a nice sharp shadow, or a slightly softer one, just by turning blur on and off... seems a shame to lose that potential feature. Tie blur into the size of the sun spot and you have a cool way to get soft hazy day shadows, or sharp clear day ones.

Good point on the smCor values. If they are something that is generally tuned to the split distances, then I guess it's just editing in two places for now still




Ruud, the blur off does work, I was confusing it with the fact the half map size for camera direction was making it look blurred at the back of the car still, but upon observation the front of the car shadow was sharp. Sorry about that.


Not sure about the shadowmaps looking blocky and bad without blurring. In my honest opinion, shadows on bright sunny days are sharp, and the default blurring is too strong to suggest a sunny day shadow. Maybe a strong hazy day is correct for them.

I'm finding no blurring works best for split0/1 any way, and by the split2/3 (i run 4 splits right now while testing) you can't really tell that they are a bit jaggedy anyway.
The down-side to blurring them at a distance is that they blur quite a lot, and look really soft and unreal. I'm preferring the slightly jaggedy look.

I'll try compose a load of screen shots to show what I mean, but I'm finding now with 1024 maps that blurring isn't really distracting me at all on most occasions, or looking that bad. I'll turn it ON for a hazy day conditions, maybe with the rain going, and it feels really nice then



I'm getting the idea that shadowing is a *****...

...just trying to help out with some comments and observations. Maybe you are aiming for perfection with the blurring and stuff, but with the blend between splits and 1024 maps, I'm not really looking at Racer and thinking you need map blurring generally.

I'm thinking it looks REALLY good like that full stop for a sharp sunny day (bar the annoying blur behind cars now due to the direction thingy which should be fixed with sticking that under the interior profile only)!

Blurring it then seems nice for softening shadows for hazier days, which is a bonus really... you can get the sharp sunny days and then softly shadowed days (maybe as sunny value moves towards 0 it softens the shadows?)

Powerful potential there, just would hate to see it missed out on as a feature



As for the green, yeah, there were a few changes that I saw that all summed up to just moving factoring around... but it did seem like that order was important, and we went from what looked like defined values to float4 things in a few places...
My main concern here was the fall-off change, it seemed to be less linear with distance, and more exponential, which hurt the feeling of realism for me. Stuff 5km away suddenly looked less far away (less hazy), and yet stuff 10km was darker and less saturated than it was before... hmmmmm.

That is possibly because the green colour was mixing with the greeny gound, and making the mist on those elements look less obvious... perhaps the bluer tint to the mist will make the mist stand out again


All good, just making sure that I know what is changing so I can consider it when authoring and setting up mie/ray values etc


I need 26hrs a day. I'll want 48hrs a day when GT5 lands... hehe. Are you going to get a copy Ruud, would be cool to have a few games on line maybe

Dave

 

[DavidI]

I personally am happy with the shadows as-is for now, they aren't perfect, but look as good as anything else on the market (especially for the price!), and can be worked on more post 090 imho. There are better things to be done.

Move along folks, nothing to see here.

Maybe some sort of Slider that alters the smsplits values by some set ratio's in the config menu?

 

[Mr Whippy]

I've diff'ed the 2 versions and the only change should be the 0.9 -> 0.8 factor in v3InvWaveLength...

Hmmm, I've had a look through.

The 0.9 > 0.8 factor does change things.

However, it still looks too greeny.



Just a bit odd really, because from what I can tell that factor should be all there is to change, but it doesn't get the image looking right.

However, reverting to the 22 shader DOES get it looking like it did in my 22 screenshots. That is weird hehe.


The only other thing is that the colours are now defined differently:

22:
RayleighColor.rgb=color*xyz

23:
RayleighColor=float4(colour*xyz)


And that these lines are commented out:

22:
finalColor=(rayleighPhase/atmosRayleigh)*rayleighColor+(miePhase/atmosMie)*mieColor;
finalColor=(rayleighPhase+miePhase)/(atmosRayleigh+atmosMie)*(rayleighColor+mieColor);

23:

//finalColor=(rayleighPhase/atmosRayleigh)*rayleighColor+(miePhase/atmosMie)*mieColor;
finalColor=(rayleighPhase+miePhase)/(atmosRayleigh+atmosMie)*(rayleighColor+mieColor);

But I guess if you define something twice (as 22 does), then the 2nd one over-writes the 1st anyway, so that is no change?


Will do more testing here. I want to try get why the 22/23 atmosphere.cg shader makes such a difference despite the suggested technical difference only being the 0.8 factor (which gets half way there, but not all the way there )

Cheers

Dave

 

[DavidI]

line 83 in 0823 atmosphere.cg is

float3 v3InvWavelength=float3(5.8,13.5 * 0.9,33.1);

line 80 in 0822 is

float3 v3InvWavelength=float3(5.8,13.5,33.1);

Is this your difference Dave?

 

[Mr Whippy]

That * 0.9 factor in 0823 is done later in 0822, and it's 0.8 in 0822.

However, there is something else at play I think.

Gonna go back to out of the box 22/23 installs and do screenies I think, starting to confuse myself

Dave