Racer v0.8.21 out!

Ruud

RACER Developer
It's been a while. Enough bugs still that need to be squased but let's not keep things too long.
v0.8.21 is at http://www.racer.nl/download/racer0.8.21.zip (63Mb).
The Blackbox DLL isn't used anymore -now I'm using VLD (Visual Leak Detector), which gave a few important memory leaks.

Known issues:
- Tracked displays Carlswood badly (white); something with the klux lighting

The changes from v0.8.20:
- Added improved process control for physics.async=1; the original process.cpu_affinity_mask now controls
the entire process (all threads). 'process.main_thread_affinity_mask' was added to control the main
thread cores. Additional, when physics.async=1, physics.thread_affinity_mask then controls
the cores on which the physics thread may run.
- 'cache_geodes' didn't work well when cars used data.ar to store .dof models. Common names like 'body.dof'
would conflict and different cars could use the same 3D models.
- Shadowmapping splits are now blended to make smoother transitions
- Shadowmapping per-split filtering can be turned on/off using renderer.shadowmapping.blur (0/1)
- renderer.auto_exposure.filter_gain was read incorrectly and thus had no effect (defaulting to 0.05). Fixed.
- Added wheel<n>.tire_damping_lowspeed and tire_damping_threshold for car.ini. Tires physically stiffen
up when rotating, but at low speed they get a lot of damping. Real life values arond 5.0 for the threshold
velocity and 2500.0 for tire_damping_lowspeed. See also http://racer.nl/reference/wheels.htm#tireforces
- dev.log_last now set to 0 by default since many people will not know what to do with QLOG anyway.
For content developers 1 is highly recommended.
- Removed the 'can't create envmap' error message on some DOF files - it isn't useful anymore.
- Switched Newton from v2.22 to v2.24. Small objects seem to have difficulty when colliding with cars.
- Modified dyn_standard_bump_speca_f.cg to accept 'scale' float parameter. This scales the normal map's
texture coordinates.
- Some large memory leaks fixed inbetween races.
- Renderer could crash in certain mixes of static geometry and custom geometry (particles/skidmarks etc)
- Ini keys with a dot (.) are found and warned about in QLOG. Some cars (F458 test version) had 'fresnel.bias'
defined directly in the ini file, which won't work (use fresnel { bias=xxx } ).
- View dials now have Cg shaders - data/renderer/shaders/viewelt_*.cg. Needed for klux lighting to avoid
very dark dials.
- Added bounce_amount and bounce_alpha properties for shaders to allow for lighting to not mix with the
alpha channel (Carlswood's road incorrectly reflected light; not enough light was reflected/bounced).
See also http://www.racer.nl/reference/shadereng.htm#matglobal
- Added surface 'grip_decline_driveline' property to allow grip to decrease when you go off the driveline.
Needs more work though.
- mirrors.texture.lod_factor set to 1.0 to avoid quickly disappearing geometry in the mirror
 
ProcessShadow does the local blurring, GetShadowFactor & DoShadowFactorBlend do the blending between maps.

In ProcessShadow,
The first bit (smSplits) is just selecting the right shadowmap coordinates, as they're all rendered into one texture in different quarters.
Then using iSqrtSamples as a limit, it gets the shadow "height" for each pixel out to a radius defined by that variable. Right now it just averages those samples out to give the "height" of the shadow.

Blending between the shadowmaps is more complicated, I don't know how to explain.
 
I'm having trouble with dyn_standard_bump_reflect_*.cg,

At some viewing angles reflection goes to 100% where it shouldn't.

The shader in question (body texture, the glass is separate and works fine) has reflect=0.5, tangents=1.
rx7refl.jpg



I'm also having trouble with flares - color values above 1.0 don't work so they're extremely dim. I guess it needs a klux value of brightness to go with the new system but I'm not really sure what shader it's even using.

Trying out the Baja, generic models seem completely broken? They're all being drawn at the centre of the vehicle.

There is indeed a world coordinates vs texture coordinates problem in dyn_standard_bump_reflect_f.cg. Change this line:

float fresnel=Fresnel(fresnelBias,fresnelScale, fresnelPower,normalize(I),N);

into

float fresnel=Fresnel(fresnelBias,fresnelScale, fresnelPower,normalize(I),normal);

As for the flares; they still need a Cg shader to indeed increase their lighting. For the Baja, I'll check it out...
 
I'd like to be able to define a blur amount on the reflection map per material. Maybe have only 4 steps, so sharp, medium, soft, and very soft (ie 16x16px mipmap at softest)

Would be nice for many track-based object then... like the road etc... specular from diffuse light source only these days just doesn't really cut it next to proper diffuse reflection (which NFS HP seems to use on the roads!)

Dave
 
Another request I have is (if possible) to be able define a material as a collision object. for use in objects like trees where u want the trunk to be a collision object, ut not the foliage. Or am I just better to have them as two seperate objects (one tree as trunk.dof with collision & foliage.dof no collision)?
(On top of my previous requests for gravity & air density to have special.ini overrides over the racer.ini ones)
 
Boomer , that may work, as I only use Cg on the foliage anyway. The Cg needs the foliage to be seperate objects so they each have a meaningful centrepoint, but the trunks don't, so them as one (or a few) objects might be the way to go. Just have to be careful they all aligned.

Ruud, is there any way to make Cg scripts in the data/track/track, or better data/track/cg folder, include the include files easily? Currently, it's easier to just copy my CG's into the shader folder, but I'm asking for trouble if I release a track expecting everyone to do that. If this little issue's resolvable, i'll release a WIP beta of my Cg'd Mugello, my 2nd favorite driving track, give everyone something decent looking to take screenies in. And even drive for the daring...

[edit] I could release Cg updates for Broken Springs as well [/edit]
 
@DavidI: You can add CG scripts to a data/track/cg/ folder, just call it as
cg/myshader.cg in the shader (I have done this with cars and tracks):

Code:
vf_myshader
{
    vertex_shader
    {
        file=cg/myshader_v.cg
    }
    fragment_shader
    {
        file=cg/myshader_f.cg
    }
}
 
But don't they get upset that atmosphere.cg etc aren't there? They do for me. I can copy the includes from the shader folder, or custom cg's to the shader folder, but thats my point.
 
But don't they get upset that atmosphere.cg etc aren't there? They do for me. I can copy the includes from the shader folder, or custom cg's to the shader folder, but thats my point.

I would vote against using custom Cg shaders in tracks and cars. The Cg shaders are very low level application specific shaders and should be provided by the application for the users to use. Yes, they are powerful and custom effects, but they might also change over time as Racer is developed and then we are back in square one, where all the content needs updating again.
 
Lol dejavue;
Standard shaders are fine, but I beleive we should have the flexibility also of custom shaders per track or car. eg Gravedigger needs a rotating radiator fan, its exposed in full view from the rear, it looks like an airfix model with a stationary one, but does there need to be a standard_spin_object_v.cg, as its more a custom thing that GD needs and not many other cars need it.
Same for my Carnage track, it is meant to be an alien world, so manipulating the Cg's to change atmosphere etc is something I'd like the flexibilty to do, but then nothing else would probably ever need these customisations, so I see a need for custom Cg's in some cases. Not everything, but sometimes.
 
but does there need to be a standard_spin_object_v.cg, as its more a custom thing that GD needs and not many other cars need it.

As long as it's generalized enough that some of the values are coming from the shader, eg. axis of rotation, centre of rotation, and speed, it could see track applications - eg. spinning windmills in the scenery.

I think that sort of thing would benefit from a generic structure in the shaders as well, eg.
Code:
generic
{
  # axis of rotation defined in 3 dims as normal to the plane of rotation
  var1
  {
    length=3
    value=1.0 0.0 0.0
  }
  # speed of rotation, revolutions per minute
  var2
  {
    length=1
    value=38.0
  }
}
Then in the shader, just toss in the extra variables at the end
Code:
  uniform float3    var1,
  uniform float    var2
This or somehow generalize animated shaders to the point one function fits all, with the right parameters tossed in.
 
As long as it's generalized enough that some of the values are coming from the shader, eg. axis of rotation, centre of rotation, and speed, it could see track applications - eg. spinning windmills in the scenery.

Ideally, apart from complex geometry animations like flags, water, you shouldn't need shaders for object animations (like rotating objects etc),
 
I've already tweaked the flag shader to make wavy grass... the scale value works nicely too for different length grasses.

Longer term it'd be cool to have a global track value like cloud/rain/snow, called 'wind' which then scaled the 'scale' value for flags, grass, trees etc... mmmmm.

Generally though, I agree that shaders should shade, and real transforms (windmills going round), should be done via some basic code in the geometry.ini somewhere. Perhaps a multi-input variable.

move = action.axis.rate

So maybe rotate.z.10

spin at 10 rad per minute in z axis...

Hmmm... should do for most 'things'

Dave
 
Yes ideally, but in reality
a) it works and gives us huge flexibility
b) Ruud has to add nothing more than he has to give us that power & flexibilty.

We could wait a looong time to get spin controls in code, in fact I'm happy for that to be the last thing he looks at, there are far more important things to be done. With Cg I can do it now, and not bother Ruud (much) to do it.

We could do with some more custom variables we can feed thru to shaders, vara varb varc or similar. I use scale as a variable currently, but another one or two would be great.

One more request, could we get some of the standard shaders written into world coordinates? standard_detail, standard_bump_detail & standard_bump would be handy additions. Also is standard_bump_detail up-to-date? And could it have scale added to it please?
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 290 15.4%
  • < 2 years

    Votes: 195 10.4%
  • < 3 years

    Votes: 195 10.4%
  • < 4 years

    Votes: 141 7.5%
  • < 5 years

    Votes: 251 13.3%
  • < 10 years

    Votes: 223 11.8%
  • < 15 years

    Votes: 141 7.5%
  • < 20 years

    Votes: 114 6.1%
  • < 25 years

    Votes: 85 4.5%
  • Ok, I am a dinosaur

    Votes: 247 13.1%
Back
Top