Racer v0.8.27 released!

[Ruud]

Hopefully quite close to v0.9RC1.

Get it at http://www.racer.nl/download/racer0.8.27.zip (75Mb)

The changes:
- move_cg=1 didn't offset correctly: cameras, wipers, generic models, brake calipers, exhausts, dials, helmet, carlights Z/far.
- 'rewind' commands for live rewinding (if RTD logging is on)
- Default font made a little bigger again
- onspeedlimiter.rex gets executed when the speed limiter is turned on.
- Shadowmapping tweaked for director and other cameras.
- Fuel consumption reset to 0 when standing still (was 99.9 L/100km).
- A missing controller (defined in a controls file) would crash Racer
- Using something other than default.ini in racer.ini's ini.controls now works (can be saved)
- 3 profiles available in the controller setup screen.
- The names above the cars were black - fixed with floatingname_*.cg shaders.
- The wheel blur models would show in the car selection garage.
- Added grass smoke particles
- Select car/track screens sped up by loading only part of the car.ini/track.ini files. Assumes 'car' is at the top though (!).
- Selecting a car, then exiting would crash.
- When cars stood still, too much was damped away and the differential wheels would rotate a bit.

 

[Ruud]

I can upload my shadow test scene if you like. Although, it is a bit primitive, and perhaps could use more different objects, but overall, it does the job.

That scene would probably be helpful yes.
Also note that I just set textures.enable to 0 to check a track with all-white textures. I use it for shadows myself a lot as well.

 

[Mr Whippy]

I've moved the heli down a bit. Also, I now only blur split 0 and 1.
The last fade is in BlendSplits() in shadowmapping.cg; you can clone that and make your own, but the extra instructions are not worth it IMHO. It will be slower again just to tweak the end fade

An extra smCor[] will also cost more performance; I'd rather keep it worst-case for both camera profiles.

Hmmm, don't have the latest version of Racer here at work. So is the fade simply a hardcoded value? Just that if I tweak the split distances I might want to tweak the fade too... I was just making sure that the two are independent, which it sounds like they are. Ie, we need to go tweak the fade point independently of the split distances.

Just curious why extra smCor impact performance? Surely when you use one profile or the other it uses either one set of smCor/splits or another?
It just seems odd to use smCor across both profiles when they use different split distances, which seem to be the thing we tune smCor against... smCor ~ split sizes... they are like tuned to each other.
Car exteriors now look very nice, but the interiors are still suffering, I can get them looking nicer, but the the outside ones are not optimised hehe

Dave

 

[Mr Whippy]

That scene would probably be helpful yes.
Also note that I just set textures.enable to 0 to check a track with all-white textures. I use it for shadows myself a lot as well.

Ah, good tip

Dave

 

[Ruud]

Hmmm, don't have the latest version of Racer here at work. So is the fade simply a hardcoded value? Just that if I tweak the split distances I might want to tweak the fade too... I was just making sure that the two are independent, which it sounds like they are. Ie, we need to go tweak the fade point independently of the split distances.

Just curious why extra smCor impact performance? Surely when you use one profile or the other it uses either one set of smCor/splits or another?
It just seems odd to use smCor across both profiles when they use different split distances, which seem to be the thing we tune smCor against... smCor ~ split sizes... they are like tuned to each other.
Car exteriors now look very nice, but the interiors are still suffering, I can get them looking nicer, but the the outside ones are not optimised hehe

Dave

The fade is currently a fixed percentage of the last split (10%). From BlendSplits():

shadowCoord.x=min(1.0f,(0.5f-abs(shadowCoord.x-0.5f))*5.0f); // 0.1f

This takes 10% of the outer sides. It then lerps (linear interpolation) this towards complete fadeout. So you could tweak the last split by calling a clone of this function which does another calculation, but that costs more instructions.

The extra smCor: it needs to be decided inside the fullscreen pixel shader which smCor to use. That is 1 'if' at least. And it is done for every pixel, so around 2 million times per frame. That's why every instruction counts. smCor is used in several places so should somehow be redirected, or an offset into the array added (smCor[i+profile*4] for example). If we can do without, it's faster. With shadows, it's all about compromises... as you've learned by now.

 

[Mr Whippy]

Hi Ruud,

Sorry, I'm still not a really fluent cg reader

So that means that the fade always starts at 0.9*splitdist3, and is the fully faded out at splitdist3

So if splitdist2 is 495m, and splitdist3 is 550m, then the fade will begin exactly at the edge of splitdist2, and fade linearly to the edge of splitdist3?
If splitdist2/3 are too close, then weird things will happen I guess. But that isn't an ideal thing to do anyway.

I guess I'll be able to see this by experimentation. That logic seems sound


Simply put, the fade exists over the last 10% of the shadow total range (defined by splitdist3)




As for the smCor part, does that mean the different profiles for inside/outside is costly? Deciding what split sizes to use for each camera type?
Ie, is that part of the process and 'if' statement too?


Thanks

Dave

 

[Some1]

That scene would probably be helpful yes.
Also note that I just set textures.enable to 0 to check a track with all-white textures. I use it for shadows myself a lot as well.

Ok, I've uploaded it -> thread.