Racer v0.9.0 RC5 released

[Ruud]

Get it at http://www.mediafire.com/file/zdn8i0kntl3h579/racer0.9.0_rc5b.7z
[URL edited at 16-11-2012, 17:07 for some bugfixes]
Get a racer.exe/pdb bugfix at from http://www.mediafire.com/file/ny6a8gju5oaracb/racer090rc5c_exe.7z (which fixes that braking with locked wheels would give extra force instead of less).

A note about the audio: a bit more is planned to add to audio. Mainly an extra 'noise' sounds for each surface when going off the AI line. Then there's also an idea to use understeer & oversteer values to select samples, instead of taking skid values per wheel, since understeer sounds different from oversteer. Experimental a bit though.

Enjoy!
Ruud

Changelist:
- Ctrl-I now inverts debug readout colors (it used to roll through the debug readout views)
- Onyx compiler improved with bugfixes, type-casting.
- Onyx pointers (hm).
- Onyx now supports float const ('const float x=0.5'), while, for and do-while.
- Onyx supports basic yielding of scripts (coroutines, triggered each frame).
- Onyx internal function abs(), sqrt() added.
- A default Cg shader is created for materials without an explicit shader. To avoid black materials.
- car.ini's now accept wheel<n>.pacejka.negate_camber. Some TIR files/coefficents out there
seem to reverse camber (inverting influence on Fy tire forces). This option inverts camber sign
as it goes into the Pacejka formulae.
- lighting.cg no longer adds Ks (specular) to the ambient term.
- .f32 file support for textures in .shd files; future development for sky colors.
- Added $water_reflection texture map for shaders, in the same way $mirror exists. This works with renderer.water.*
to render a mirror image of the scene into a 2D reflection map, which can be used for a water shader.
See also water_f.cg/water_v.cg in data/renderer/shaders.
To be elaborated.
- The default debug text color is now white again.
- Timing is passed to the Cg shaders in TrackEd for some animations.
- Explicit low LOD steering model removed; use the model LOD available for the regular model (steer.model) (in car.ini)
- Car cameras can explictly turn the steering wheel on or off (camera<n>.steering_wheel=0 or 1). The default is 1 (added to data/cars/default/car.ini).
See also http://www.racer.nl/reference/carphys.htm#campos
- Number of materials in a track raised to 6000 (from 4000) for some nasty import tracks.
- TrackEd's generate template shader generated '<unnamed_QObject>' for unloaded textures.
- Added engine.shifting.cut_ignition in car.ini; instead of cut_throttle=1, you can leave throttle open and cut
part of the ignition instead. A value of 0.5 for example will output 50% of engine torque to the clutch/gearbox/wheels,
so is smoother while shifting.
- Autoclutch during shifting linearized; it was now squared, making for a less smooth experience.
- New combined slip method for tire forces; #7. From Pacejka's book, the Similarity method. Does not require
optimal_slipratio and optimal_slipangle anymore. More info on http://www.racer.nl/reference/wheels.htm#tireforces
- When the tire left the surface, slip angle and ratio were reset to 0. This was not realistic for a bumpy surface,
since you lose a lot of traction when the tire is bouncing a bit. Now it keeps on tracking slipAngle/Ratio.
- Different fonts (Eurostile)
- Added dyn_standard_bump_ao_f/v.cg shaders for ambient occlusion map (much like the mix shaders really).
- After all these years, on Win7/64bits with 32-bits Racer, got PerfKit working with PerfKit v2.2.0.12166 from nVidia ('debug 6 1').
- Added 'float serverTime' uniform for Cg shaders to get (an estimate of) the multiplayer server time. To sync vertex shader effects across multiple PC's.
- Added active differentials basics using Onyx. See http://www.racer.nl/tutorial/differentials_active.htm
- Added a global 'lowpass' DSP option. Mainly used for testing for a future 'muffle' parameter per car to soften incar sounds.
- Added track audio per surface (in special.ini). If not defined, the default global surface type audio is used.
See http://www.racer.nl/reference/tracks_surfaces.htm

------------------------------------------------------------------

Bugs (currently known specific to RC5)

• Gearbox shift times not working properly, step from 0 > 1 clutch position over the time rather than smooth linear transition.
• Water reflection not rendering, needs clarification on functionality.
• Qlog discrepancies (I'll let Boomer clarify those.
• Odd console readouts about tyre slip angles or something popping up (same goes for gearbox manual/auto setting, doesn't need to be console displayed imo)
• PerfSDK not working as advertised, broken?
• Multiplayer joining to IP's seems glitched, the person joining has their brake stuck on and are unable to shift
• The Multiplayer Lobby does not let you connect, and subsequently let you host, despite the right ports being forwarded. (Anyone else experiencing this bug?)
• The particles pop-out of existence at the end of their specified lifetime instead of fading away smoothly. It would be nice to have some better control over the fade-in and out over the lifetime of the particle since tiresmoke starts out thick and opaque then disperses and becomes more transparent over time, while gravel or dirt fades in a bit at first then eventually fades away.
• Smoke flickers in the reflections, as though it's missing every other frame.
• Replay bugs: No smoke effects, ghost car is left on track.
• The starter sound plays all the way to the end of the sample instead of stopping when you let off the starter.
• Ghost doesn't work on endless tracks.
• track special.ini: timeline.point_to_point=1, timeline.auto_return=0 - The auto_return setting doesn't seem to work here. I have a point to point track and the car resets 3000ms (3s) after crossing the finishing line, but I don't want it to.
• No reflection in the Racer garage when selecting a car.
• The unsprung weight apparently applies a downforce, try making a 150kg rear axle with the front
  suspension lighter and the car will act as though it has high downforce when jumping off of a ramp.
• If the wipers are set to rotate in opposite directions then the intermittent position does not rotate back and forth smoothly. It snaps back.
• In RC5c at least, the camera bug is still evident, and on Carlswood (spline based cameras) you can often get stuck so you can't get back to the in-car camera view which is really annoying! - Courtesy of Dave

 

[KS95]

Current list of bugs are:

• Gearbox shift times not working properly, step from 0 > 1 clutch position over the time rather than smooth linear transition.
• Water reflection not rendering, needs clarification on functionality.
• Qlog discrepancies (I'll let Boomer clarify those.
• Odd console readouts about tyre slip angles or something popping up (same goes for gearbox manual/auto setting, doesn't need to be console displayed imo)
• PerfSDK not working as advertised, broken?
• Multiplayer joining to IP's seems glitched, the person joining has their brake stuck on and are unable to shift
• The Multiplayer Lobby does not let you connect, and subsequently let you host, despite the right ports being forwarded. (Anyone else experiencing this bug?)
• The particles pop-out of existence at the end of their specified lifetime instead of fading away smoothly. It would be nice to have some better control over the fade-in and out over the lifetime of the particle since tiresmoke starts out thick and opaque then disperses and becomes more transparent over time, while gravel or dirt fades in a bit at first then eventually fades away.
• Smoke flickers in the reflections, as though it's missing every other frame.
• Replay bugs: No smoke effects, ghost car is left on track.
• The starter sound plays all the way to the end of the sample instead of stopping when you let off the starter.
• Ghost doesn't work on endless tracks.
• track special.ini: timeline.point_to_point=1, timeline.auto_return=0 - The auto_return setting doesn't seem to work here. I have a point to point track and the car resets 3000ms (3s) after crossing the finishing line, but I don't want it to.

 

[Cosmo°]

I'm curious Dave: why would you want to have different parameters for AI shifting behavior? Perhaps you're thinking about potential performance loss due to the AI running more complex shifting scripts? Outside of this, shifting behavior is a property of the vehicle itself in my understanding, so it would apply to human drivers as well as the AI in the same way.

On a related note, if autoclutch is used, manual override should be deactivated.



To the general bug list:

- Qlog discrepancies; a couple of elements are always listed for vehicles despite those car.ini files following the state of the art content and structure. An example is the listing of car header content (car.year, credits, comments) as "unused". Another such case is the "missing" audio.skid.sample when using the current audio.skid.smp0/1/... syntax. One of the examples boomer brought up before is with cameras, when using the headphysics type, it seems to expect an entry for offset_to to give a non-zero distance to the regular offset entry, but this is of course unnecessary for the given camera syntax.

- odd console readouts; you can disable them yourself via uncommenting of the respective lines in data/scripts/oncar.rex (it's the last paragraph of the section titled "combined slip..." near the top of the file), but yes, it would be better for the default case to have it off as few users want this information onscreen (as important as it is for us to stay on the ball here - combined slip mixing is a big questionmark at the moment and it has a huge influence on handling, but zero documentation).

- MP clients getting stuck in place; definitely a bug, has been around for ages. The known cure for us users is for the host to Shift-R reset the race to "free" the client drivers.

- MP lobby; yes, I have never been able to host an event via this, yet usually can host/join over direct IP despite being behind a stubborn router

- replay bugs; another issue with replays is that when you save a replay file with a custom file name, it creates a copy of the .avi file with the default name as well (so, uses up twice the disc space). Camera controls are also depending on the replay speed and direction, ie if I hold Numpad4 and the camera moves clockwise at regular speed in normal play mode, it will rotate counterclockwise and at reduced speed when rewinding in slow motion (or faster when fast forwarding). Skidmark state at the beginning of a replay is as it was in live-play before the replay was started, skidmarks then disappear just before the vehicle "recreates" them.



A few more minor things:

- carpoints; when using "show carpoints" to visualize certain elements, the aero rectangles don't show the angle of attack, they're always horizontal.

- brake heat shader; applies for all wheels at once, not for each individual wheel (hottest brake temperature is displayed).

- model.offset; when using a different offset value on different instances of the same model, ie brake caliper .dof file is identical for front and rear wheels, only the first instance gets the correct offset applied, the following ones use the first's.



The elephant in the room right now:

- differentials and related force reversals; it's currently a real issue to do any sensible development work on vehicle handling with the unwanted behaviors around. Constantly getting stuck when trying to reverse on slippery surfaces, very pronounced, spring-like unloading behavior of differentials, etc. Add to this the uncertainties of having combined slip mixing going on of which we have no clue about the way it's supposed to work (so we can check), makes for a big guesswork, very dark ages in my opinion. Example clips, showing the odd acceleration behavior when spinning, as well as the reverse lockup bug (Baja model is RWD, other info related to the experiments in the description boxes):

 

[Stereo]

- model.offset; when using a different offset value on different instances of the same model, ie brake caliper .dof file is identical for front and rear wheels, only the first instance gets the correct offset applied, the following ones use the first's.

This one is documented, here for more info.

 

[Alex Forbin]

That doesn't strictly seem to be the case here. With manual clutch and manual h-pattern shifting, Racer recognizes the correct gear selection on startup, be it reverse, neutral or a forward gear. With autoclutch and manual shifting, this is still the case. With manual clutch and automatic shifting, the vehicle is loaded in neutral, regardless of shifter position (in my case, paddle shifters automatically take over when automatic is selected anyway, since I defined them for sequential shifting in my controller file). Finally, when both autoclutch and automatic shifting are selected, the vehicle always spawns in first gear (and, annoyingly, we have to press the clutch pedal to start the engine because autoclutch doesn't assist us enough).

You're right, the problem was I had both sequential AND h-pattern set-up in the controller.ini
Thanks

Alex Forbin

 

[Mr Whippy]

I'm curious Dave: why would you want to have different parameters for AI shifting behavior? Perhaps you're thinking about potential performance loss due to the AI running more complex shifting scripts? Outside of this, shifting behavior is a property of the vehicle itself in my understanding, so it would apply to human drivers as well as the AI in the same way.

Because the AI needs shifting that works basically, wheras I don't.

Ie, paddle shift is great on the Lambo but I don't like it changing up for me at 7600rpm where it's best for the AI, or down-shifting at 3500rpm so the AI doesn't get stuck in short gears.

I want to have it not shift up or down except at extents (ie, beyond the rev limiter to stop me picking a wrong gear, and around idle to get me back to 1st gear if I spin out), but the AI won't ever change out of 1st with that strategy.


AI shifting logic limitation is a problem. AI emulated a human, and a human will pick gears based on more than just rpm if they have the choice.

And many cars have choices, ie, they are automatic with overlaid driver control if they want to change at a different time, won't change up in braking zones etc, and that is a blend of shifting behaviour we can't actually set in Racer cars because it's limited, or Racer AI can't interact with in any meaningful way.



Again, hard coding is Racers weakness. There is no reason why we can't just have shifting_ai. It is probably a line of code and opens up freedom to be creative around the limitations of other systems.

No real cost, lots to gain.


Dave

 

[Cosmo°]

OK, my view is that in a vehicle equipped with a manual transmission you would shift how and whenever you like, while the AI takes the standard engine.shifting parameters. If you run an automatic transmission, you're either using shift curves or a dedicated script, which should apply for both human and AI drivers.
That leaves semi-automatics that don't upshift by themselves near the limiter and variations thereof, as in your example. For this case we currently "misuse" the engine.shifting parameters to prevent automatic upshifts while still calling for downshifts near idle speed.

Going through a couple of options in my head, it's not easy to come up with a solution that doesn't add extra lines to car.ini. As you know, I'm not against additional features and/or improvements of course, but it would be nice to avoid adding extra lines and parameters people have to keep track of if there is a more elegant way. I guess you would simply add two lines, ai.shift_up_rpm and ai.shift_down_rpm?

 

[Mr Whippy]

Since neither curves or scripts are really a solid feature for general users at this stage for automatics etc, but the hard-coded car.ini variables are reliable, then I'd tend to prefer to specify each gearbox type to be as near to what the real car might offer as possible, and also what is preferable from a users point of view.

I suppose just having another pair of parameters for shift_up_rpm_ai and shift_down would make the most sense.
If they are not set, then use the default shift up and down values.

Then you can define specific behaviours per gearbox type if you really want (ala Lambo where you choose the appropriate set)


This is just another case where opening the system up would be beneficial for content. Ie, why is racer.ini holding so many parameters that might be useful on a per-track basis if we want them to be (ie, defaults can be in racer.ini, but if they are present per track then use those instead!)

Ie, starting lights, run-on time after finishing point to point courses (broken right now too), reverse direction warnings etc.

Dave

 

[scania970]

Hello, I'm new to this game and I can't understand why I get this error:

 

[KS95]

Hello, I'm new to this game and I can't understand why I get this error:

Please have a read of either of this, if you don't find your answer ask in the first thread, thanks

http://www.racedepartment.com/forum/threads/problems-with-racer-post-here.55324/

http://www.racedepartment.com/forum/threads/wip-frequently-asked-questions.29064/

 

[skybh]

Discovered another bug.
When i pause the game while the skid sound being player, then resume the game, the sound stays playing :/ (even if i'm not drifting the skid sound stays)
another :
When i pause the game at place X and revs Y (with sound) and i do "reload car", when i go back to the place X i can hear the sound of the car at Y revs (hidden ghost car? )

 

[scania970]

Please have a read of either of this, if you don't find your answer ask in the first thread, thanks

Uh, ok, sorry I didn't see that, and I solved the problem

 

[KS95]

Uh, ok, sorry I didn't see that, and I solved the problem

No problem dude, just keeping this place tidy

 

[camsinny]

I modified the dyn_standard_reflect shaders to include vertex colours. I can't see a downside to having them passed with the standard shaders - so should be fine to fold in with the next release rather than adding another shader to the long list of already available ones.

### EDIT ###

Apparently I assumed incorrectly - DOF files return black VC's when none are present.

 

[Mr Whippy]

Hmmm, so that is vert colour multiplying against the basic ambient, or ambient + diffuse?

Or just vert colour normalised to 0...1 multiplied against ambient term (for AO faking?)

Also note there is a subtle face normal shading effect on ambient term on all shaders I think...

Dave

 

[camsinny]

Hmmm
I applied it the same as is in standard_vc_f - though this may not be best since it's applied after lighting calculations - therefore the specular term is also multiplied by vert colours.
For my current purpose it is of no consequence but for others that may not be ideal.

 

[skybh]

I've tested here, the part become all black (maybe i'm stupid)
But it would be nice to have some AO in racer

 

[William Geuze]

You can use a mix shader, or the new mix shader which includes a normal map

 

[Mr Whippy]

Vert data is useful for baking in some AO, assuming you build in sufficient poly data to give a nice look... well, any vert data is the same I guess.

Model with it in mind and then use it. It can be cheaper than textures... especially in our case where we can't have a 2nd UV map set for light maps... vert baked stuff makes more sense.

If you are doing AO then the vert impact needs to multiply the ambient term, then you can also colour tint it too. Using 3DS Max and radiosity plugins you can bake some nice effects into verts and export that data.

Like I said though, you really need to build with this in mind from the start. Quite often you might build with non-ideal poly densities that just look bad when you try use vert shading data over the top (ie fans etc look horrible vs a nice quad high density mesh.


Imo with the onward march of AO in post, faster GPU's and more sophisticated programming/shading techniques, I'd generally not bother doing much with verts except using it where a shader can't do the job better... ie, blending materials, adding some colour variations and so on... these generally tend to save texture memory = win win vs a few extra verts.

For most stuff in Racer right now the most important thing is just good diffuse/spec/normal maps for most materials, they bring a lot of life to scenes. Ideally a diffuse/gloss/spec/normal shader with proper energy conservation and reflection/spec management would be best

God knows how you program that though hehe...


Dave

 

[Alexander Knoll]

I modified the dyn_standard_reflect shaders to include vertex colours. I can't see a downside to having them passed with the standard shaders - so should be fine to fold in with the next release rather than adding another shader to the long list of already available ones.

http://cameronsinfield.com/wordpress/wp-content/uploads/2013/01/shaders.zip

THX cam,
but a question, what did i wrong....if i use the mod files the car in car preview screen went from white to yellow...and in game to black...can you give me a hint please...THX

Alex

 

[camsinny]

I was using it to remove the need for another material (since I haven't baked out the car AO yet I figured I'd set the vert colours to black where I wanted black paint instead of orange.)

Alex: I'm not sure why it would mess up your car selection screen. All that's changed is a couple of the texture units passed between the shaders - nothing that should mess with that. The only possibility was that your vert colours either aren't baked properly (what program are you using and what exactly are you trying to do with the vert colours?) or the model is using all black vert colours. AFAIK the default for any program is to output white - or if there aren't any present it's assumed they're white. In which case there shouldn't be any noticeable difference between the shaders provided with RC5 and the modified ones.

I also modified a shader earlier that uses the vert colour channel to store a 2nd set to UVs. Was quite handy but it meant a few extra steps in the 3d program to transfer the 2nd UV data to vert colours.