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

 

[Mr Whippy]

ALSO, has anyone noticed how the sun is tinted heavily blue in the kLux output? You can even see a blue tint around it in the sky...

We set ray/mie to get the sky looking right, but this also seems to impact the sun. Is that right?

I'm feeling we need to split the sun blob and the sky rendering into two. That way we can get the sky colouring/tinting/intensity right, and then the sun size, colouring, intensity right independently.

Hmmmmm

Dave

 

[Alex Forbin]

SMD cameras are definitely broken, the only way to stop the jitter is to put maxdist=0 in the src and dst sections.

I suspect it's a problem with the new implementation of Newton. Ruud, since you're going to look at the cameras why not find out why they swing in an arc when you turn?

Alex Forbin

 

[Mr Whippy]

Hmmm, my cameras seem fine here.

Have you tried deleting the cache for the track collision thingy, and let Newton rebuild it?!

Dave

 

[Some1]

Hmmm, my cameras seem fine here.

Have you tried deleting the cache for the track collision thingy, and let Newton rebuild it?!

Dave

Yep, I confirm that the cameras look fine here... Alex, can you provide an example of an SMD camera configuration that is jittery?

 

[BVSX]

When new betas will give me more than 16 FPS? Don't see that much graphics improvements that eat all of my FPS
Anyway, is great that RuuD don't giving up and make more and more betas.

 

[Mr Whippy]

Yep, you can't make an omelette without breaking a few eggs


But as Bumper found out, the blur on the shadow map seems very costly. I'm happier running a much larger shadow map without blurring.

Not perfect, but just playing GT5 Prologue earlier and there are plenty of times you can catch the shadow mapping getting a sawtooth edge... I'm happier with some sawtooth edging and a sharper shadow I think, than soft-edges which you can't really appreciate unless you screenshot anyway, but cost you in game-play speed

Dave

 

[Stereo]

Bit of a bad way to fix a problem with the shadows...

If you open up shaders\shadowmapping.cg, and find

      fShadowTerm += fSample;
    }
  }

  fShadowTerm /= ((trsSamples+1)* (trsSamples+1));
  return fShadowTerm;

Commented out original code, new line

      //fShadowTerm += fSample;
      fShadowTerm = max(fShadowTerm,fSample);
    }
  }

  //fShadowTerm /= ((trsSamples+1)* (trsSamples+1));
  return fShadowTerm;

Instead of using the average distance, it just uses the least good shadow distance - so there's no more ripple patterns along sharply angled surfaces. The tradeoff is that the edges of the shadows are more jagged, and the different map levels won't blend quite as smoothly into each other, and it's really not improving performance.



In general I've been reading through shadowmapping.cg to see what I can optimize... nothing good yet.

 

[Alex Forbin]

Yep, I confirm that the cameras look fine here... Alex, can you provide an example of an SMD camera configuration that is jittery?

Thanks for the reply guys, I think I figured it out. The cameras are fine, I just had the masses and springs set too high, it used to work but now doesn't.:tongue:

I would still like to see the swinging taken out though. To see the effect just turn right and left quickly, you will notice the dash and roof-line moves closer and farther away. While I have gotten somewhat used to it I think it could be responsible for some people getting motion sick.

Alex Forbin

 

[boomer541]

The settings in the image I posted on page 2 work very well with gyral and swiss stroll tracks, no jagged edges apparent. There were NO other changes to constants.cg or racer.ini. The FPS was a good improvement over ver 0.0820.

I have got to check shadows with other tracks that have fences to see if they have the moire pattern problem.

Also car shadow flikers as it speeds along a track and sometimes disappears. Ruud needs to fix.

If anyone wants to try my racer.ini or constants.cg I'll post them.

 

[MitchVL]

If you guys have some solid settings for shadowmapping that you prefer, send them to me, so it will be the default in the next release.

If you want extra frames, set shadowmapping.blur to 0 and be amazed, the downside to this is that the shadows will be more pixely.
That's where my setup gets 50 procent more frames.. very recommended if you have a slow card..
Reducing iSqrtSamples to 2 in constants.cg will also help.

if you have CSM-artifacts at low sun-angles, or even at a default angle, raise the values set for smCor in constants.cg (use the console command "reload gpushaders" so you don't have to restart Racer)


I recenlty participated in GT5 contest, racing on the nordschleiffe with a SLS, with a pretty recent GT5 build.
The shadowmapping quality was very poor incar, you could see the pixels running by.
Shadowmapping is very hard to get right, and if you look at other games, they have problems to.
Every implementation has it's drawbacks. You guys might be right when saying that the screenspace one was better, but the current one can't be that much worse with some tweaking. (The screenspace implementation had problems with alpha-objects...)

 

[Some1]

If you guys have some solid settings for shadowmapping that you prefer, send them to me, so it will be the default in the next release.

If you want extra frames, set shadowmapping.blur to 0 and be amazed, the downside to this is that the shadows will be more pixely.
That's where my setup gets 50 procent more frames.. very recommended if you have a slow card..
Reducing iSqrtSamples to 2 in constants.cg will also help.

if you have CSM-artifacts at low sun-angles, or even at a default angle, raise the values set for smCor in constants.cg (use the console command "reload gpushaders" so you don't have to restart Racer)


I recenlty participated in GT5 contest, racing on the nordschleiffe with a SLS, with a pretty recent GT5 build.
The shadowmapping quality was very poor incar, you could see the pixels running by.
Shadowmapping is very hard to get right, and if you look at other games, they have problems to.
Every implementation has it's drawbacks. You guys might be right when saying that the screenspace one was better, but the current one can't be that much worse with some tweaking. (The screenspace implementation had problems with alpha-objects...)

What Mitch said!

Actually, I think that the current implementation is the best. Because of shadow splits, we can get high res shadows in car cockpit view when the shadow profiles can be tied to cameras. There is still a lot to be optimized and tweaked, but I think CSM is the way to go.

We need to come up with optimal shadow settings that would be included in the following betas. Also, maybe there are some ways to optimize the blurring as well...

 

[DavidI]

Shadow blurring also seems to cause me problems around treelines and fences etc; as ALL edges of the shadow are blurred, at the baseline of the treeline/fence u end up with an un-natural unshadowed area. It occurrs when the 3rd or 4th split is used.
Also while on shadows, they seem to be a uniform darkness regardless of the height of the object above the surface where the shadow falls. Shouldn't the shadow be lighter & more diffused the further it is from the shadowed surface?

 

[Mr Whippy]

If you guys have some solid settings for shadowmapping that you prefer, send them to me, so it will be the default in the next release.

If you want extra frames, set shadowmapping.blur to 0 and be amazed, the downside to this is that the shadows will be more pixely.
That's where my setup gets 50 procent more frames.. very recommended if you have a slow card..
Reducing iSqrtSamples to 2 in constants.cg will also help.

if you have CSM-artifacts at low sun-angles, or even at a default angle, raise the values set for smCor in constants.cg (use the console command "reload gpushaders" so you don't have to restart Racer)


I recenlty participated in GT5 contest, racing on the nordschleiffe with a SLS, with a pretty recent GT5 build.
The shadowmapping quality was very poor incar, you could see the pixels running by.
Shadowmapping is very hard to get right, and if you look at other games, they have problems to.
Every implementation has it's drawbacks. You guys might be right when saying that the screenspace one was better, but the current one can't be that much worse with some tweaking. (The screenspace implementation had problems with alpha-objects...)

Blur off seems to be the way to go!

We can seem to get better trade off that way, bigger maps reduce the visible edge jaggies, at less cost than blurring the smaller shadow maps.

Then as we want softer shadows (say a partially cloudy day with the sun behind mist), we can use smaller shadow maps with more blur...


I agree on the GT5 shadows etc. I played GT5 Prologue yesterday, and the new NFS HP demo on the PS3, and both had visual shadow artefacts and jaggy edges.
I think where GT5 wins, and FM3 etc, is that the 'photomodes' and so on use higher settings possibly with lower FPS, so they look really good when you look at the details. But in-game they then return to faster settings and generally you won't notice the issues as they are flying by at 100mph


I'll post my settings later, but they are very similar to Bumpers... mainly bigger maps, no blurring. It seems for a sharp sunny day no blurring is ideal imho.


Is there any way we can migrate the split and shadow profile info set in Racer.ini to the constants.cg file... then we should be able to share/swap settings really quickly all from one place


Also, what exactly do the smCorr values do? Ie, are there any general guides which way we should take the values depending on the visual errors. Can we go too far one way or another? Ie, too small or too big etc?

Dave

 

[Mr Whippy]

Shouldn't the shadow be lighter & more diffused the further it is from the shadowed surface?

Try Racer in another 5 years when we have the GPU power

I guess that falls under the ambient occlusion somewhat too, ie, ambient light in-filling more away from the occluding object.

Dave

 

[Stereo]

That one should actually be fairly easy to add in from the current method, it's just a question of whether it'll look good (and it'll only be able to use a single shadow distance, so objects that are entirely in shadow can't contribute further shadowing). The wider it tries to diffuse the more samples it needs. I remember in the old ambient occlusion there was an issue of using a random texture as a source of noise to make it less patterned, but it had to be hardcoded or something, so not really an option for those of us just fooling around.

Still need to draw a schematic of what the shadowmapping functions are doing on a sheet of paper or something so I can work out where it's comparing depths. Once I have that it's just a matter of making it drop off the farther it gets from the source of the shadow, and maybe spreading out the source pixels on the shadowmap.

 

[Mr Whippy]

The problem is, the effect is a function of more than just the distance from the occluding object. It will depend heavily on the surrounding objects.

Ie, a tree casting a shadow on it's own in a large concrete area, will have a shadow with a different falloff to one surrounded by 15m high concrete walls which are occluding ambient light from in-filling the shadow as much.

That in-filling will also contribute to what appears to be a softer edge to the shadow the further it is from the source casting object, as will atmospheric particles etc etc...

Imo, simulating the effect that way is rather too simple and will lead to it looking incorrect for half the time where it's applied where it's not wanted.

Hmmmm

Dave

 

[boomer541]

Tried setting the mapsize to 4096, but the Qlog monster came and ate my memory and left a note in the Qlog file!

I also have the problem same as DavidI, no shadow close to the base of an object.

 

[KS95]

Auto-exposure causes quite bad lag, FPS are a steady 25 but gameplay is still very jumpy. It's perfect without auto-exposure though

 

[QuadCoreMax]

Anyone having this issue, a grey & white menu ?

Is there any easy fixing for this ?



Same for Tracked....(Known Issue)



===============
Running on ATI 4670
XP SP3

 

[DavidI]

The problem is, the effect is a function of more than just the distance from the occluding object. It will depend heavily on the surrounding objects.

and its even more complex than that. take a tree for example, say a pine or fur tree, triangular tall thing.
The branches at the bottom, being close to the ground would blur/diffuse less than the topmost branches, and would also depend on the sun angle to some extent.

Maybe an averaged height would suffice. and maybe that average height sets the amount of blur and partially the darkness of the shadow?

KS95: Phenom 6 core 2.8Ghz CPU 8GB RAM, GF460GT, with shadows I get 70fps upwards (pending the track & how many ai cars), with shadows off 200+ fps.
try changing your GPU settings with nvidia or catalyst control panel, go for lower/less demanding settings.