Racer v0.8.22 released!

Ruud

RACER Developer
Yep, it's at http://www.racer.nl/download/racer0.8.22.zip (63Mb).
Known issues:
- Tracked still displays white
- Generic models don't get transformed correctly to their right location

Mostly this version is a lot nicer in the tonemapping/HDR department; I think it's quite good enough to leave as is for v0.9, so it's easier from now on to tweak content for.

Changes:
- Added speed limiter (controlled per car); see http://www.racer.nl/tutorial/engine.htm#speedlimiter
- If the speed limiter is on, the rpm_warning variable will 'flash' between 0 and 1. Useful
for Formula-style cars which indicate it that way.
- Added view var 'speed_limiter' that is 1 if the speed limiter is enabled (default: SPACE key)
- Added rev limiter time per car; see http://www.racer.nl/tutorial/engine.htm#revlimiter
- Added view mapping curve to map input values to output values. This allows for non-linear
dials, such as km/h gauges, commonly seen on lots of cars. See http://www.racer.nl/tutorial/dials.htm
and look for the 'map' variable.
- HDR tonemapping now uses the Uncharted 2 method. See http://www.racer.nl/tutorial/hdr.htm
This looks cleaner (a bit in the GT5 direction). In constants.cg you can add some gamma to increase
contrast (default=1.0).
- Modified auto exposure filter gain from 0.1 to 0.001 (much slower)
- Decoupled dynamic exposure integration from exposure sampling; made it smoother with less sampling.
- dyn_standard_bump_reflect_f.cg had a bug in its fresnel calculation, resulting in funny reflection
factors. Fixed.
- Multiplayer collisions using forces/torques instead of SetPosition(). Newton could get seriously
stuck when doing that (taking >1 second while resolving collisions for a single step).
Still a bit alpha functionality.
- Flares are now rendering using Cg to be able to give them more light. The 'color' property
of a flare should now be in klux, so a value of around 'color=40 40 40' should be better.
- TOD editor can now zoom in with Z key (multiple zoom levels); some curves needed precision at the low end.
- TOD exposure curve improved so things also work without auto-exposure.
- standard_mix*.cg shaders changed to put the most important texture in layer0. This was needed since
projective lighting only uses the first texture to light the scene, and that was a control texture,
giving funny black & white looks when lit. See http://www.racer.nl/reference/gpushader.htm
- Renderer now caches OpenGL's texenvmode for a small performance gain.
- Added 'reload track' console command.
- Added 'sound reverb <n>' console command. Useful in combination with trigger lines to give certain
areas of the track reverb sound. See http://www.racer.nl/reference/scripting.htm
- Carlswood sky improved (thanks to Luthobu)
 
Ruud/Mitch...

Is there any chance the shadow stuff can be moved from Racer.ini to the constants.cg or a shadow.cg file. It'd make tweaking/testing shadow settings in-game easier (reload shaders)

Also it'd make it easier for us to copy/send around different shadow settings having them in one place.

If possible that is... just seems a bit of a pain having them in two places!

Dave
 
Heres another thought about the sound reverb command:

Triggerlines are fine if you never go offroad, but once you do and manage to sneak around them weird results may come up. Driving backwards will also result in unintended stuff, especially for tunnels as when you enter the reverb is reset and if you leave you get the reverb setting which should actually be played upon entering if you drove in the correct direction. (From: http://www.racedepartment.com/racer/39981-hdr-sounds.html#post662005 )

If you make triggerlines two-way aware the problem driving in the wrong direction would be fixed, but not the "evading" problem.
 
Heres another thought about the sound reverb command:

Triggerlines are fine if you never go offroad, but once you do and manage to sneak around them weird results may come up. Driving backwards will also result in unintended stuff, especially for tunnels as when you enter the reverb is reset and if you leave you get the reverb setting which should actually be played upon entering if you drove in the correct direction. (From: http://www.racedepartment.com/racer/39981-hdr-sounds.html#post662005 )

If you make triggerlines two-way aware the problem driving in the wrong direction would be fixed, but not the "evading" problem.

How about a trigger node, so like ambient track sounds, the effect is determined by how close you are to the node?

That way you can have a node for zero effect and a 20m radius of effect before a tunnel entrance, then through the tunnel at say 50m intervals have nodes for the reverb with a 50m radius...

That way we can get the ramping in and out of effects, rather than the on/off issue of triggerlines, AND we avoid any pitfall with ordering of triggerings...

Much more possiblity for creative freedom that way too, ie, we can have small subtle effects all over, like near trees or buildings etc...

Hmmm

Dave
 
Something's changed between 0.8.21 and 0.8.22, I'm getting some kind of drawing errors, see the screenshot.
Also, shadows are weird and the splits do not follow the SMD camera's direction.


I noticed Z problems with v0822 due to problems in the render engine's pipe cache (of the OpenGL state). Fixed in v0.8.23. Also that effect in the shadow is a blend thing; I messed something up in shadowmapping.cg; in the blend there's a *2.0 that was a *5.0. also, Mitch added a dot(normal,lightDir) effect last friday to reduce smCor[] when the light hits a face head on. Makes shadows at fences much better. In fact, it seemed with mapsize=1024 to begin to look stunning. :) v0823 somewhere next week...
 
How about a trigger node, so like ambient track sounds, the effect is determined by how close you are to the node?

That way you can have a node for zero effect and a 20m radius of effect before a tunnel entrance, then through the tunnel at say 50m intervals have nodes for the reverb with a 50m radius...

That way we can get the ramping in and out of effects, rather than the on/off issue of triggerlines, AND we avoid any pitfall with ordering of triggerings...

Much more possiblity for creative freedom that way too, ie, we can have small subtle effects all over, like near trees or buildings etc...

Hmmm

Dave

The Idea is quite nice, but we should be able to choose either radius OR a box shape. This is mainly for things like

http://www.azdot.gov/Highways/Valle...orth/Images/I-17-Overhang-at-Loop-101-009.jpg

The Box shape is pretty much to avoid getting an effect due to the radius cutting into the track above (could happen in some special cases).

Another point is, is it desired that the "in-tunnel" nodes have the fade effect as you approach and leave the radius of one triggerline? That would either mean you need to place a lot of triggerlines next to each other to negate the changes as much as possible or we need a checkbox which prevents any changes based on distance to the triggerline.
 
I'm not sure on the actual solution, just it's best to use a node, however we define it (perhaps a volume mesh!?) and then give it properties, ie, reverb 25%, falloff 25m etc?!

I'm not sure, but triggerlines look liable to going wrong, and are not really logical. Reverb in real life is dictated by environment and those are spatial... using a line as a trigger for a spacial effect just feels a bad idea :D

Dave
 
you can script something like that

Code:
rcar $car = get local rcar
float[3] $dist
float $distLen

function float ClampAboveZero(float $val)
{
  if $val < 0.0
   {
    $val=0
   }
  return $val
}

while 1 // loop infinitely
{
  $dist=get $car pos
  // subtract hardcoded position 
  $dist-= float[3]{100,100,100}
  // distance from 
  $distLen=sqrt($dist.x*$dist.x+$dist.y*$dist.y+$dist.z*$dist.z)
 
  // most reverb when close, start fading in from 20 meters, then normalize to 1
  $dist = ClampAboveZero(20-$dist)*0.05
  
  send ("reverb " + $dist) to console

  interrupt
}
script is untested and will most likely not work ;)
 
Still working on getting tod curves set right, original quite good for carlswood but bad for other tracks.

Also noted that on my Surfaces and Sounds track, as well as others, adjusting tod curve with edit tod causes trees and other transparent objects to flash on/off! This really needs fixing for the next version.

I lowered the first split variable in constants.cg from 0.00007 to 0.00001 and set the gamma to 1.5. Then set autoexposure off and blur=0 to get the best I've seen yet, blur=1 to blur=0 had fps go from 120 to 180.

Please, Mitch or Ruud fix the mirror flicker as mirrors are no longer useable!
 
Blurring really doesn't work so nice right now. Slow and it looks worse than no blurring, imo.

Autoexposure off though, what happens when you drive into the sun vs out of the sun on a sunset track? :D Blinded or too dark ;) :D

Dave
 
The TOD curves are a pain.

Hopefully more will be automated in future, but for now it's better this way.

Ie, I'd like to see the intensities/colours for the ambient/diffuse curves populated from the calculated intensities/colours in-sim... which are driven by the mie/ray mainly...

Sun intensity value seems to be the main one that is hard to get right.

I also feel day/night is a weird one to get right... it's basically turning the night time sky on and off (texture), but surely night is just a result of no sun intensity or sun diffuse? Should the night time merely be the absence of sun intensity and diffuse, not a thing that is turned on and off?

I'd prefer to see a realtime night sky drawn like the day time one. All my skies seem to have terrible colour banding etc due to the texture being so dark. Ie, black > dark blue is about 20 levels of intensity... yuck.

Hmmmmm.
 
What I'd really like to see (besides enhanced physics) is support for variable road profiles. Forgive me if my assumption is off, but with the current system of splining the road surface, it is as though it is perfectly planar from shoulder to shoulder (or curb to curb if you prefer). That is hardly the case on highspeed racetracks, let alone public roads made for optimal drainage. Of course, if the physics engine isn't built to handle this kind of stuff, then it's probably not worth thinking about it...
 
You can profile with the mesh instead, which is preferred these days anyway.

However, the splines need to be set to allow you to drive on the mesh surface, but still be used for resets, cameras and the map.

use_mesh_hits is used to achieve that (however I seem to be struggling with it right now)


Dave
 
Ewertyime, when i'm trying to select a car, racer freezes, and:

aaaanw.jpg
 
Erm, Cosmo spotted an issue in the latest version, we did some testing and I'm pretty certain he is right.

grip_decline_driveline feature seems to be active and messing all surfaces up.

Cosmo tested 18 and 22 and the difference was very noticeable in FF steering feel and limit behaviour, so he went through and the change happened when grip_decline_driveline was added in the changelog notes (yay, accurate changelog yields bug finding result :D )


So we added grip_decline_driveline=0 to our surfaces thus, and suddenly found we were not falling off the track half as much as we were in yesterdays driving exercised :D

surfaces
{
surf_road
{
grip_decline_driveline=0
type=road
subtype=0
grip_factor=0.9
rolling_resistance_factor=1.0
road_noise=0.04
road_noise_frequency=0.4 2.0
road_noise_amplitude=1.0 0.2
road_noise_threshold=0 0
steer_noise=0
pattern=road
}


Of course, it's NYI properly, but it needs setting to 0 to remove the negative issues it is having now!


Dave
 
Alllssooo, while I am here.

There used to be a few good scripts in the old Racer releases.

glong glat, one to watch the vertical wheel position to see the road bumps you were setting up etc. Where have they gone? They were massively useful to have there. Any reason for the removal.

Leading on to the issue that, last time I could check, road_noise_threshold didn't work, not truncating the road noise to this value (ie, not flatting off the peaks of the noise trace from the wheel sensing the bumps)


Leading on to one final thing, load_filter_frequency

Is this implemented yet? In my view we would be better using a logic system based on a variable we input into the car.ini
Tyre pressure vs tyre width (already in) vs tyre rolling circumferance (already in), gives us the contact patch size, then use that as a guide to what bumps might be felt...
Filtering frequency is an issue because big bumps that you would feel at all speeds, might be filtered out with a frequency based system.


Hmmmmmmm
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top