Racer v0.8.22 released!

[Ruud]

Yep, it's at http://www.racer.nl/download/racer0.8.22.zip (63Mb).
Known issues:
- Tracked still displays white
- Generic models don't get transformed correctly to their right location

Mostly this version is a lot nicer in the tonemapping/HDR department; I think it's quite good enough to leave as is for v0.9, so it's easier from now on to tweak content for.

Changes:
- Added speed limiter (controlled per car); see http://www.racer.nl/tutorial/engine.htm#speedlimiter
- If the speed limiter is on, the rpm_warning variable will 'flash' between 0 and 1. Useful
for Formula-style cars which indicate it that way.
- Added view var 'speed_limiter' that is 1 if the speed limiter is enabled (default: SPACE key)
- Added rev limiter time per car; see http://www.racer.nl/tutorial/engine.htm#revlimiter
- Added view mapping curve to map input values to output values. This allows for non-linear
dials, such as km/h gauges, commonly seen on lots of cars. See http://www.racer.nl/tutorial/dials.htm
and look for the 'map' variable.
- HDR tonemapping now uses the Uncharted 2 method. See http://www.racer.nl/tutorial/hdr.htm
This looks cleaner (a bit in the GT5 direction). In constants.cg you can add some gamma to increase
contrast (default=1.0).
- Modified auto exposure filter gain from 0.1 to 0.001 (much slower)
- Decoupled dynamic exposure integration from exposure sampling; made it smoother with less sampling.
- dyn_standard_bump_reflect_f.cg had a bug in its fresnel calculation, resulting in funny reflection
factors. Fixed.
- Multiplayer collisions using forces/torques instead of SetPosition(). Newton could get seriously
stuck when doing that (taking >1 second while resolving collisions for a single step).
Still a bit alpha functionality.
- Flares are now rendering using Cg to be able to give them more light. The 'color' property
of a flare should now be in klux, so a value of around 'color=40 40 40' should be better.
- TOD editor can now zoom in with Z key (multiple zoom levels); some curves needed precision at the low end.
- TOD exposure curve improved so things also work without auto-exposure.
- standard_mix*.cg shaders changed to put the most important texture in layer0. This was needed since
projective lighting only uses the first texture to light the scene, and that was a control texture,
giving funny black & white looks when lit. See http://www.racer.nl/reference/gpushader.htm
- Renderer now caches OpenGL's texenvmode for a small performance gain.
- Added 'reload track' console command.
- Added 'sound reverb <n>' console command. Useful in combination with trigger lines to give certain
areas of the track reverb sound. See http://www.racer.nl/reference/scripting.htm
- Carlswood sky improved (thanks to Luthobu)

 

[Alex Forbin]

Bug: Exhaust backfire will only pick up the first defined exhaust position.
Bug: Sliding upside down still applies weird forces to the car that causes it to slide erratically (sometimes in a very obvious arc). While this may seem trivial I can't help but think that it is applying these odd forces ALL the time, and that it just shows up when you are on your lid.

Alex Forbin

 

[Marcin Sobkowiak]

Every time I turn off shadowmapping (I need to if I want more than 14FPS!) I end up getting this error:

Even if I turn it back on via the racer.ini, I get the same error. The only fix I've found so far is extract the racer.ini again and replace it, help!

same here, I have no idea how to fix it...

My Qlog:

Tue Nov 16 02:37:48 (INFO): [noqapp/4420] --- application start ---
Tue Nov 16 02:37:48 (WARN): [noqapp/4420] QInfo: can't open 'data/tracks/./track.ini'
Tue Nov 16 02:37:48 (WARN): [noqapp/4420] QInfo: can't open 'data/tracks/../track.ini'
Tue Nov 16 02:37:48 (WARN): [noqapp/4420] QInfo: can't open 'data/cars/./car.ini'
Tue Nov 16 02:37:48 (WARN): [noqapp/4420] QInfo: can't open 'data/cars/../car.ini'
Tue Nov 16 02:37:48 (ERR ): [noqapp/4420] QInfo(data/cars/bmw_e38/car.ini); brackets don't match; still 1 closing bracket(s) expected at end of file.
Tue Nov 16 02:37:50 (INFO): [noqapp/5188] --- application start ---
Tue Nov 16 02:37:50 (INFO): [noqapp/5188] 2 processor(s); setting affinity to 0x3
Tue Nov 16 02:37:50 (INFO): [racer/5188] Racer version: 0.8.22 (Nov 10 2010/18:36:22) - customer: Internet
Tue Nov 16 02:37:51 (WARN): [racer/5188] DGPUShaderManager:MakeObject(data/renderer/fullscreen_shaders_hdr/bloom_f.cg): can't create CG fragment shader program
Tue Nov 16 02:37:51 (WARN): [racer/5188] DGPUShader::LoadAndCreateFromFile[data/renderer/fullscreen_shaders_hdr/bloom_f.cg]: CG ERROR : "The compile returned an error."
Tue Nov 16 02:37:51 (WARN): [racer/5188] data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(242) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(273) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(311) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(316) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(366) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(409) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(375) : error C1008: undefined variable "gamma"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(375) : error C1115: unable to find compatible overloaded function "pow(float3, error)"
Tue Nov 16 02:37:54 (FATAL): [racer/5188] DGPUShaderManager:MakeObject(data/renderer/fullscreen_shaders_hdr/bloom_f.cg): can't create CG fragment shader program
CG ERROR : "The compile returned an error."
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(242) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(273) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(311) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(316) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(366) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(409) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(375) : error C1008: undefined variable "gamma"
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(375) : error C1115: unable to find compatible overloaded function "pow(float3, error)"

and PC specs:ASUS N61VG: C2D T6600 2,2GHz, GF GT220M 1GB, 4GB of RAM, Win7 Home Premium

GTA IV runs well, Racer 0.8.22 only in non-cg at ~390 fps (on carlswood track with MB SL65)

 

[Stereo]

The problem is in the fullscreen shader, in \racer\data\renderer\fullscreen_shaders_hdr\, in this case bloom_f.cg, or passthrough.cg. As a result of the new tonemapping, which I guess was just tested with bloom_shadows_f.cg.

Up at the top, it should have

#include "../common/hdr.cg"
#include "../common/constants.cg"

Without constants.cg it can't find a value for gamma so it crashes I suppose (I can't replicate the issue here, mine runs fine without shadows)

 

[radome]

go to this line:
data/renderer/fullscreen_shaders_hdr/../common/hdr.cg(374)
and uncomment it
Then change line 375 if you want to. I took off the 1.0/2.2 and it seems OK

 

[Ruud]

Every time I turn off shadowmapping (I need to if I want more than 14FPS!) I end up getting this error:

Even if I turn it back on via the racer.ini, I get the same error. The only fix I've found so far is extract the racer.ini again and replace it, help!

A problem with fs_filter1. I've fixed passthrough.cg and inserted an:

#include "../common/constants.cg"

at the top for example.

 

[Ruud]

Car shadow disappearing with track camera is due to wrong constant variables, try the constants file below.

More problems!
Background movie doesn't work!

Change the speedlimiter key in controls.default.ini from space to t as space is used with edit TOD!

Got good shadows with constants.cg and racer.ini splits. See attachments below.

blur=0 and autoexposure on. If autoexpsure off the lighting is too bright so I need to adjust the TOD and special.ini settings.

The background movie works ok here; I had to install a codec though; hunt for wmv9VCMsetup.exe on the net.
I won't fix the SPACE vs speedlimiter control; you normally don't use the TOD editor too much, so it's not such a big deal.
Shadows are a bit better again in 0.8.23

 

[Mr Whippy]

Ruud, about that shader for planes in the distance to approximate mountains and so on. Is there any chance it can be tweaked so that it has an up-normal.
I've started using a few and a vertical approximation would be more ideal for lighting blending with surrounding elements I think, otherwise sun location impacts the apparent colour/intensity relative to the surrounding true 3d elements too much.

Just a thought

Dave

 

[Ruud]

What I'd really like to see (besides enhanced physics) is support for variable road profiles. Forgive me if my assumption is off, but with the current system of splining the road surface, it is as though it is perfectly planar from shoulder to shoulder (or curb to curb if you prefer). That is hardly the case on highspeed racetracks, let alone public roads made for optimal drainage. Of course, if the physics engine isn't built to handle this kind of stuff, then it's probably not worth thinking about it...

There has been a spline 'elevation' attribute for a long time. This applied a x^2 type curve over the surface:

rfloat dy,u2;
u2=2.0f*(u-0.5f);
dy=u2*u2*line->elevation;

Here, 'u' is the lateral position on the track, normalized (0..1). So u2=-1..1. Then 'dy' is a delta, subtracted from the surface Y. The real problem is that this way, 3D geometry doesn't match the actual surface so you get graphical Z-fighting as the wheels stride off the actual geometry and use the modified spline position.

 

[Ruud]

Erm, Cosmo spotted an issue in the latest version, we did some testing and I'm pretty certain he is right.

grip_decline_driveline feature seems to be active and messing all surfaces up.

Great find. The default was indeed 1, giving severe grip loss outside of the AI line. I don't have a good system thought out yet to determine how to reduce the grip - by absolute distance or relative (easier).

 

[Ruud]

Alllssooo, while I am here.

There used to be a few good scripts in the old Racer releases.

glong glat, one to watch the vertical wheel position to see the road bumps you were setting up etc. Where have they gone? They were massively useful to have there. Any reason for the removal.

Leading on to the issue that, last time I could check, road_noise_threshold didn't work, not truncating the road noise to this value (ie, not flatting off the peaks of the noise trace from the wheel sensing the bumps)


Leading on to one final thing, load_filter_frequency

Is this implemented yet? In my view we would be better using a logic system based on a variable we input into the car.ini
Tyre pressure vs tyre width (already in) vs tyre rolling circumferance (already in), gives us the contact patch size, then use that as a guide to what bumps might be felt...
Filtering frequency is an issue because big bumps that you would feel at all speeds, might be filtered out with a frequency based system.


Hmmmmmmm

The scripts: were they not just 'graph step -1 1 gforce_lon' (in data/scripts/oncar.rex are a lot of commented lines as an example)?

I checked road_noise_threshold recently (a week ago or so) and it worked fine. The thresholds work per frequency though, perhaps that's the problem?

The load_filter_frequency indeed works and was an attempt to filter out using a Simulink based example. With the default 0 frequency, it does nothing. But I noted that if I put it at 50Hz, you just get a 50Hz output value. Looking at road penetration it didn't help, but made it worse actually. It's more a numerical than a physical thing - really you should decrease road noise probably to what the wheel feels. Racer's definition of a contact patch as a single point does not work ok for noise coming through the tire rubber.

For shaky cars (Formula cars are quite stiff) we use tire_damping of ~500 at speed, and at low speed increase it to 2500 (using tire_damping_lowspeed and tire_damping_threshold).

A logic system would need papers or such to define something that was verified and used in real life. Better to tweak a bit with filters & dampers to make things stabler. Unfortunately at some point the way you numerically integrate a car has an effect on its driving characteristics.

 

[Ruud]

Ruud, about that shader for planes in the distance to approximate mountains and so on. Is there any chance it can be tweaked so that it has an up-normal.
I've started using a few and a vertical approximation would be more ideal for lighting blending with surrounding elements I think, otherwise sun location impacts the apparent colour/intensity relative to the surrounding true 3d elements too much.

It seems the panorama shaders don't even use the normal! It's just like a sky object, only blended based on distance, not on direction. Hm.

 

[Mr Whippy]

Hmmm, maybe that is ideal then...

What do you think

A steep mountain might have a significant angle towards horizontal, while a flat rising terrain won't... so is it best to average to no normal!? Hmmm...

If that is in 0.8.23 I'll do some tests, polygons forming the object at a few TOD's, then a plane again at various TOD's, and see which method approximates the mesh terrain most closely. I assumed an up normal would be best... hmmm, not sure now.

Dave

 

[Mr Whippy]

The scripts: were they not just 'graph step -1 1 gforce_lon' (in data/scripts/oncar.rex are a lot of commented lines as an example)?

I checked road_noise_threshold recently (a week ago or so) and it worked fine. The thresholds work per frequency though, perhaps that's the problem?

The load_filter_frequency indeed works and was an attempt to filter out using a Simulink based example. With the default 0 frequency, it does nothing. But I noted that if I put it at 50Hz, you just get a 50Hz output value. Looking at road penetration it didn't help, but made it worse actually. It's more a numerical than a physical thing - really you should decrease road noise probably to what the wheel feels. Racer's definition of a contact patch as a single point does not work ok for noise coming through the tire rubber.

For shaky cars (Formula cars are quite stiff) we use tire_damping of ~500 at speed, and at low speed increase it to 2500 (using tire_damping_lowspeed and tire_damping_threshold).

A logic system would need papers or such to define something that was verified and used in real life. Better to tweak a bit with filters & dampers to make things stabler. Unfortunately at some point the way you numerically integrate a car has an effect on its driving characteristics.

Oh ok, I just remember doing:

"run latg" or some such in the console and the appropriate little graph coming up in the top left of the screen. They don't seem to work any more, I'll have a look in the scripts again.

Road noise threshold, I'll check again. I'm using two noises for my road surface, so perhaps that is it... I'll check one noise and threshold for it and see, may have been fixed but hard to check without the above little graph showing wheel y position.

I'll ignore the frequency thing for now.


As for the tyre damping, what speed is it we define? rad/s or m/s of car etc? The units were not defined and it'd be useful to know them for testing and finding ideal values.


One super duper last thing that I think would be handy to be looked at, the sounds system pitch_scale doesn't seem to work. No matter what you do, doubling the input variable doubles the play rate it seems (ie, wind noises always double frequency with double velocity, even with the scale set at 0.1 for example)

Thanks

Dave

 

[boomer541]

Noted that car instruments such as tach on left side of screen is partially transparent. It wasn't in ver 0.0821! the lambo tach and speedo were partially transparent in 0.0821 but are almost completely faded out in 0.0822!

Using t key for speed limiter is easy to set up in the controls.default.ini, simple. There were a couple of other duplicate key functions, I can't remember which now. w key is used twice.

Will be looking forward to ver 0.0823 and hope the mirror flicker problem is gone. Thanks Ruud for all you have done with Racer!

 

[Ruud]

Oh ok, I just remember doing:

"run latg" or some such in the console and the appropriate little graph coming up in the top left of the screen. They don't seem to work any more, I'll have a look in the scripts again.

Road noise threshold, I'll check again. I'm using two noises for my road surface, so perhaps that is it... I'll check one noise and threshold for it and see, may have been fixed but hard to check without the above little graph showing wheel y position.

I'll ignore the frequency thing for now.


As for the tyre damping, what speed is it we define? rad/s or m/s of car etc? The units were not defined and it'd be useful to know them for testing and finding ideal values.


One super duper last thing that I think would be handy to be looked at, the sounds system pitch_scale doesn't seem to work. No matter what you do, doubling the input variable doubles the play rate it seems (ie, wind noises always double frequency with double velocity, even with the scale set at 0.1 for example)

Thanks

Dave

latg.rex probably just contained 'graph step -10 10 gforce_lat'. The oncar.rex file in data/scripts contains a bunch of commented out examples I used in the past.

For the road noise, use 'graph -0.02 0.02 wheel0.road_noise' to see road noise directly, without attempting more complex things such as tire penetration.

On tire damping, I've updated http://www.racer.nl/reference/wheels.htm#tireforces ; it's rad/s (spin velocity).

I'll have a look at the wind's pitch scaling...

 

[Ruud]

Noted that car instruments such as tach on left side of screen is partially transparent. It wasn't in ver 0.0821! the lambo tach and speedo were partially transparent in 0.0821 but are almost completely faded out in 0.0822!

Using t key for speed limiter is easy to set up in the controls.default.ini, simple. There were a couple of other duplicate key functions, I can't remember which now.

Will be looking forward to ver 0.0823 and hope the mirror flicker problem is gone. Thanks Ruud for all you have done with Racer!

I've noticed the blur_alpha setting under motion_blur can do this. Reset it to 0 and it probably is better. I want to have a look why that's not working. Notice that 0822 already had a bloom_shadows_blur_f.cg for fs_filter1 (use velocity_map=1 to enable rendering of the required velocity per pixel). There's some aliasing going on though, hm. Anyway, that should be much better than the blurred motion blur, which is a bit yucky.

The mirror problem is gone in 0823.

 

[Ruud]

One super duper last thing that I think would be handy to be looked at, the sounds system pitch_scale doesn't seem to work. No matter what you do, doubling the input variable doubles the play rate it seems (ie, wind noises always double frequency with double velocity, even with the scale set at 0.1 for example)

Couldn't find anything wrong with that; it sure made a difference. I use this in the Lambo now:

wind
  {
    volume=15
    pitch_scale=3
    pitch_offset=0
    smp0
    {
      sample=wind1.wav
      min=25
      max=26
      attack=33
      decay=33
      natural=80
    }
    smp1
    {
      sample=wind2.wav
      min=50
      max=51
      attack=33
      decay=33
      natural=80
    }
    smp2
    {
      sample=wind3.wav
      min=75
      max=76
      attack=33
      decay=33
      natural=80
    }
  }

Note that I modified pitch_scale a bit and set the offset to 0. I get a definite pitch increase when I use pitch_scale=5 or 10 for example.

 

[Mr Whippy]

So if pitch_scale is set to 0, will the sound always just play at the natural rate, no matter how fast you drive?

And if it is set to 2, will the pitch quadruple for every doubling in the speed you drive?


Also, I see the volume is really huge there, for ALL samples. The wind noise is rather exponential due to it being related to drag (squared with speed)...
What does using volume 15 achieve relative to the other sounds volumes? Surely it just clips? I'm confused here... hence my wondering about HDR sounds eventually.

I didn't seem to get more volume after about volume=3

Dave

 

[Ruud]

So if pitch_scale is set to 0, will the sound always just play at the natural rate, no matter how fast you drive?

And if it is set to 2, will the pitch quadruple for every doubling in the speed you drive?

Also, I see the volume is really huge there, for ALL samples. The wind noise is rather exponential due to it being related to drag (squared with speed)...
What does using volume 15 achieve relative to the other sounds volumes? Surely it just clips? I'm confused here... hence my wondering about HDR sounds eventually.

I didn't seem to get more volume after about volume=3

Dave

Indeed, volume here seems to get clipped. Normally, around 1 would be ok and the rest set to <=1.0 to downmix. Hm.
For pitch, this is in right now:

pitch=(pitchInput*pitchScale+pitchOffset);

where 'pitchInput' is specific for the type of audio. For wind, the input is car velocity (m/s). After that, the sample frequency is calculated:

sampleFreq=audioFrequency*pitch/naturalValue

where audioFrequency is probably 44100 for most people, 'pitch' is the calculation from above, and 'naturalValue' is the value you enter in car.ini for a sample (for the wind, natural=80 means the sample was supposedly recorded at 80 m/s).

So a pitchScale=0 and pitchOffset really bring down the value to freq=0, so no sound really (it gets clamped at 1000Hz though). To fix this in 0822 you'd need to set pitchOffset to 80 again (the natural value). This doesn't feel too intuitive.
For pitchScale=0 you'd want the frequency to never change. But for pitchOffset=0 you probably want it at naturalValue, not 0. Hm. So the pitch calculation would become:

pitch=(pitchInput*pitchScale+pitchOffset+naturalValue);

where 'pitchOffset' is really an offset to the sample's natural value. However, if you have multiple samples with different natural values, this may get hairy, and you might want to specify pitchOffset per sample. However, that sounds to become too complex. How about we just keep the 1 pitchOffset, and default it to 0, in which case (if scale=offset=0) you just get the natural sample frequency (as if you'd run it with mediaplayer).

Or if you have a cunning better idea?

*EDIT* Strike that '+naturalValue' part; it doesn't work for engine rpm, and isn't logical for wind either now that I think of it. So, add pitchOffset=<avgNaturalValue> to your sample definitions. This pitch is related to each sample's naturalValue (pitch>naturalValue: sounds will sound higher, pitch<naturalValue: sounds will sound lower).

From the updated docs on http://www.racer.nl/tutorial/car_sounds.htm :

pitch_scale; adjusting the pitch of the samples; default is 1.

pitch_offset; as with volume, this is a pitch offset. Defaults to 0. The pitch is calculated as this: pitch=pitch_scale*pitch_input+pitch_offset. Pitch can be used for wind for example, very slightly rising in frequency as the speed goes up. The 'natural pitch' is derived from the smp<x> 'natural' value. For engine sounds, for example, the 'pitch_input' will be the engine rpm; the natural rpm is used in setting the frequency of the sample playback.
An example: you have a wind sample that was recorded at a wind speed of 50 m/s. Say you only have 1 sample, so that's the wind's smp0 section. Just set the min/max for that sample to 0 and 9999 respectively, meaning the sample is valid for windspeeds (which are nearly the same as car speeds) 0 m/s upto 9999 m/s (so everything in practice).
The natural frequency of the sample (the frequency if you would play the wavefile with Mediaplayer for example) is reached when the velocity is 50 m/s, so set 'natural' to 50. To vary pitch slightly with speed, you can set pitch_scale to 0.01 and pitch_offset to 50. Meaning you will keep close to the original sample's frequency, but it rises slightly with car speed. In this case, when the car is doing 50 m/s, the sample's pitch will be pitch_scale*carVel+pitch_offset = 0.01*50+50 = 50.50. So the wind sample will sound slightly higher than the original.
A bit more complex, if the car is going 40 m/s, the pitch will be 0.01*40+50 = 50.40. So the wind will still sound slightly higher than the original sample, but less so than if the car was going 50 m/s. 

For the engine sounds, say you have a sample at 44,100 Hz that represents an RPM of 2500 (the natural value) and the current engine RPM is 4500. The 2nd step (after calculating pitch=..., see above) is to relate the sample frequency (not the natural frequency) to the current pitch: playbackFrequency=(sampleFrequency/naturalValue)*pitch. For example: playbackFrequency = (44100/2500)*4500 = 79380. So in this case the sample is sped up (higher pitch than the original sample).

 

[Alex Forbin]

I've noticed the blur_alpha setting under motion_blur can do this. Reset it to 0 and it probably is better. I want to have a look why that's not working. Notice that 0822 already had a bloom_shadows_blur_f.cg for fs_filter1 (use velocity_map=1 to enable rendering of the required velocity per pixel). There's some aliasing going on though, hm. Anyway, that should be much better than the blurred motion blur, which is a bit yucky.

The mirror problem is gone in 0823.

Bug: Exhaust backfire will only pick up the first defined exhaust position.

Bug: Sliding upside down still applies weird forces to the car that causes it to slide erratically (sometimes in a very obvious arc). While this may seem trivial I can't help but think that it is applying these odd forces ALL the time, and that it just shows up when you are on your lid.
The forces are applied normal to the roof of the, car so as it yaws (especially if the roof is pitched any.) the cars path will wander around as it slides, always being pushed toward the roofs normal. Negative forces are being applied to the body of the car.

I hope this clarifies the problem enough that I can get some sort of response.

Do any particles work other than backfire and tiresmoke? I've tried to get the exhaust to work without any luck.. or help.

Alex Forbin