Racer v0.8.18

[Mr Whippy]

http://www.racer.nl/download/racer0.8.18.zip

Ruud didn't do an official thread for this, but he did post up the link on here somewhere, so I guess he is happy for us to use/test it if we like!

Anyway, I'm using it and there are some useful changes, and also some bugs I wanted to note.


Release notes:

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.

 

[camsinny]

Is 1m the smallest CSM split distance possible?
I tried setting it to 0.5 but that seemed to create no shadows at all which suggests it broke it.

We really need a different way of doing shadows for interiors!!

###EDIT###
Also, what's the deal with 3d dial shaders?

 

[Some1]

Is 1m the smallest CSM split distance possible?
I tried setting it to 0.5 but that seemed to create no shadows at all which suggests it broke it.

We really need a different way of doing shadows for interiors!!

What's wrong with interior shadows?

 

[gtpdzbiz]

What's wrong with interior shadows?

The splitting for CSM in Racer is static at the moment, which means fixed shadow texile resolution in a given splitting distance, not a big deal for third person cam as shadow texile/screen pixle ratio is large enough to hide the artifacts, when in a on board camera situation, the shadow tex/screen pix ration dips down and shadow texile becomes very apparent and jaggy. Also due to the fixed shadow bias value, the 'peter panning' effect(shadow discontinuity at object contact area) becomes more apparent in a close up cam.

 

[Some1]

Well, yeah... my current setup was good enough for me, I guess I didn't realise the artifacts so much.

Shadow settings (splitting dists and bias) should be somehow specified dynamically per camera.
Maybe a single value like "shadow_detail" or "shadow_bias" or similar in the camera definition that would be used to multiply the split dists and bias?

 

[camsinny]

Yeah, maybe just on cameras that have the model=1 in the car.ini we could have a secondary definition for shadows?

Was going to suggest the screen based method but then remembered that that would require a re-write of the render pipeline. oops.

 

[Some1]

Yeah, maybe just on cameras that have the model=1 in the car.ini we could have a secondary definition for shadows?

Was going to suggest the screen based method but then remembered that that would require a re-write of the render pipeline. oops.

You mean screen based blur? Please no, it really doesn't look good at all.. :S

 

[camsinny]

Well as long as we have a shadow solution for interiors that looks good I don't care how it's done haha

 

[MitchVL]

Splits that small (1m) are never gonna work with TOD.
You are better off with a higher splitdistance, about 4 meters, and raising the shadowmap resolution, which is preferred for higher detail in CSM.

 

[boomer541]

I was having trouble with split distances due to the dark square problem and reduced to just 2 splits, posted my solution in the raceproblems and fixes thread.. I wound up with 60 and 1000 for split distances, this needs work to get good shadows down a long fence or line of trees.

Also had problem with tracked, set autoload = 0 in the .ini file and it crashed on opening. Drove me batty until I changed it back to = 1, needs fixing.

 

[MitchVL]

Thanks for the report Boomer.

I changed the smCorrection stuff, now you only need one, since all the shadow maps have the same near and far planes. So no matter how the splitdistances are set, no additional tuning of the smCorrection is needed.
Im currently implementing shadowmap-profiles, so you can use a different profile for different cameras.
Each profile uses a different render buffer, so you should only use 2 profiles (interior, exterior) to save GPU-memory

 

[gtpdzbiz]

Thanks for the report Boomer.

I changed the smCorrection stuff, now you only need one, since all the shadow maps have the same near and far planes. So no matter how the splitdistances are set, no additional tuning of the smCorrection is needed.
Im currently implementing shadowmap-profiles, so you can use a different profile for different cameras.
Each profile uses a different render buffer, so you should only use 2 profiles (interior, exterior) to save GPU-memory

That's quite interesting, so the interior and exterior are rendered to different buffers? I was thinking that camera defined profile would only involve some different sets of smCorrections and such...

 

[Mr Whippy]

If these shadows look good on one setup, should they look good on all set ups, or is it resolution based with other factors?

Two render buffers sounds odd, but I guess sensible otherwise shadows of stuff outside the car, and other cars, will look odd if they use the interior ones.


How come the old depth space blurred, CSM shadows, worked so well here, yet these new ones don't?

I'm still struggling with why these new shadows are better, because they don't look it except in still optimised screenshots, and they are not quicker from what I can see, and they now need two buffers to work. Is this the technique all modern games use, or is this a new method being pioneered here?

Dave

 

[MitchVL]

Well actually, it is being rendered to different buffers because the texture-atlas system is restricted to a single profile, meaning that you cant really reuse a buffer (for now) because it might have other dimensions and such... I want to keep this profiles so we can support mulitple lightpoints with shadows later on. The only thing we lose now is a bit of GPU memory. If your card cant miss that, its probably to slow to run shadowmapping anyway, but dont worry, its temporary.. still a lot of work to be done

In the meantime i had to overhaul the system once again because it didnt run well on NVidia (yes, this time it was the other way around) so we still have the smCorrections ... but a good set of defaults should work on all Cards since the CSM frustums always have the same depth from now on, so its definitely an improvement.

The new shadows definitely look better on NVidia cards, because of the PCF filter, i dont really agree with you there Mr.Whippy.
Shadow mapping still eats a lot of frames indeed, thats something to take a look at for the final release (tweak renderer ... )

 

[Mr Whippy]

I'm not saying they are not better generally. They have shown they are better and more accurate in a still picture where the settings are optimised. Interiors are still not so nice at all. It'll be nice to see interior shadows working nicely with this new shadow technique

But in motion they just seem to have plenty of issues that, all up, make them not so great right now. If these problems can be resolved without costing more fps then I'll be happy enough. But if the overall cost is a significant drop (5-10% + ) in FPS just for accuracy that can only really be noticed in still shots, then it's a harder call to make I guess...

I'm just thinking of those with the lesser computers, I've just done an upgrade to a 275GTX and at 1600x900 resolution it's borderline on dropping into the sub 60FPS area on more graphically complex tracks right now...

I guess there is the 'optimisation' stage to come for the final which might buy some FPS back though

Excited to try out the interior optimised shadows!

Dave

 

[Alex Forbin]

Well actually, it is being rendered to different buffers because the texture-atlas system is restricted to a single profile, meaning that you cant really reuse a buffer (for now) because it might have other dimensions and such... I want to keep this profiles so we can support mulitple lightpoints with shadows later on. The only thing we lose now is a bit of GPU memory. If your card cant miss that, its probably to slow to run shadowmapping anyway, but dont worry, its temporary.. still a lot of work to be done

In the meantime i had to overhaul the system once again because it didnt run well on NVidia (yes, this time it was the other way around) so we still have the smCorrections ... but a good set of defaults should work on all Cards since the CSM frustums always have the same depth from now on, so its definitely an improvement.

The new shadows definitely look better on NVidia cards, because of the PCF filter, i dont really agree with you there Mr.Whippy.
Shadow mapping still eats a lot of frames indeed, thats something to take a look at for the final release (tweak renderer ... )

Multiple lightpoints sounds great, I assume this will be for tracks that have street lamps and such?
As an aside do you know if the damage code that someone was working on with you actually worked?
Also I remember something about a prize winning programmer reworking the particle system, any news on that?

Thanks
Alex Forbin

 

[MitchVL]

Dave,
Shadow mapping is very hard to get right in combination with TOD (low sun = disaster), hopefully well get that right eventually.
I'm going to see what gDebugger can do for us to optimize performance, hopefully that helps.

Alex,
Yes, if we were to implement that, it would be for such use. But that requires a deferred renderering system. It's just a good idea to keep everything as generic as possible, so future plans are never restricted by existing code.

There is no damage code, who said that? I recall Quadcoremax dreaming about that in a thread, probably a misunderstanding there

The particle system is working already, it's much faster than before and that was Rob (He won second prize with his team this summer at the imagine cup) was aiming for.

 

[Alex Forbin]

Alex,
Yes, if we were to implement that, it would be for such use. But that requires a deferred renderering system. It's just a good idea to keep everything as generic as possible, so future plans are never restricted by existing code.

There is no damage code, who said that? I recall Quadcoremax dreaming about that in a thread, probably a misunderstanding there

The particle system is working already, it's much faster than before and that was Rob (He won second prize with his team this summer at the imagine cup) was aiming for.

Thanks for the feedback as always Mitch.

Here's the relevant quote from the post about damage...

@Alex Forbin

Damage is fully possible now with Racer, after some testing with skinned meshes it's almost perfect ! Special thx to Mitch for the help.

On second thought I think what he was actually saying was that he had tested skinned meshes and that THEY were perfect and not that he had actual damage code. I was wondering how he got the impact velocity and direction information.
Still it seems like a fairly simple addition from where we are at, and it does look a bit odd to hit something hard and have sparks fly with no damage. That being said, GT got away with it for a long time.

Alex Forbin

 

[Some1]

I guess, I'm the only one, but I think the current shadows look great overall, even in interiors. Just a little tinkering with the splitdist and other values and you can get pretty decent results. Keep in mind that even the most advanced games still have graphical glitches and shortcomings. Things never aint perfect anyways.

Come on, people, we have shadow mapping in Racer!!! So what it's not perfect, nothing is.

As for modding, do you think it would be possible to monitor the amount of video memory and/or other resources used by the selected car and track. It might help to optimize mods I think.

GTA4 calculated the amount of video memory used by the current settings, I remember...

 

[Mr Whippy]

This video was from the first CSM beta, and I've seen nothing as nice looking since we moved away from that system...

When interior shadows look that good again, and generally, the random issues with the new ones are mainly all gone, then I'll buy into them.

I'm still wondering if all the extra development time and complexity will be worth the wait, since in motion I really can't see much difference here
No matter what it seems under certain conditions the weird lines appear on bodywork etc, or down the sides of the car when they are in that gap between lit and unlit. The old CSM system with depth blur had no such issues at dusk/dawn or anything. It just worked it seemed. Again, I don't get where the hate for the old system comes from. Was it really that bad? It seemed to work better and better at every iteration until we moved to this new system, and now it's just moving between compromises each time it's updated.

Perhaps it's just me, but I'd like to know specifically why the old one is so bad. Looking back through my screenshots it looks fine in almost all conditions. Again, not as nice as the new system in a big high res screenie, but why not have a 'photomode' shadow system for people who just take pictures all day?



All good either way, it's just a shame if these shadows are holding up other developments, because there are much bigger concerns I have about the graphics like the stippled alpha transparency which imo totally offsets the visual benefits of slightly sharper or more accurate shadows in screenshots

Dave

 

[Some1]

The old CSM system with depth blur had no such issues at dusk/dawn or anything. It just worked it seemed.

Okay, I'm a little confused. Depth blur? I know, the first attempt at shadow mapping used shadow blurring in screen space and that just looked plain wrong. I mean, the further the camera went, the more noticeable the blurring become and it looked like many light flares, just inverted colors.

Current system, where the shadows are blurred in texture space is much better, IMHO. Yes, we need blurring between cascades, and the parameters need to be tweaked to avoid artefacts like when the angle between the surface and the sun gets low...but still...