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

 

[Stereo]

Expanded out the number of points, the reason it's an 8-pointed star is that the points I'm using are in a square that's been rotated 45 degrees.

What you'd really want to do is carefully choose the set of points it's sampling from to be the 'shape' of the blur (eg. uniformly across a circle for a round aperture, defined blades for an n-sided one)

With a blur kernel of 128 points I'm sure it's affecting framerate a little more but I haven't even turned off normal bloom yet (it's not in the FS shader; the maps are still being generated) so I'm not gonna say it's worse.


Next step is to dig into HDRToneMap to figure out at what brightness a given exposure 'clips'. I'm not entirely convinced that doing that is better than just dividing it by an appropriately selected fudge factor (to represent the proportion of light from one or the other source), will have to get the whole bit combining in-game and compare at different views to see what makes sense. As you can see, the wider it's blurring, the darker the scene can be and they still stand out. (http://i.imgur.com/eP1lguV.jpg - this is what it looks like at 60% brightness, above is around 6%)

 

[Mr Whippy]

Looking good so far Stereo!

I'm not sure I noticed a big bump in FPS turning off the bloom maps, but I'm sure they must cost something... this method can in theory cost a bit more than the old bloom because it does such a nice job (or will)

I love the way the blurring is working on the true HDR image here, as seen by the soft spots on the car body reflections of the lights themselves!


As per blurring clipping values vs blurring the whole scene... I suppose you are right...

In theory what you could do is just tone-map the blurred image with a factor on the exposure value... no doubt whatever that factor is it'd be basically pushing what were just clipping whites in the original scene exposed image back to near black...

That seems to then make sense... probably more elegant too.


You could easily check what you were 'adding' back to the frame buffer as 'bloom' by just setting the shader output to the image blurred and tone-mapped at a different exposure.


I think that is probably the most elegant method, and I bet that factor is probably going to be pretty much static because it'll be very closely related to the dynamic range the standard tone-mapper tends to cover.



I like the idea of having different blurring too. This is where we can have a nice elliptical type blur with the odd streak (for eyes/eyelashes to simulate the human eye aperture)... or have squares/hexagons etc for camera lenses...


PS, wouldn't a better test for the street lights be to drop the facing shader planes? In theory this shader needs to pick out 1 pixel points that have a very high intensity and then 'blow' them out to a big splodge with a medium high intensity. Ie, 1 pixel with 10,000 lux gets spread out to be 100 pixels with 100 lux per pixel... a bigger softer less intense spot rather than a tiny super bright one (which still exists in the middle of the splodge of course )

Dave

 

[Mr Whippy]

Just generally thinking...

The current bloom system just doesn't seem very good at detecting small areas of light.

The fact it's 256px across as the highest res means as soon as an element is under 7.5px across (on my 1920px wide screen), then it'll flicker or not register. I'm not even sure what the logic is for detection, and I know that the end result if it does register is LDR, not HDR!

In theory with your method Stereo, even a pixel that is half-sampled with the bright value and empty black space WILL get seen and blurred out... iirc, the multi-sampling is 4 as default, so even 1/4 of a pixel coverage will get 1/4 of the high Lux value through into the blurring process, and you will get your nice soft glare.

That suddenly means that the night time highway track for example, all those tiny points of light that almost disappear from view will STILL pass their HDR energy through to be blurred, even if they are sub-pixel in size...
The blurred and tone-mapped end result will then reasonably represent the glare energy to be added to the original pass.


As far as my thinking goes, that means you don't need to use the fudged 'glare' planes on the highway track so the bloom then picks them up... in theory your blurring pass should grab even sub-pixel bright elements and blur them


Excited to see if I'm right or wrong hehe... but I'm pretty sure I'm right.


Yay!

Dave

 

[Stereo]

It should help with that, but it's gonna either look grainy or start using up more GPU time - an 8x8 pixel kernel (not sure if photoshop would call this 4 or 8 px on the Gaussian blur) is about the size I'd be running and on a big screen that's not much.

The glare panes help with that by giving it a few more pixels to work with - if each light is 3x3 to start, then you can triple the size of the blur (to a 12 pixel radius) without going all grainy or taking more computation time.

(bloom seems to be required for the mirror FSB to work)
Basic benchmark of the bloom shader goes:
16 samples - 70% GPU @ 60fps
128 samples - 100% GPU @ 50fps
256 samples - 100% GPU @ 36fps
512 samples - 100% GPU @ 5fps
512 would be a 22x22 blur, so as you can see it doesn't scale out all that well.

There's some optimization to be had in my code in terms of making a Gaussian blur in particular look nice but there's only so much you can do this way. Blurring is not very multi-thread friendly, literature has fast single-thread algorithms which scale to any size of uniform blur, but that approach doesn't translate to GPU code.

A nice mipmap (actually averaging the pixels on each downsize, instead of just picking one) doesn't lose pixels, but if it's done in LDR the information's already gone. If I was gonna do it from scratch, I'd probably use the HDR 128x128 map, blurred using a 5x5 Gaussian shape. That would make it overall 40x40 in the output if I have the math right. That's about the size that seems decent when I try it on a screenshot. 5x5 is a little small for more complex shapes but I expect you could get an approximation of a 2 or 4 bladed aperture decent enough (like the pattern eyes see)


The graininess probably doesn't matter so much for non-screenshots, maybe another case of 'bump it up in screenshot mode'.

 

[boomer541]

Another Bug!! If the wipers are set to rotate in opposite directions then the intermittant position does not rotate back and forth smoothly. It snaps back.

 

[KS95]

Another Bug!! If the wipers are set to rotate in opposite directions then the intermittant position does not rotate back and forth smoothly. It snaps back.

Added good sir. If there's any I've missed just shout them out and I'll add as written And for the next release's bugs list I'll add names of who reported the bug so Ruud can ask for more info.

 

[Mr Whippy]

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!

So, cameras, broken

Dave

 

[boomer541]

Another bug! I put a glass cover on the views KPH and RPM gauges and the needle disapeared. Tried for two days to fix but could not then I looked through a side window of a different car at the RPM/KPH gauges and lo and behold the needles disapeared.

Definately a bug!

 

[Mr Whippy]

Cam might know the answer to that one as he was complaining about a shader for the gauges... iirc there is a shader used for them that you can access or something.

Just checked his F458 and the needle sits fine under some glass... but after another layer of glass (car windscreens) it disappears. I'm guessing he uses a specific shader just for that glass that sits over the needles so it can have the properties tweaked just for that bit of glass!?


Assuming it's a transparent shader then maybe it just needs the sort_offset tweaking for that glass specific to the needles being covered?

As per needle coverage from other cars or even outside the car, I can live with them not showing up, but of course it's important for the interior driving view

Dave

 

[skybh]

Hum is not it related with the depthwrite?
I can say :
With my cars with digital gauges, i had sometimes this, i think add "depthwrite=0(or 1?)" to the shader of the glass should fix it

 

[boomer541]

Thanks skybh, I'll try that.

 

[Mr Whippy]

I'd also try sort_offsets... depthwrite=0 just seems the wrong way to force the element to not be hidden... and if possible move that glass over the needles to it's own shader...

I'm also wondering if there is a better way to do this glass over gauges/needles.

In theory it's almost always 100% see-through, and it's also usually got no details in it. The effect we want for it is purely for some reflection mixing.

Could it be a much more svelte shader? Ie, does the blend really need to be there at all? Or can we just mix based on the dst_colour (envmap intensity)?

Ie, no diffuse, no ambient, no specular, just write (add?) the envmap values over the top of the stuff underneath?


This is probably more Stereo's domain really as he gets shaders a fair bit more than me from a technical pov... i'm not sure if that is faster or not... but like I said there is little going on to me except adding the reflections values over the top!?

Dave

 

[boomer541]

Thanks for the tips, but nothing I've tried works. When glass is transparent objects s/b visible on the far side. When the object is produced with views.ini they are not and I'll keep working on the problem that is a potenyial bug for Ruud to look at.

 

[Mr Whippy]

I'm not sure what is going on there then...

How did you get the dials on the Bugatti working? Are the needles over the glass?

All I can guess at is that as per Ruuds post on the sort_ordering, the views.ini element shaders (were they given shaders somehow at some point, I vaguely remember needles being able to use is_3d or something in views.ini??) might need pushing back up the sort_ordering?

Try -500 and +500?


Or if not already using, try the "is_3d=1" flag on and off in the views.ini elements?

Dave

 

[Alex Forbin]

Getting back to my bump shader issue. I now know it's not a simple problem with bump map generation, since Daves Gallardo update shows the same problem. This is on a clean install of Racer I use for testing.

Alex Forbin

Edit: Oops just realized he didn't use bump mapping on the tires. Oh well, it just shows the problem is not just related to the bump shader alone.

 

[boomer541]

Fixed glass bug! Tried Mr Whippy's "file=dyn_standard_reflect_transparency_window_f.cg" that he used on the Gallardo, but it really fouled up the glass a. "depthwrite=always" in the glass shader did the trick.
Posting the glass shader I used in the Bugatti Type 57 thread.

 

[Mr Whippy]

The Gallardo glass uses a different technique/shader to the 'old' cars, it uses a diffuse texture and a control texture... it's very flexible but for most uses most of the texture channels are redundant... but hey, texture memory is cheap... ish... hehe.


Alex, I think Stereo worked out that it was mainly the shadow map not doing a very good job through layers of nearby surfaces... in this case the wing over that tyre is quite close so the shadow map isn't catching it... I bet if you made the suspension longer iteratively you'd find that point where the shadow map 'catches' the tyre and shadows it...
It looks like the back wheel is shadowed?


And the real issue here is that one I've pointed out a few times (and I'm sure it was fixed at one point but is broken again haha), and that is how the shadow map we see nearest the camera seems to be the lower quality one first.
Ie, shadows are sharper at the far end of the car than the map near the car which is using a much larger casting area, and so quality is worse.


Here are a few pics again that show the issue...

Sometimes I see the tyre problem, other times I don't, so it's probably likely related to the shadow map being used on the car often being the inappropriate one!?

Or something related to that process maybe?

Then again maybe the tyre shadow thing is another problem? Perhaps just generally related to the rather 'average' shadow attachment on sharp edges etc... where there always seems to be a big offset. Some times you don't notice it but other times it can be really bad... I'm not sure where the coefficients are to tweak that 'offset' but I assume they exist in shadowmapping.cg or whatever it's called?!


Hmm

Dave

 

[Alex Forbin]

I see what you mean about the shadow quality. And the coverage does indeed vary with distance.

Alex Forbin

 

[tormento19]

Gonna try the multiplayer on v0.90 RC5D and like it's already posted in the bug list, i can't host or join It's a pity!

 

[Mr Whippy]

I think you can set up and play a game if it's hosted and you share your IP with joiners to direct connect... just make sure the firewall is open for the correct ports.

It is temperamental though...

Pretty sure the hosting/lobby system is non-functional though. Which is a shame really. I remember back when the TtR/T-Shine Gallardo was new out on Snowball's figure 8 track and this stuff worked great and I remember four or five of us racing around there... that must be about 8 years ago now?!

A bit of a shame that Racer has almost stepped back in being a stable multi-player environment.
Ie, less stable, no lobby system, no dedicated server support... just completely and utterly forgotten as a feature

Considering the rise and rise of internet play in every game, including racing genres, it's sad that Racer has as said, stepped backwards really

Dave