Racer v0.8.21 out!

[Ruud]

It's been a while. Enough bugs still that need to be squased but let's not keep things too long.
v0.8.21 is at http://www.racer.nl/download/racer0.8.21.zip (63Mb).
The Blackbox DLL isn't used anymore -now I'm using VLD (Visual Leak Detector), which gave a few important memory leaks.

Known issues:
- Tracked displays Carlswood badly (white); something with the klux lighting

The changes from v0.8.20:
- Added improved process control for physics.async=1; the original process.cpu_affinity_mask now controls
the entire process (all threads). 'process.main_thread_affinity_mask' was added to control the main
thread cores. Additional, when physics.async=1, physics.thread_affinity_mask then controls
the cores on which the physics thread may run.
- 'cache_geodes' didn't work well when cars used data.ar to store .dof models. Common names like 'body.dof'
would conflict and different cars could use the same 3D models.
- Shadowmapping splits are now blended to make smoother transitions
- Shadowmapping per-split filtering can be turned on/off using renderer.shadowmapping.blur (0/1)
- renderer.auto_exposure.filter_gain was read incorrectly and thus had no effect (defaulting to 0.05). Fixed.
- Added wheel<n>.tire_damping_lowspeed and tire_damping_threshold for car.ini. Tires physically stiffen
up when rotating, but at low speed they get a lot of damping. Real life values arond 5.0 for the threshold
velocity and 2500.0 for tire_damping_lowspeed. See also http://racer.nl/reference/wheels.htm#tireforces
- dev.log_last now set to 0 by default since many people will not know what to do with QLOG anyway.
For content developers 1 is highly recommended.
- Removed the 'can't create envmap' error message on some DOF files - it isn't useful anymore.
- Switched Newton from v2.22 to v2.24. Small objects seem to have difficulty when colliding with cars.
- Modified dyn_standard_bump_speca_f.cg to accept 'scale' float parameter. This scales the normal map's
texture coordinates.
- Some large memory leaks fixed inbetween races.
- Renderer could crash in certain mixes of static geometry and custom geometry (particles/skidmarks etc)
- Ini keys with a dot (.) are found and warned about in QLOG. Some cars (F458 test version) had 'fresnel.bias'
defined directly in the ini file, which won't work (use fresnel { bias=xxx } ).
- View dials now have Cg shaders - data/renderer/shaders/viewelt_*.cg. Needed for klux lighting to avoid
very dark dials.
- Added bounce_amount and bounce_alpha properties for shaders to allow for lighting to not mix with the
alpha channel (Carlswood's road incorrectly reflected light; not enough light was reflected/bounced).
See also http://www.racer.nl/reference/shadereng.htm#matglobal
- Added surface 'grip_decline_driveline' property to allow grip to decrease when you go off the driveline.
Needs more work though.
- mirrors.texture.lod_factor set to 1.0 to avoid quickly disappearing geometry in the mirror

 

[Alexander Knoll]

Oh..Ruud...nice to see^^ Try it!

 

[luthobu]

Thanks! Good news is, got it to work by replacing dyn_standard_reflect_f.cg and
dyn_standard_bump_reflect_f.cg with the ones from 0815. Darker modes work almost
flawless (after a quick test), but daylight modes are either all white or look cartoon-ish
(dark contour lines). Will play more with TOD and other settings. Anyway, it's a great
improvement from 0820 which I could not run at all Cudos!

EDIT:
OTOH.. something must be very wrong? 0815 has, on my setup, almost perfect graphics,
while 0821 looks totally, well.. wrong! (See attach). So.. I'll stick to 0815.

Sorry.

 

[Some1]

Thanks! Good news is, got it to work by replacing dyn_standard_reflect_f.cg and
dyn_standard_bump_reflect_f.cg with the ones from 0815. Darker modes work almost
flawless (after a quick test), but daylight modes are either all white or look cartoon-ish
(dark contour lines). Will play more with TOD and other settings. Anyway, it's a great
improvement from 0820 which I could not run at all Cudos!

EDIT:
OTOH.. something must be very wrong? 0815 has, on my setup, almost perfect graphics,
while 0821 looks totally, well.. wrong! (See attach). So.. I'll stick to 0815.

Sorry.

What looks wrong? The only thing that might be wrong are the settings. The auto_exposure lights up the night too much perhaps?

I think the 0821 is the best so far. Blurring of shadowmapping splits, filter_gain for exposure works etc.
It's just that the out-of-the-box racer.ini is quite badly configured and the default car and track are getting old and out of date.

EDIT: Hmm, it seems one annying bug has returned - the shadow splits do not follow the camera direction. It was fixed in a previous version, but already reappeared in 0820. Hmm, It seems the splits follow the sun instead...

Currently, I'm trying to come up with best settings for shadow mapping; I want to get rid of this nasty aliasing. Help!

 

[luthobu]

What looks wrong? The only thing that might be wrong are the settings.
The auto_exposure lights up the night too much perhaps?

You could be right. I'll give it some more time before I pass judgement on it.
Really do want an improved version, but still want to keep the 0815 look

 

[Mr Whippy]

These damn shadows seem to be impossible to ever get looking nice.

I'd prefer less accuracy and outright quality if we could just have something solid and reliable... literally.

Since the move to CSM it just seems to be one compromise after another... personally I'd prefer to go back to the old depth space system which although not amazing visually, just worked with whatever you threw at it (from what I remember)



Nice updates generally though, the tyre damping model seems a good addition!

Not sure why this scale factor for bump map was added? dyn_standard_bump_speca_f.cg What are others using it for? (just wondering )

Cam will be happy with the dial shaders too!

Thanks

Dave

 

[insane666]

please how to reduce the lightning ?

 

[Some1]

There seems to be something funny going on with lighting. Ideally, the unlit areas (where the shadow is cast) should be as dark as the shadow, is this correct?

Look at the screen below: because of the poorish shadow accuracy, the self shadowing on that cube is a bit off, and you can see that the unlit side of the cube is lighter where the self shadow is off. Shouldn't it be as dark as the shadowed area to cover up the shadow inaccuracies?

 

[Mr Whippy]

That isn't, or at least shouldn't be self-shadowing, that's just an area of being unlit by the diffuse light source.

It should be just like that other box to the right hand side of your screenshot... obviously

Never seen that problem before... hmmm...

Dave

 

[Mr Whippy]

82 > 72fps over my old 0820 version, and the shadows now look worse.

They stop being rendered well in your view from the car, I had them rendering out to about 500m in the old version otherwise it looked odd them popping into view.

They also don't appear any sharper, looking more noisy, jaggedy and flickery more of the time.


Like LOD, shouldn't the shadow mapping draw distance vary depending on the FOV of the camera being used, because a camera looking at a car approaching a long way away with a narrow FOV is just seeing a car and scenery with no shadows at all.


Appears to be a complete step backwards in the shadow regard. Slower, and worse looking, and yet more artefacts visible during play.

Simply doubling or tripling the split distances doesn't increase the draw distance of that quality of shadow map either, it just goes all weird and liney and nasty

Isn't there any way to just have them work right? Either they do or don't? It's not like they are even acceptable right now like 089 were at first release. Sorry to rant but I just don't 'get it'
Tuning CSM seems to be like flogging a dead horse to me, or finding some magic mix of variables for every different camera or lighting angle. Madness. I just want trees 500m away to cast even 'ok' shadows onto my car as it travels towards the camera through a narrow FOV lens!



I vote for the old shadows from 089 again

Fast and looked 'ok' all the time



Will try the tyre stuff now too.


Also, the time per update for the auto-exposure is a bit slow and clunky/steps clearly seen. 50ms seems nicer with no real difference in FPS that I can see, 25ms seems ideal... not sure what the impact is of adjusting this lower really?!

Dave

 

[Alex Forbin]

I'm surprised no one has mentioned that the cameras (track and SMD) jerk when they move. It's as though they only move in 2 degree increments.

Alex Forbin

 

[Some1]

Dave, before you permanently decide that current shadow system is no good, please try my settings:

data\renderer\common\constants.cg:

const float shadowMapSize = 2048.0f;
const int iSqrtSamples = 2;	
const float smCor[SM_MAX_SPLITS]={0.00005, 0.0005, 0.001, 0.001};

racer.ini:shadowmapping

blur=1
profile0
{
      ; 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=10
      splitdist1=75
      splitdist2=300
      splitdist3=400
      ; the amount of frames to skip to increase performance
      splitrenderjump0=0
      splitrenderjump1=0
      splitrenderjump2=4
      splitrenderjump3=30
      ; 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
}

These settings are satisfactory, IMHO.

Still, I think the shadowing system must be optimized more than a LOT...

We also need the ability to disable self shadowing and shadow-receiving per object or per shader (which can be done with additional fragment shaders that simply won't calculate shadows). For example, tree lines, crosspolygon trees and such look weird and wrong when receiving shadows.

 

[Mr Whippy]

Map size of 2048?

That seems a bit large?

It's also defined per shadow profile now, and globally for the whole shadow section in Racer.ini, but seems pointless when it's set ONCE in constants.cg and they have to match.


I've seen them look good, once or twice, but the rest of the time they just seem to show up their limitations of being actually any good for dynamic lighting possibilities that TOD offers. Ie, get them looking good at midday, and they are shocking at dawn or dusk etc.

As per past threads on this shadow subject, am I missing something here? Shouldn't they get faster and better looking, not slower and crapper looking, with development time


Not to put a downer on the rest of Ruud's fantastic work, Racer is full of oodles of potential. Just I hate to see so much time wasted messing with these shadows, when as a user of Racer, and a fan of Racer, they are honestly not appearing to be worth the hassle over the old v089 depth space blurred ones (or whatever they were)

PS, didn't Mitch mention a 20-30% fps increase because of some optimisation? Is that in-place or not!?



Generally though, what do all these values mean when trying to tweak the shadows?

There are variables all over racer.ini and constants.cg (why they all can't be in a shadow.cg file we can swap/share easily!?) and I have no idea what any really do relative to any other!?


Dave

 

[Mr Whippy]

Hmmm, just noticed I was running 4 sqrtSamples before and had 80fps with 1024 texture maps... and I could see shadows at a good 500m away too, and had NO weird artefacts at most TOD's...

Now I can't get over 50fps with the same kinds of settings, and and can't get a view distance for shadows over about 200m...


I'm figuring something is broken here with 0.8.21?

Wish I'd kept my racer.ini file now from 0.8.20... those settings were really nice and I can't get anywhere near half as good now... grrr.


Can anyone explain how to make it so I can see shadows at say 1000m away? The split distance thing doesn't seem to work intuitively at all, are these tied into those weird values in constant.cg? const float smCor[SM_MAX_SPLITS]={ 0.0002,0.0003,0.0008,0.003 }; ??

Hmmmm

 

[Some1]

As far as I understand, each splitdist in racer.ini specifies the max distance that split is visible. So, to shadows at 1000m, you need a splitdist[n]=1000. Keep in mind, that currently, it seems that the max number of splits is 4.

So, perhaps something like:

splits=4
splitdist0=10
splitdist1=75
splitdist2=200
splitdist3=1000

Still, the less splits, the better, 2-3 should be enough.

The smCor values in constants.cg basically specifies the shadow offsets or something... It's a balance between the accuracy of the shadows and aliasing which appear at low angles wrt the sun.

Shadowing in computer games is real rocket science!
Currently, by looking at the shaders, the shadow blurring is quite slow. I've heard that using conditionals such as 'if' in shader languages is quite expensive.

 

[Stereo]

I've heard that using conditionals such as 'if' in shader languages is quite expensive.

The multi-threaded processors (on ATI cards in particular, to some extent NVidia) are not all equal, I suspect the cost is that the more complicated functions (anything outside mathematical ops) can't be run on the simpler processors on the chip, so it has to run pixels through fewer threads and gets slowed down.

Haven't had a chance to try the latest versions yet as I'm at my parents' with just my netbook.

Did have some fun last week overclocking my videocard, it's still pretty low-end but I got about 20% more fps in previous versions - next step I guess is to go into the .cg and see what is expensive.

 

[boomer541]

Oh my goodness, straight out of the box my FPS dropped from 175 to 154 on carlswood! then put all the tracks I updated to ver 0.0820 into ver 0.0821 and lo and behold they all worked very nicely but the FPS and shadows sucked.

Then updated racer.ini file to my liking and ran Surfaces and sounds track, FPS went from 174 down to 94, bummer then did a few things with the constants cg and the shadowmapping code and came up with very good shadows (except for moire patterns probably due to the fence) and FPS shot up to 194!

All I can say is great job Ruud! for those having trouble with shadows see the images below!



Last image shows the only changes needed but could probably be made better!

 

[camsinny]

Not sure where to start. Great to have a new version to play with.
Hitting a couple of walls though...The dials are still being reflected in the env.map (I thought this was fixed?) but it's not showing a live view of them like before.
Also, how and where do we define the shaders for the elts? or are they automatically defined? I also tried tinkering with the viewelt_f.cg but the emission value seems to not do anything...This may be due to the fact I haven't assigned the shaders properly yet though.

Sun also seems to play differently to the last version. Before where I had the sun coming up now it isn't. Direct copy of the track over to the new version. Are things being checked differently to the last version? Does the sun section need to be defined in a different place now?

 

[Mr Whippy]

I think the dials being reflected are the interior ones (ie, inside car cockpit view type)... if you define the gauge and dial as per an outside view type, but for the inside ones, then they are rendered in the envmap somehow... not sure how, but they are.


As for sun position stuff, all seems ok here for my UK locations and sunset/sunrise times/locations at different places/times of year... first thing I checked... hmmm... but I'm lucky running gmt0 offset and so on, maybe it's one of the adjustments that is a bit buggy?


As for shadows Boomer, they look nice. Sounds like it's the blur costing the fps then...

Personally I'm seeing better results just having a higher quality shadow map rendered further in to the distance, than trying to be clever and blurring them seamlessly between splits, which is clearly quite costly!


Some1, I get the split distance thing, but if you just input 1000 for the furthest one, it doesn't make shadows visible at 1000m.

It's almost like the split distance is the 'square' size for the map size defined. So if the 1st split is 15m, then the 1024 map is spread over a 15m sided box.
The next split is maybe 50m, so the next 1024 map is spread over 50m (and so gets more blurred)...
So by a 1024 split distance say, the 1024 map I'm guessing would be 1px ~ 1m shadow map accuracy. However, it seems that the weird correction factor thing (the four sets of small numbers 0.001 0.004 yadda yadda) has an impact on if it actually gets drawn and is visible or not.

My logic would be thus.

Determine the max distance you want to see shadows. The map size then determines the accuracy where the shadows stop being drawn. The closest split is probably best at 10m around the car (i guess that is then 5m in front, 5m behind, 10m sided square?)
There must then be an ideal falloff in the split distance to use to get the smoothest visible result to the shadows. Ie, if closest is 10m and furthest is 1000m, then maybe it's 4.5x at each split, so 10m, 45m, 200m and 900m.
Then the correction values must be ideal as a function of the maps size?

I just think we need an elegant way to scale the view distance of shadows because all tracks are different. Maybe even set a shadow render distance per track, or perhaps even flags along a track to set this value... hmmmmm... all just thoughts

 

[Mr Whippy]

Hmmm, just tried your settings Bumper, much better!

82fps > 92fps, and the shadows look generally much nicer. Yes, they are a bit jaggedy, BUT, they are solid.

They won't go winning screenshot of the year competition, but who gives a crap about screenshots. I want them to look right when I'm driving around and watching replays. Photomode can run at 1fps for all I care, just have a photomode setting

The rest of the time fps and solidity to the shadows matter to me



splitdist0=10
splitdist1=44
splitdist2=200
splitdist3=850
; the amount of frames to skip to increase performance
splitrenderjump0=0
splitrenderjump1=0
splitrenderjump2=0
splitrenderjump3=0


They work really nicely imo.


Still getting that weird offset that Some1 showed though, where there is shadowing on lit faces of some shapes, or it's kinda like a self-shadowing offset slightly into the model, so rather than the object just getting ambient lighting, it's ALSO getting a shadowing from itself on back-faces!?!?

As Some1 said, is this to do with the splits working oddly? If I drive under a camera with the car, then I get a strobe of dark/light bands passing across the screen. It's like the splits are being done relative to the wrong thing. Surely they should just work relative to the car/camera distance?! Hmmmmm, hmmmmm



Dave