Racer v0.8.23 released!

[Ruud]

An important one.
Troubles expected with this one:
- linearity of the steering wheel (you for one now need to specify the wheel lock in the setup screen before starting to judge things)
- a new parameter ('sunny') in most fragment shaders (any typos?). For a simple 'overcast' type of thing where you allow less sun to shine through.
- dbg_car.flip_tan=1. Perhaps a major breakthrough on the physics end. Where I always used a tan(SA), it might have needed to be atan(SA). Ouch, we're going to test this on our high-end sims later today, see how it feels (easier to do than with a G27).
- steering controls are now in degrees, rather than normalized. How about center_squeeze (and related) for Mz reduction near 0? Haven't looked at that yet.

The download: http://www.racer.nl/download/racer0.8.23.zip (67Mb)
Then get the latest exe flip_tan bugfix (only exe): http://www.racer.nl/download/racer0.8.23b.zip
(5Mb)
*after some testing, it appears than dbg_car.flip_tan should be 0* (the older situation)

The changes:
- Steering revised quite a bit - the controls for steering left/right now use degrees, instead of being
normalized. This changed some things inside the physics engine to use rotation more directly.
The idea: set your controller's lock correctly. With cars that have a steering lock that is smaller
or equal to that of the controller lock, the steering is direct (1:1). If a car has more lock defined
in its car.ini, linearity will be applied on the controller's steering output (now in degrees) to let it
use the full range of the car's steering wheel (linearity=controllerLock/steerLock).
This all targeted a bit for 900 degrees where you no longer then have to tweak for a lot of cars.
The controller setup screen is being worked on to visually check the lock (press F5 twice in the setup
screen to show the 'Wheel' page).
- Controller lock is now saved in the setup screen.
- A new important physics tweak is available: dbg_car.flip_tan. Defaulting to 0 (the v0.8.22 behavior),
setting it to 1 modifies the slipangle calculations for each wheel to use atan() rather than tan().
The tan() has been in there for a long time, to stabilize high slipangles. But, tan() makes values
worse as they grow, instead of flattening them like atan(). So, this needs to be investigated;
probably it has quite an influence on slipping behavior (with big slipangles).
- bloom_shadows_f.cg accidentally had bloom turned off
- Flare Cg shaders tweaked for nicer looks (alpha changes)
- log file position group added 'lap' (ASCII format)
- Added motion_blur.stencil option - use 1 for the old projected shadows, 0 for shadowmapping (faster)
- Added dev.nvidia_perf option that will try to access nVidia PerfSDK counters if installed.
Install an instrumented driver for this to work.
- Added a profile debug page (Ctrl-6, may have to press twice for the 2nd page) to see some nVidia performance counters.
I must say it bluescreened my XP machine more than once, so be careful with instrumented drivers.
- Added envmap.live_track.frames_per_update for more live track mapping control
- Fixed some tough render engine bugs that messed up Z-buffer usage (mirror on made the screen flicker)
- Generic models weren't transforming; fixed.
- Added wiper modes (off/interval/normal/fast), use 'w' to switch to the next mode (see also Ctrl-4 for the current mode)
- dyn_standard_bump_reflect_f.cg now also lets bumpmap alpha affect specular (next to reflectiveness)
- Sky_f.cg and sky_daynight_f.cg modified so clouds=1 now gives the normal effect (and does not raise
cloud regions to 175 klux!)
- A track's exposure in special.ini is now correctly used as the initial exposure (no more starting
with white, then coming back to a normal exposure if you set this one to a nice value; like 0.02?)
- Fixed a bug in the fresnel calculation in dyn_standard_bump_reflect_v.cg, which gave bad looking
reflections.
- Selecting Bloom/Shadowmapping from the menu gave problems with undefined 'gammaFactor' errors.
- Surround Gaming mode camera aspect fix (director mode)
- A surface's 'grip_decline_driveline' now defaults to 0 (was 1). Fixed issues with grip declining by default.
- Panorama shader's extinction now uses 'scale' Cg parameter instead of hardcoded value (5). Add 'scale' to
your track.shd file.
- Backfire would sometimes not work. This and a bunch of other uninitialized data fixed.
- 2D elements in the render engine could mess with motion blur blending (OpenGL state cache).
- When bloom was on, the aliased buffer was anti-aliased twice! (for bloom and at postprocessing)
- blur_alpha didn't work; the fullscreen shaders didn't output correct alpha. Using a bit of blur_alpha now
by default (0.3).
- Auto exposure sampling did an anti-alias pass; now it uses a previously anti-aliased result (faster).
- Dropped config.exe for now - anybody using it actively? Most should be settable ingame.
- Added 'sunny' in special.ini (tracks); 0=totally overcast, 1=super sunny. For ground objects.
Needs to be added to all fragment objects though. Also adds script cmd 'sunny <x>' to set it live.

 

[luthobu]

Strange. I can start 0823 but if I select any car or track it crashes. No idea why.
My ini is optimized as usual, but still no luck. Could it be the renderers? Will try
with the 0822 renderers - they work - and replace one by one to see if I can track
down the error. Still using the ATI x600. Also tried with my old onboard Intel and
it did not run at all. Shame really, I was looking forward to this one after finding
that 0822 was such an improvement...

Edit: It is not caused by any of the CG renderers but is a hardcoded error.

 

[ammods]

spoke too soon getting same problem here as well.

 

[Alexander Knoll]

hmm...not sure, but the smoke move to the wrong direktion...?
...wheel spin at start...so the smoke should move to the rear end of the car...not to the front...?!

EDIT:forgot it...after restart Racer it was ok...

 

[Alex Forbin]

A good release Ruud, there's a lot to play with and it seems to be low on bugs. There are a couple I've found however.

1. Racer will crash after I set up my DFP in the controls menu. If I copy my old control.ini over and add the new lock= function it works fine.

2. Tire smoke seems to pour from the front tires at the least sign if slip, is there any way we could change to some form of tire heating by mult the SA and the time maybe?

3. Skid marks only work when sliding laterally.

Thanks for the release.
Alex Forbin

 

[Alexander Knoll]

hmm....i use DFP too, but no Problems....no crash after setup....Alex witch OS do you use? I'm on win7 x64 Ultimate...

 

[Alex Forbin]

XP pro corp.

Sorry I forgot to mention it's only when I use the autodetect function that it crashes.

It will only write part of the file too...

 global
{
  name=Racer controls - defined ingame by menu
}
controllers
{
  mouse
  {
    enable=1
  }
  keyboard
  {
    enable=1
  }
  joystick0
  {
    enable=1
    index=0
    force_feedback=1
    kerb_magnitude_factor=1
    kerb_period_factor=1
    max_torque=20
    max_force=10000
    deadzone=0
    latency=0
    friction=1000
    inertia=0
  }
}

Alex Forbin

 

[luthobu]

Just curious.. but does anyone know why 0823 crashes on some machines when loading content?
I have tested the renderers and it is not any of them, so I figured it might be hardcoded. What
is the biggest difference between 0822 and 0823 that can cause this error? Racer starts, I can
do all kinds of stuff in the main screens, but as soon as I select a car or a track it dies on me.

I would very much like to see it fixed since 0822 looked promising and I was getting my hopes up.

 

[Marcin Sobkowiak]

I does work on my pc but when:

1) I have shadow mapping switched on and set max resolution 1366x768 I get ~20-30fps with CG cars (it's a bit lagging) and game doesn't crash while using ESC button. When in 1024x768 I get 50fps

2) I switch shadow mapping off game is running with 60-70fps and crashes while pressing ESC (1024x768, fullscreen)

3) with shadow mapping on, all non-cg cars are dark or black

4) at non-cg I get over 400fps :]

5) What happened with config.exe ??

Anyway great release, prefer this version to previous. At least it works;] Tested on carlswood nt.

PS. later I'll upload pics with errors I got a few times.

 

[Stereo]

In the shader, you could end with 'outColor.rgb=fresnel' (check specific variable names) to visualize fresnel. I do that all the time to visualized components in the shader, to hunt bugs.

Yeah, that is helpful. Looks like the Lamborghini has much less Fresnel falloff with the default values (the Aronde's chrome is basically set to reflect in all directions, and auto-exposure is compensating which is why it's darker than the other two).

 

[Mr Whippy]

General observations.

If you turn off blur samples in constants.cg then it still seems to blur. You need to use Racer.ini to turn blurring off?! Annoying to have a constants.cg file, and then have another load of constants in racer.ini... can we not put them in one place? Even with samples at 0 and blurring off, it still looks to blur.
Why can't we just have a single value, 0 = no blur, 2, 4, 8 etc = more blurring/sampling quality?


constants.cg tells us to have the map size for shadows the same as in racer.ini, it's not. Is it lying, or does this not matter any more? Where do we set shadow map size, where do we set blurring. Isn't it starting to be messy defining things for shadows in two places? Same issue as above.


Clouds 0 seems to make a black sky... have things changed with how we need to build skies? Should we only ever go from 0.01 > 1.0 for example?



Clouds values larger than 1 still shows the clouds, even when the alpha channel for the clouds is 0 rgb. I thought alpha determined coverage? However this is calculated, if the alpha is 0, multiplying it by 100 will still equal zero... it seems to be the diffuse texture in it's entirety that is visible in this case.


Sunny seems to work ok I suppose. It's kinda useless without actually removing the bright spot in the sky when sunny=0 though.



I'm just concerned that the sky/atmosphere is now a bit broken with the clouds/sunny features. Seems to be weird cross-interactions going on.

I've found that to achieve a look like in 0.8.22 when I had it working really nicely, I need 0.35 for the auto exposure gradient. With the default value things look a bit too light really, even sunset looks 'light'


I'm also having issues with the fogginess/mie/ray.
What values looked nice in 22, now look almost greeny in 23 on my distant terrain. Has anything changed to do with the way mie/ray are calculated? Anything to do with 'sunny'? I'm having to drop ray values, and then add extinction factor to get it looking the same.
Dusk is now a nice greeny misty colour where before it was a light blue or moving into orange. To get a similar look to before, I'm halving ray, ish, and doubling extinction_factor.



There are starting to seem to be inter-dependencies between things which are ultimately influencers on those inter-dependent items themselves.

Ie, "sunny" seems to influence the sun_diffuse, but sun_diffuse is a function of the sun spot which is still being rendered on the atmosphere, and the intensity of that is a function of mie/ray and clouds amount, but sunny also seems to impact the effect of mie/ray too. Hmmmm...

I think something is broken in there, quite badly.

I hope this part of the system is streamlined and made very clear and logical to use before v0.9.

I'd hoped that developments with skies would be simplifying things (ie, tod/date/lag.long/mie/ray) and then the rest is all driven from those values... if the sun gets occluded by clouds (kinda like sunny value), then the envmap intensity change drives the new values for diffuse/ambient.
When it's hazy and foggy, the sun spot is rendered larger, and so shadows soften (more blur and smaller shadow map size?), when it's clear the map is higher res and no blur... for example.

But this system of sunny AND clouds, AND having to have curves for diffuse/ambient which are very much driven by the intensity of the envmap of the sky (take numbers from mip-map that is used to get scene exposure?), seems a bit bad from a developers point of view...

OK, this isn't v0.9, but adding more complexity seems bad, before we have got what is already too complex for many, simplified.

Ie, carlswood curves are only good for carlswood. Change the lat/long or date and ALL the curves are wrong. Nooooooo


Dave

 

[Mr Whippy]

Alsoooo...

Force feedback stuff now.

It'd be nice if we had more control per car.

Sometimes I can get a good balance of friction and force feedback of effects through the wheel, but then it's too strong, but to weaken it I can't, without altering the controller.ini settings.
Also, for some cars, the two values in controller.ini are not ideal, needing to maybe be closer to each other, or a bigger gap.


So, I think it would be logical to have

ff_factor (as we have now, which is for the Mz and kpi offset 'feel' strength)
ff_friction_slow_factor (to alter the slow factor by in controller.ini)
ff_friction_factor (the normal one from controller.ini)

ff_strength (an overall factor, so once the above three are fine tuned, we can then tune this one per personal preference)

The reason for this is that the author can now get a car to feel how they need it to, the balance of friction and mz feel and all that, and then set an overall strength for it once they feel the balance is right. They could achieve the balance easily with the first three, BUT, anyone getting the car who found it too strong, would start tinkering, and that is like going and messing with pacejka c variables to tweak the FF strength...

Also, later, when we start to make cars consistent against each other more, it'll be easy for certain power users (like Ruud with high-end gear), to determine the ideal settings for cars against many others, and just change this one setting.
Then a global strength could be added to the set up screen for the controller (ie, a person with weak arms may set it lower than a stronger person)... but then all the cars inside the game are set up relative to each other, so lorries are heavy, luxury saloons are light etc...


Just thinking longer term there, but for the short term adding the friction factors and a strength factor, imo, make good sense, and in theory it's easy to do

Dave

 

[QuadCoreMax]

Just thinking longer term there, but for the short term adding the friction factors and a strength factor, imo, make good sense, and in theory it's easy to do
Dave

Friction is also present in materials.ini, maybe you need more time to test all kind of possibilities.

 

[camsinny]

Afaik that's a completely different friction system QCM. That's to do with how things slide across a surface (for newton interactions) whereas Whippy is talking about FFB friction.

 

[boomer541]

Having problems with skies and tod curves on tracks other than carlswood. Testing transition thru 24 hours has headlights getting too dim night being too light and a general bad result.

It looks like the sun is on the far side of the sky on carlswood as it dims a bit going past clouds but on other tracks it doen't and getting a proper sky image texture with proper alpha channel to work is a real pitb.

We definately need to have the sun on the far side of the sky and control the light as it passes clouds and terrain, imho. It's done with the day texture alpha channel setting, to block sun the pixel needs to have an alpha value of 255.

Got good shadows with changes to constants.cg and racer.ini, I'll post them tomorrow.

Back to work on good skies!

 

[MitchVL]

How does everybody like the new improved shadowmapping ?

Improvements:
- Shadowmaps have a heading, so you have more resolution in front of the camera.
- angle between pixel normal and sun angle now determines how much correction is added, so resolution artifacts are far less likely now.
- Played around with split distances and tested them on Ruud's desktop and mine. fe: fence shadows should be as good as it will ever get on our setups.

To give a comparisson on how GT5 shadow maps look:
goto 1:40 and look at the shadows from the kart coming from the right

We're not doing bad at all !

 

[Mr Whippy]

We are not doing bad, but car self-shadowing isn't as good as it was in 0.8.22 with the same splits imo.

The shadowmap heading is an odd one, it's impossible to check since if you turn to look the other way, the shadow is now re-drawn with more quality haha.


I couldn't seem to get the blurring turned off with 0.8.23, like there is always some built in?


I also think the split distances turn off shadows too soon. Can we not have a global slider for shadow distance/quality?

Blurring needs to be thought out better too. The default is very soft, which is ok for a soft ish sun, but on a bright clear day shadows need to be sharp, and they look better sharp with no blurring with 1024 maps imo


+ the mie/ray issues above, with greeny sunset mists, clearly shows something wrong there. Will be hard to tell how it's all working until these issues are fixed

Dave

 

[Alex Forbin]

How does everybody like the new improved shadowmapping ?

Improvements:
- Shadowmaps have a heading, so you have more resolution in front of the camera.
- angle between pixel normal and sun angle now determines how much correction is added, so resolution artifacts are far less likely now.
- Played around with split distances and tested them on Ruud's desktop and mine. fe: fence shadows should be as good as it will ever get on our setups.

To give a comparisson on how GT5 shadow maps look:
goto 1:40 and look at the shadows from the kart coming from the right

We're not doing bad at all !

Wow, I never realized that GT5 shadows looked so bad! I agree at this rate we should be able to pass them in image quality soon.

Alex Forbin

 

[Mr Whippy]

How does everybody like the new improved shadowmapping ?

Improvements:
- Shadowmaps have a heading, so you have more resolution in front of the camera.
- angle between pixel normal and sun angle now determines how much correction is added, so resolution artifacts are far less likely now.
- Played around with split distances and tested them on Ruud's desktop and mine. fe: fence shadows should be as good as it will ever get on our setups.

To give a comparisson on how GT5 shadow maps look:
goto 1:40 and look at the shadows from the kart coming from the right

We're not doing bad at all !

Hehe, they are rather nasty shadows. That said, GT5 is running 16 cars in some races, I wonder if they have had to trim shadow complexity to get back FPS somewhat... it's hard to say really. BUT, Racer is certainly nice generally.


However, the heading tweak on shadow resolution needs tweaking somewhat.

Check this screenie:

http://gowhippy.com/racer/shadows_stuff.png

One is 0.8.22, the next is 0.8.23.

The 23 is noticeable by the fact the shadow is soft at the back of the car, and sharp at the front, if I pan back with the camera, the back gets sharp. The camera position for the heading seems not ideal. Is it using some kind of offset to assume a distance from the object of focus?



Also note that the 23 version has doubled extinction_factor, and halved rayleigh. It's not perfect, but it's as close as I can get the look to the 0.8.22 version with regards to atmosphere. Ignore the sky, that is different anyway, but the way the hills shade with distance is different.
With the ray/extinction values from 22, this foggy haze goes a fairly vivid green about 1hr before sunset in 23.

So I think mie/ray or something there is a bit broken now since 22.

I'm also using an auto exposure gradient of 0.35.


Cheers

Dave

 

[Mr Whippy]

Hmmm, looks like lots was changed in atmosphere.cg,

// Take out a bit of green
RayleighColor.g*=0.8;
RayleighColor.a=0;

That is commented out, explains the greeny skies I'm getting.

And a * 0.9 factor here... I guess this is on the green channel?

float3 v3InvWavelength=float3(5.8,13.5 * 0.9,33.1);



Also, generally, the atmosphere looks thicker further away, but less thick closer, like it's more exponential. This doesn't look as nice in my view, terrains are now losing the feeling of depth at the intermediate ranges. There are some other changes that I don't really get for this, mainly changing things from a single variable to a float (I guess so things can be 'sunny'd? )

To get the horizon looking reasonably light as you would on a relatively clear day, the terrain even 5 miles away looks to almost be no different in clarity to that 5 metres away. The 'depth' of the atmosphere seems to have been lost somewhat.


Testing and tweaking on Carlswood means the impacts of these changes are not seen... Carlswood is small and has no long view distances.


These explain the green then, and the poorer falloff properties of the atmosphere hurting the effect of the depth sensation with distance... but why were they changed? Hmmmmm



Ahhh nice, using atmosphere.cg from 0.8.22 and it's all pretty again. Lighter in the distance, but still misted in the near distance, giving much more sensation of depth of the terrain you are looking over

 

[MitchVL]

The Link does not work Dave

Some cameras have a "focus point", meaning that the all the detail is not always on the foreground, otherwise, some track cams would look like crap.
That is probably related with your issue.