Racer v0.8.24 released!

Ruud

RACER Developer
v0.8.24 is out.
Expected problems:
- Carlswood's kerbs seem to have a problem with bumpmapping. They're using static bumpmapping which haven't changed yet (to world space). Might be the tangent creation, hm.

Get it at: http://www.racer.nl/download/racer0.8.24.zip

Changes:
- dyn_standard_bump_reflect_*.cg rewritten to work in world space. Faster & reflection
is now also affected by the normal map (quite noticable).
- Same for dyn_standard_bump_*.cg; it now also takes the bumpmap's alpha for reflectiveness (specular).
- dyn_standard_bump_speca_v/f_cg was removed; use dyn_standard_bump_reflect*.cg instead (which does
the same thing).
- Controller stick_friction threshold velocity decreased from 20 m/s to 5 m/s (hardcoded).
- Added 'u' to position logging (normalized lateral position on the track)
- Added projected lights intensity: car.ini's lights.light<n>.color (default=4 4 4). In klux. Check
the Lambo's car.ini.
- async now runs the physics thread full throttle; it must run on a separate core if you want to avoid
it impact the other threads.
- TrackEd reworked to use the full render engine. Flashing also works again. Stack overflow fixed.
- Wheel setup screen now includes friction/stick friction/damping/inertia sliders.
- Added car.ini car.ff_friction, ff_stickfriction, ff_damping and ff_inertia factors to tune force feedback.
- Also added car.ini car.ff_gain, which modifies the ff_friction etc values directly (default=1.0)
- Added console commands 'ff friction <x>', 'ff stickfriction <x>', 'ff damping <x>' and 'ff inertia <x>'
for live setting of FF values. Absolute numbers for the controller, not car relative (0..10000).
- Fixed typo in NightSaturate() (no green in B&W color) in hdr.cg
- Tangents now generated in 4 coordinates (was 3). Mirrored UV seams are now being duplicated
to avoid tangent trouble where UV and mirrored UV parts meet.
- Modeler can now show tangents (T to toggle). It already did normals (N to toggle).
- Tangents were never used as VBO's; now they are (slightly faster).
 
I put my Surfaces and Sounds track in the download thread as it intermittantly makes the gravel or stones or mud area to go dark or very bright.

It appears to be a problem with vetex colors as it works very well in ver 0.0823 but has the problem in ver 0.0824.

Perhaps Ruud or Mitch or somebody else can figure out the ptoblem, thank you.
 
I've found one glaring issue with bumpmapping, these were Mugello's dyn_bumpmapped concrete walls in 083.
1st image is in 084, 2nd is in 083

Fixed in v0.8.25; only 3/4th of the tangents was passed, the rest was NaN.
Also note that in track.shd you forgot to use 'mode=linear' for bumpmap textures, and tangents=1 to get tangents even passed to the shader (otherwise nothing is passed, resulted in all tangents being NaN).
 
Any chance of a shader for tarmac etc...?

standard_bump_speca_*.cg

So rgb diffuse on tex0, and rgb normal and alpha specular on tex1?


Seems a fairly well needed shader type to have, for everything on tracks that is near the sides where you see it lots... and the tarmac/road surface itself of course.

Thanks

Dave
 
Just some feedback on the force feedback stuff.

All works pretty intuitively.

ff_gain nicely scales the ff_frictions,damping and inertia up and down.
ff_factor just scales the Mz/castor/kpi forces.
ff_damping doesn't seem to do anything here.
ff_frictions feel like they are harder the faster you turn the wheel, nice settings for dead ahead and general weight suddenly feel much firmer when you try steer quickly to correct a slide. Not sure if the friction is working nicely in that regard.

ff_inertia seems to work better as a friction, it's got nice weight dead ahead, but doesn't seem to ramp up the resistance if you need to steer much more quickly. I've used 3.5 here for the factor and it's fairly good.

ff_factor and ff_gain seem a bit alike, but for compatibility sake ff_factor only does Mz/caster/kpi indeed.
ff_damping was applied wrongly in v0824; it was multiplied with the original friction factor. It should now work (at damping in itself works fine on my G27).

Friction: that's really a wheel-related issue. It seems as the motor starts pushing your hand, the effects get a lot clearer. Around the zero position, the G27 seems to cut forces to remain stable. I just pass a friction amount to the wheel; if that feels weird, it's either a deadband in the driver or something on the wheel side.

Inertia is acceleration relative (as damping=velocity, friction=position), so with constant velocity, you don't really feel inertia, except when speeding up your rotational movement (acceleration). That's why inertia may be nicest to tweak. Frankly I don't really understand the damping principle in real steering wheels (it seems mostly friction).
 
Actually, it does finalColor=min(finalColor,255) (dyn_standard_bump_f.cg:115).

It seems the calculation of normal N goes awry at some places:
(notice the black triangles)



This is out0.rgb=N;

EDIT: It seems the tangent is indeed broken. This is 'out0.rgb=tangent.rgb':

It may be that the normal gets mangled since only 3/4th of the tangents are passed in 0824 (fixed in 0825):

float3 bumpNormal=N+(bumpColor.x*tangent+bumpColor.y*binormal);
N=normalize(bumpNormal);

Here, if tangent=NaN then your normal becomes NaN too. If you skip the 2nd line, the normals may look fine again, just unperturbed.
 
The variables just go under the car.ini, car tree.

car
{
ff_factor=0.7
ff_friction=1
ff_stickfriction=0.5
ff_damping=0
ff_inertia=2.5
ff_gain=1
}


For example... so alongside the existing ff_factor

The G25/27 is default as Racer defines it... right from the G27 base file iirc.

I'm still not entirely happy that friction is working exactly as you would want it. Not sure how/why etc. It's good having it there, way better than none at all... just need to tweak it and play with it more :D

Ruud, what kind of info is sent to the wheel to do friction etc, from Racer? Just basic requests for the inertia, friction and damping amounts?

Would be interesting if we could scale back the friction when Mz grows... that way we can get the weight around dead ahead, but lose some when we want to feel the Mz etc. Sounds like a fudge of mighty proportions, but we are dealing with relatively cheap FF wheels here :D

Could you mail me your G25 settings? If you get that working as a preset that is; I need the device name for Racer to be able to auto-detect it (it just loads data/controls/presets/<devicename>.ini at autodetect).

For friction/inertia/damping, I just send 1 number (0..10000) to the wheel, and it handles all the details. Not much too tweak in that department (I think there's not even a deadband in the driver screen).

The friction dependency on Mz sounds like a real fudge which may make things worse if you're not on your exact software. It should be tweaked per setup to add, instead of subtract, to the experience. :)
 
Could you tell us how you've set the variables in car.ini + in your custom default_G25/G27.ini file ? Was wondering why Ruud didn't integrate those in the lambo car...

Anyway, first tests with the GUI settings seems to be quite handy...Console commands too !

Sorry about that, in v0825 they are. They're also in default/car.ini already in your 0824 installation.
 
I got some muti-colored flickering planes all over the place & a crash. If I wireframe the Modeler view before & then N or T press, no crash, but still weird planes rendered.

Code:
OS-Version: 5.1.2600 (Service Pack 3) 0x100-0x1

0x6925A43F [atioglxx]: (filename not available): atiPPHSN
0x6925B8C9 [atioglxx]: (filename not available): atiPPHSN
0x6925CBDE [atioglxx]: (filename not available): atiPPHSN
0xA0FF0000 [(module-name not available)]: (filename not available): (function-name not available)
0x006D0061 [modeler]: (filename not available): (function-name not available)
Also, have the same crash as Alex when saving my wheel settings (inertia & damping) & then trying to return to the wheel settings...Same for auto-detection.

Hm, I'm using a custom default_G25.ini file which won't get updated with the new wheel settings, instead once saved, in racer.ini, I have => controls=default.ini with none of the saved values I've set.

Anyway, using the default.ini & editing the wheels settings ingame works correctly, no crash...

Indeed, you may want to leave controls=default.ini (it expects that more or less, the setup screen) and create a preset file instead. Get all things set, then copy the default.ini file to presets/<devicename>.ini, where <devicename> is the exact name you see in your game controllers screen (i.e. 'G25 Logitech Pro Bla Bla').
 
Shadow defaults imo are still really bad.
...Just driving on a test Mugello, and the over track cameras looking down just see a splodge to one side of the car, not a solid cohesive shadow... blurring off and increasing the split distances, and adding a 4th split makes it look better, more realistic, and gets about 10-15% more fps!

If you can mail me those 4-split settings you use, I can see if we can make those default instead.
 
Any chance of a shader for tarmac etc...?

standard_bump_speca_*.cg
So rgb diffuse on tex0, and rgb normal and alpha specular on tex1?

Sounds like standard_bump_*.cg as it is right now, only with an added 'reflectiveness' (really 'specularity') in bumpMap.a. I've added that to v0.8.25, so it stays the same shaders, but bumpMap.a now controls specularity (before it was ignored).
 
Since the interior shader for dials was added, they are being displayed wrong. They are too big and in the wrong position.
0.8.16 vs 0.8.24.
dials.jpg
 
Sounds like standard_bump_*.cg as it is right now, only with an added 'reflectiveness' (really 'specularity') in bumpMap.a. I've added that to v0.8.25, so it stays the same shaders, but bumpMap.a now controls specularity (before it was ignored).

I'd done that here DIY (specularity * baseCol.a), just as a quick fudge, but yep, better to have it in with the other linear data of the normal map :D

Thanks!


Does look so very very nice having all those speculars working with the bumps.

Just wondering, from a point of experimentation, if I use an alpha map in the tex0 (diffuse map) and use alpha to coverage, will it work for transparrency with that shader? (just thinking for trimming off the rough tops of the dry stone wall shader)

skye-dry-stone-wall-large-1.jpg


Dave
 
I'd done that here DIY (specularity * baseCol.a), just as a quick fudge, but yep, better to have it in with the other linear data of the normal map :D

Thanks!


Does look so very very nice having all those speculars working with the bumps.

Just wondering, from a point of experimentation, if I use an alpha map in the tex0 (diffuse map) and use alpha to coverage, will it work for transparrency with that shader? (just thinking for trimming off the rough tops of the dry stone wall shader)

Dave

Yes, that should work with the stone wall.
Note that the SRGB vs linear modes don't affect alpha, so whether the specularmap would be in diffuse.a or normalmap.a, it wouldn't matter since both alphas are handled as linear (even if they're uploaded to the graphics card as mode=srgb).
 
It's really strange. My car and Tib's Jag have problems with dials, but the SL65 has no problems. I'll have to check with my other cars.

They all have it; in viewelt_v.cg, remove this line:

OUT.Position.y+=0.01f; // reduce z-fighting

What a 'y' would help for 'z' fighting, hmmm. Fixed then for v0825.
 
Curious to see how the steering effects work out in v0.8.25 then, right now I also get the impression that friction and inertia appear to act as if they were mixed up. That is, with only inertia running there's a nice constant resistance, whereas friction is almost non-existant during slow inputs and dramatically ramps up the faster you try to accelerate the wheel.
Not sure about the damping aspects in real life either, but maybe it can be useful to iron out some of the force reversal effects we get around the centre position (?).



In regular v0.8.24 the show carpoints/carbbox/aero commands don't work anymore? They do in the nocg.exe version, though.

On the other hand, nocg.exe doesn't support the ff friction/... console commands, but seems to take the controller file values nonetheless.
 
Thanks Ruud. But there is still an issue with digital elements. See it for yourself.
dials.jpg


And while we are at it, the dials look a lot better when I comment out the line
OUT.normal=IN.normal; //mul((float3x3)modelMatrix, IN.normal);
dials1.jpg
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 373 16.1%
  • < 2 years

    Votes: 256 11.0%
  • < 3 years

    Votes: 247 10.7%
  • < 4 years

    Votes: 181 7.8%
  • < 5 years

    Votes: 304 13.1%
  • < 10 years

    Votes: 260 11.2%
  • < 15 years

    Votes: 166 7.2%
  • < 20 years

    Votes: 129 5.6%
  • < 25 years

    Votes: 100 4.3%
  • Ok, I am a dinosaur

    Votes: 301 13.0%
Back
Top