Racer v0.9.0 RC5 released

Ruud

RACER Developer
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
 
Hmmm, all my normal maps here seems to respond as I expect them to respond.

I was pulling my hair out the other day with normal maps (dyn_standard_bump_reflect) for my alloy wheel blur models, the normal map was spinning.
But then I realised at the last minute that I was using the wrong vertex shader... I think I was using dyn_standard_reflect vert shader because at first I was trying without a normal map.

So just for double checking I assume that both vert/frag shaders are set right?

Yup, only difference is the textures are .tgas. Although the RX7 does have some strange shader behaviour (the disappearing logo texture, and random white flashes) so it's possible there are issues elsewhere in the file.
 
Maybe DDS are the issue then?

I personally like TGA for development work, they are faster... but DDS make sense for final stuff, and also you can do clever work with the mip-maps (or some would say the 'proper' work with normal map mips!)

I also find the PS DDS format thingy breaks the alphas or something, they look like 4bit not 8bit... not ideal either.

Maybe Ruud still has some DDS issues then, I remember a while back DDS dxt5 (iirc) was really broken on the alpha channel!

Dave
 
Unfortunately the GIMP dds plugin is not very good either, it'll export a single layer and generate mipmaps from that one. I haven't looked into if I can write a better one; not my area of expertise.


I tried with a dds texture and it didn't fix the problem.
There are really 2 oddities - the first is near 90 degrees as it goes into shadow (7 seconds), the second is when the camera's facing the sun and the top shines (10 seconds). The first is a lot more subtle but it's quite noticeable ingame.
 
Hmmm...

I can see the issue at 10s, but not sure what is wrong at 7s...?!

Let me do some tests on my tyre here... looking mainly for the issue at 10s!

Dave

The biggest problem I've had is the specular would flip its Y-axis when turning the car in a circle, this makes materials have an apparent sheen to them.In other words when the car is facing the sun the material is shaded from the top, when facing away from the sun it's lit partially from the bottom as well.
The fix I posted should stop that (it did on mine) but the shadows still have a specular like shine, but it appears to be in the diffuse?? Odd.

Alex Forbin
 
Maybe DDS are the issue then?

I personally like TGA for development work, they are faster... but DDS make sense for final stuff, and also you can do clever work with the mip-maps (or some would say the 'proper' work with normal map mips!)

I also find the PS DDS format thingy breaks the alphas or something, they look like 4bit not 8bit... not ideal either.

Maybe Ruud still has some DDS issues then, I remember a while back DDS dxt5 (iirc) was really broken on the alpha channel!

Dave

Could you give a breakdown of what you use to make your DDS bumpmaps and what the specific format is? The reason I ask is that your tires do look really nice. :)

Alex Forbin
 
Unfortunately the GIMP dds plugin is not very good either, it'll export a single layer and generate mipmaps from that one. I haven't looked into if I can write a better one; not my area of expertise.


I tried with a dds texture and it didn't fix the problem.
There are really 2 oddities - the first is near 90 degrees as it goes into shadow (7 seconds), the second is when the camera's facing the sun and the top shines (10 seconds). The first is a lot more subtle but it's quite noticeable ingame.

Have you tried the fix I posted?

Alex Forbin
 
Hmmm...

Just to clarify on my mini-points at the bottom there.

Basically I'm trying to get a shader working that works thus:
......

Generally really nice for track stuff without reflections (well, envmap ones) any way!

Hmmm

Dave

I think once we get the lighting straightened out, many of the odd behaviors we are seeing will go away, then we can work on a nice tight set of core shaders.

Alex Forbin
 
Have you tried the fix I posted?

Alex Forbin
Still doesn't feel right after that change.
ieIFeyZ.jpg

It does get rid of the spot opposite the sun, but now when I'm looking from the direction of the sun, I get bizarre specular response - it's on all sides, but not in the middle (which is the part that should be reflecting the sun).

Should also note that it doesn't match the wheel's orientation properly. When I move the camera, the specular spot shifts, when I turn the steering wheel, it stays pretty much on the same parts of the wheel (top/bottom/side) despite the angles shifting quite a bit.

I'll try to run through the math on specular and see what's going on, cause there's definitely something wrong that goes beyond vf_standard_bump. When I swap that texture over to standard_v/f, I still see the weird specular from behind and stuff.
 
Stereo, just to clarify, you are using dyn_standard_bump* shaders?

I'm assuming you are but just to check that things do go wrong if they are not.



Alex, to make my tyres took a fair bit of testing techniques.

In the end I modelled the tyre tread pattern in 3D, fairly accurately too (little bevels and all the details)... I even counted the tread blocks around my specific tyre, found the pattern for how often the big/small blocks repeat, the wear markers etc...
I could then render out AO passes and other stuff... I then just dumped it all in PS to tweak it to feel right for the diffuse/spec channels any way.

At that point I tried using a normal map output from Max directly (a material that is just giving those pure colours for up/down/left/right etc) but the issue is when you mip a normal map you bias it, a normal map shows the gradient via a biased look up table basically, so resizing in theory needs a new bias.
Resizing a normal map makes them go gloopy looking in the mips.

So instead I just ran a gradient map (black to white) through the depth of the tyre profile, rendered it out (in essence a height map), then used PS Normal Map tools to generate the normal map. I tweaked it to get it right looking at the first mip level, then just resized the height map for each mip and generated a new normal map.
Iirc, there is an automated system to do this but it only takes 5 mins to do it manually as I wanted to check each mip as I worked through any way.


This is another material imo, where gloss is more important than specular. 1-kd from the diffuse channel for the specular would be fine. It's the gloss differences from scrubbed or patterned areas from tread blocks to smooth gaps between tyres that make them 'pop' out at you.

Here is a copy of my texture. Obviously no normals for the sidewall bit. This is a bit of a hybrid tyre really. The tread pattern is F1 Asymmetric 1, the sidewall Asymmetric 2. I need to rebuild the tread pattern for the F1 A2 and finish this really.

Hopefully if we can get a nice 1-kd/gloss/normals type shader working with fresnel for dynamic stuff too, then I'd be using that for my tyres!

tyre_example.jpg


Note the nice UV unwrap for the side walls. High quality and efficient with a nice even pixel density, elegant UV repeating, and easy to fit 4 smaller versions in the same size texture, offset the UV's, and blur them for motion really nicely for wheel motion blur models.
Again, it takes more time to do but it pays off later imo.
 
PS,

I seem to get the light leaking onto the very top of my tyre at very shallow angles and giving a specular response (the issue at 10s in Stereo's video)

It's certainly not in the shadowColor since out0.rgb=shadowColor shows no problems... so it's sneaking in via the litColor somehow.

Maybe this is just the shadow map having issues knowing what is in it's coverage or not?

Does the tyre still do this in strong solid shadows, say from a building etc?

Hmmm, no, doesn't appear to.

So is this just the tyre getting litColor rather than shadowColor because the shadow mapping at this proximity is, well, not so accurate through the bonnet/wing tops and on to the tyre top?

At higher sun angles the ability for the car to effectively cast a shadow onto the tyre seems more robust and the issue goes away... but at these low angles it seems to become a bit unreliable.


I think the normal mapping is fine right now... I'm really enjoying using them and they work as expected. These weird behaviours seem to be a function of other elements that maybe need refining (ie, shadows at low sun angles)

In motion on most tracks I don't notice these problems... I bet they are evident in GT5 or Forza 4 if you go looking for them?!

I think the generally gloopy looking normal maps people seem to get is more a function of bad mipping (DDS and authored un-biased normal maps help here), and also the material properties (gloss maps with energy conservation seem to make normal mapped materials appear a whole load more believable!)

Dave
 
I'm thinking you're right, it's a problem in the shadow function - GetShadowFactor.

This is what happens when the wheel shader is just returning the 'lit' value of a given pixel. (since that maxes at 1.0 lux it's not super bright; it's all relative)
WbQhbMH.jpg

The sun is essentially above/forward of the hood. So the curve of light (mimicked by yellow) is normal - that part of the tire is genuinely lit.

The band running across the tire, though, is not the shadow/not shadow of any part of the car - it's light coming through the hood.

The bumpmap just changes the nature of this error.
Gx7SpLw.jpg

Normals are all over the place, so it's not a single band. Regular shadow casting is relatively un-impacted since lighting works on the position of the pixels anyway.

If I'm reading the source right, this is basically conflict between 2 needs - not having the repeating ripple pattern on surfaces at an angle, and small cylinders looking funny.
IpHPRUT.jpg

Black: physical model
red: shadowmap
green: 'correction factor' that moves the object towards the light source
black dashed line: where it ends up assuming the object is.

When the correction factor is small, the bumps on the shadowmap make it 'closer' than the object, producing the lines. When it's large, it makes the cylinder effectively invert itself, so that the edges (which should be deeper in shadow) are actually closer to the sun.

If I'm reading the source right, the correction factor should be a max of the smCor in constants.cg, ie 0.0012, 0.005, 0.0075, 0.028 - but these are multiplied by the 'depth' of the shadowmap in metres. So if the shadowmap is a box 100m deep, then at the lowest level it's 2.8m correction factor.

Presumably when the sun is low the shadowmap has to be deeper to fit in objects, since shadows cast are longer, and it makes the problem worse.
 
I still struggle with the blurry shadows near the camera and they get sharper further away issue... it's probably part and parcel of that maybe?

Maybe we are getting a lower res shadow map on these close-up elements this we are close enough to see the jagged edges basically!?

If you double the shadow map resolution do these problems go away?

Hmmm

Dave
 
Anyone else find the current bloom system a bit annoying too?

Rather than operating on over-bright pixels (ie, not reasonably exposed), it just operates based on what appears to be the LDR intensity.

So a scene that is normally exposed with no blown highlights still 'blooms' a bit.


Why can't we check for over-bright pixels (probably with a curve at the edge of exposure to soften the transition), then blur the resulting HDR element.
Do the LDR pass, then using the exposure value set, LDR the HDR blurred map, and 'add' it over the top?

It can't be any slower than the current method which does lots of calculations, but it'll be based on real values rather than an LDR approach based on, well, arbitrary coefficients!?


Ie, can we dump the bloom from Racer.ini, remove it from the FS shader, and add this feature ourselves?
In theory you could even blur it with a texture to get the 'star' appearance from a lens glare... Hmmm...


I'm thinking we can but not sure where to start haha.

Just frustrated with the current flares system (hard coded with directions, appearance, behaviours etc, so no ability to be 'creative' with them)
The bloom behaviour seems to do ok on headlights etc, but if you try have a really bright day-time element (say a police car flashing light or similar, they just don't bloom up because the bloom system is LDR)

We really need to start dumping these 'old' features and replacing them with automated effective 'real unit' new ones that just look good and work as expected right out of the box... and are flexible.
Ie, I can't qscript or Onyx access the 'flares' feature, but I can access models that are very bright and move them and make them have a glare via the bloom system...


I hope we have some good news on Onyx for the next Racer release...! (ie, all variables properly exposed with logical paths)

ie, this_car. *car.ini tree sits here* or this_track. *track special.ini, geometry.ini, trees sit here* etc etc... :D

Dave
 
If you double the shadow map resolution do these problems go away?

Hmmm

Dave
Not seeing a difference at 2048x2048 shadow maps. 4096x4096 works but at that point it's using up about half my framerate on them.

They do look a lot nicer though :p

With respect to bloom... hmm. Would be nice if the method for generating bloom maps was exposed, yeah. Not sure what I'll do about it. Still haven't tried that fix you posted to get the sunspot a more reasonable size.
5Yax2TM.jpg

This is just with 4 different input light levels (10 times lower klux each time), I guess bloom would work off of these, blurred?
 
I guess maybe the algorithm for the shadow mapping just needs some optimisations at steep angles? Or another feature to try 'soften' the stepping pattern in these cases?

Generally when you have a lot going on you don't notice them, but even in GT5 I see shadow map creeping and stepping going on at times...

I guess like everything, it's FPS vs visual quality. We are quite obsessed with Racer stills quality when in actual driving/replays I think Racer just looks really great...
Right now the only thing standing out for me is the weird motion blur stuff.

For stills, well, assuming we wanted a 'stills' mode we could just bump up sampling, shadow map size and all that stuff for a 'photo mode' config with about 5fps but very nice quality :D


Realtime I'm happy for the odd visual problem if it means good FPS and 90% of the time things look 'ok' :)




As per those last shots, what are they showing? A change in sun intensity value (TOD curve)?


I think we could do bloom ourselves entirely in the fullscreen shader.

Take the tone-mapped image at the given exposure. See which areas are 'blown out'

Use that info as a mask on the HDR image to subtract intensities which are exposed 'ok'

Then blur that data, re-LDR it using the same exposure setting, then 'add' it over the LDR image originally generated.

Since the blurring we experience is a feature of glare (pretty sure it is any way) due to the aperture of the sensing device (from our eye to multi-element lenses), we can blur the blown out data using a look up image (see glare maps in renderers like Maxwell renderer, or 'shape blur' filter in photoshop which can use an image as a blur mask)

Since we blur the HDR data, we get a softer subtle effect on the very feint over-exposed elements, but those areas that are highly blown out will still remain very strong with blurring.

With a glare map like a hexagon we would get a nice 'star' effect automatically on very bright items (auto-glare/lens flares)


In 'theory' this is all pretty basic stuff I would imagine... but I'm no shader expert hehe... but I know how I'd set layers up in PS or After Effects to get these same kinds of effects that 'look' kinda real using HDR input images...

Hmmm

Dave
 
Hmmm, looking at this.

Dumping Bloom from the bloom shadows blur shader is easy.

Then there seems to be the alpha channel left over from the old alpha blending motion blur...

You could probably store the 'bloom' data there?! Blur it, then re-add it over the tone-mapped output.


Just trying to think this through. Hmmm...

Check tone-mapped image, any point over 255 rgb output is 'ticked', that point is passed to the alpha map channel for that pixel.

The HDR input map is then masked with that alpha map, normalised from 0 > X (where 0 is values that were *just* over-exposed... but the data is still linear HDR.

Then blur it. Then tone-map it, then add it to the original tone-mapped image?


Seems to make sense to me haha.

If I knew how to 'save' HDR frame buffer data it'd be super easy to test this logic in After Effects!

I guess the biggest cost is the blurring, but the current bloom system doesn't exactly look super svelte or anything.

Hmmm

Main attraction for me is bloom that is actually emulating glare with real values, and will automatically do nice glares on bright items for us!
If we can then define different glare maps we can get some nice effects for different views/cameras etc (i still think each camera for replays should be able to have a defined exposure compensation value, or define it's own fs_filter file with DOF, vignetting or whatever else you like)

Dave
 
That's actually a fullscreen shader I wrote that duplicates the scene, then cuts the klux values progressively each time (so one is showing actual values, one's 1/10 that, next's 1/100, etc.)

The way I'm thinking, nice looking bloom is basically gonna be a blur of one of these levels, which represents the fact that the source is so bright that it diffusely lights up the lens element instead of being completely transmitted.

jdmpcdo.jpg

top: blurred, and 1/16 as bright as the original (to represent the fact that only a small amount goes into the blurryness)
bottom: regular (slightly overexposed) view.

If you just add these (done in gimp) it ends up a little more overexposed but the middle distance lights turn out ok.
28hup1S.jpg


I haven't yet done the 'subtract out non-overexposed pixels' aspect; maybe that'll make this look better.



On a different note is there any way to skip materials on the velocity map pass? Anything seen through glass is getting the glass's velocity.
 
That is basically it Stereo... nice work!

All you really need to do is subtract the non-over-exposed light from the image pre-blur, since that light made it through the aperture 'ok' I suppose.

It's the light that glares/diffuses/internally reflects, or whatever other effects go on in the aperture to your light sensor, that we want to treat with our glarey process/blurring etc...

We then tone-map that the same again (so it's basically from black to white now (since we normalise it from 0 upwards), so subtle over-spill at edges etc is a subtle dark grey 'add' around edges etc, while really strong light blurs but remains very bright.


I'm not sure how correct the Maxwell renderer was but I assume it was pretty accurate to real light, but with Maxwell if you set scene exposure per real camera settings you'd get a nice look... but when you added the glare map and glare it'd always boost overall image intensity for a given EV.
I suppose it is excess light getting in the aperture and interacting with it (through diffraction at the iris or internal reflection or whatever else) and hitting the sensor and adding to the total light exposed (over-exposing), despite the theoretical aperture/f-stop/iso being set for an 'ideal' exposure.
I suppose you also get this effect when you expose for a scene that has an abnormally bright spot in it, so although the darker areas of the scene are exposed ok, that bright element and it's impacts within the aperture become quite dominant.


In any case, your method is most of the way there, which is cool.

If this bit can be made to work nicely without 'fudge' factors (although I suppose glare is ultimately a function of lens/aperture etc) then it'll hopefully result in more reliable bloom/lens flaring on bright lights in the daylight.

Ie, create a shader in midday sun at 10,000 klux, or 100,000 klux. No matter what you set it at it never seems to get a 'bloom' glow/glare around it.

Dave
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 74 7.2%
  • 75% online 25% offline

    Votes: 107 10.4%
  • 50% online 50% offline

    Votes: 150 14.6%
  • 25% online 75% offline

    Votes: 282 27.5%
  • 100% offline racing

    Votes: 410 39.9%
  • Something else, explain in comment

    Votes: 4 0.4%
Back
Top