Updating Content for 0.9.0 Final

There seems to be a demand for this kind of thing, so here you go. Thread's a work in progress and all that.

Broadly there are two types of content that need to be updated. Cars and tracks. These share some features in common - shaders, textures, dofs are all similar. Both dump errors into the QLOG.txt. They also have some unique features - the .ini files controlling them are quite different, though they follow the same structure. I'll start by covering the shared features, then move to car and track specific updates.

Racer.nl does, of course, have documentation - so where possible I'll link to the relevant pages. A lot of it supposes you're creating new content, though, or already understand how everything works. This thread will be more limited in scope, focusing on content that already works in an older version, and making it work better in new ones.

If I'm missing a step, or you know an easier way to do anything, I'd be glad to add that.

Table of Contents
  1. Car & Track Common Files
    1. .dof Files
    2. Textures
    3. Shaders
      1. Vertex & Fragment Shaders
      2. Material Shaders
      3. Pre-tweaked Shaders
  2. Car Specific Files
    1. views.ini
    2. torque.crv
    3. car.ini
  3. Track Specific Files
    1. spline.ini
    2. track.ini
    3. ai/
    4. tod/
    5. geometry.ini, movables001.ini
    6. special.ini
  4. QLOG.txt Errors
0. Introduction
So let's get started.

First things first: File formats.
.ini, .crv and .shd are text formats. Open them in your text editor of choice - I can recommend NotePad++.
- these follow a standard structure of nested brackets. Comments are preceded by semicolon ; like this.
.dof is a 3d object format. Modeler.exe, which comes with Racer, can open them.
.ar contains protected 3d objects. Normal users have no way to retrieve them, but Racer can still read them.
.tga, .dds, .bmp, .jpg are image formats. Photoshop, GIMP, etc. should be able to open them. You'll probably need to search for plugins in order to handle .dds (insert links here).
.wav and .mp3 are audio formats. Audacity is a decent free audio editor, though you probably won't need to edit these.

Next, what are you working with? Open up car.ini or track.ini. Near the head, you'll see version=. Some update tips may be more relevant to particular versions - very old ones (05b) may not even come with shaders. If you have a question, this piece of information can be invaluable in getting useful advice. If the car comes with a readme.txt, it'll most likely contain some useful information, such as author contact info. It may be worth contacting them to see if they or someone else is already working on updating the content - that'll save time.


1. Car/Track Common Files
This section applies approximately equally to both cars and tracks.
- .dof files
- textures
- shaders
1.1 .dof Files
Unlikely to be a problem.
Some will have QLOG errors telling you the model has problems. If so, copy the relevant dofs, along with dof_fix.exe, cg.dll, cgGL.dll (from the main Racer folder) into a seperate folder. I'd suggest C:\_DOF\. Open up a command prompt (Start -> Run cmd.exe) and change directory (cd) where you want to go. For example, if you put them in C:\_DOF, you would write cd C:\_DOF in the command line. Once there, you just input dof_fix filename.dof, and it will fix the problem for you.

You can also view .dof files by running Racer/modeler.exe. Once open, you can check the appearance of the object, as well as the materials it uses - use PgUp/PgDn to switch between materials and you can see their names, as well as having them highlighted on the model. The material tab will let you adjust some values, but the only useful one is the material name.

1.2 Textures
May be a problem.
The main issue here will be alpha transparency. In old versions of Racer, it was possible to reverse the alpha channel. This is no longer the case. If transparency appears backwards ingame (solid where it should be clear, clear where it should be solid) this is likely the cause. If it is a problem, open up the texture in your image editor, and invert the alpha channel (likely to be called something like Colors > Invert).

1.3 Shaders
Always a problem.
Old shaders simply use a visually similar, but incompatible format. This is the reason old content uniformly looks wrong when you load it up.
See:
Old shader documentation on Racer.nl.
New shader documentation on racer.nl.

For a quick conversion, you can just replace each shader with its modern equivalent. This is what I'll focus on - what the old shader looks like, what the new one looks like.

Shaders share more values between materials now, so a common simplification is to write the fragment and vertex shaders (yes, this terminology is confused - they are a different kind of shader) into the top of the material shader. To facilitate the transition, I'll include the most commonly used ones here with a brief description of what each looks like. After that, I'll show a 1:1 correspondence between old shader and new shader, referring back to the common values.

1.3.1 Vertex & Fragment Shaders
These vary slightly between car and track materials, but the difference is simple: An object that can move, such as a car, uses the dyn_ prefix on a vertex/fragment shader (if it exists). An object that can't move, such as the terrain, does not have the dyn_ prefix. I will write these assuming all models can move - you can delete this feature from track materials, creating slightly more efficient versions.

You can include all of these at the top of your .shd file, or limit it to the ones you use. These will be referred to by individual material shaders, and will let you tweak the way groups of materials look at the same time.
Code:
vf_dyn_standard
{
  vertex_shader
  {
    file=dyn_standard_v.cg
  }
  fragment_shader
  {
    file=standard_f.cg
  }
}
This is the basic vehicle shader. Apply this to every material, and it will all be lit correctly, but have nothing fancy - no reflections, no bumpmapping, no transparency. This is the minimum you want every material to have on a car.

Code:
vf_standard
{
  vertex_shader
  {
    file=standard_v.cg
  }
  fragment_shader
  {
    file=standard_f.cg
  }
}
Track version of above - dyn_ is removed. This is the simplest shader, period. You can remove dyn_ from other shaders, too - just check that data\renderer\shaders contains the .cg files you refer to.

Code:
vf_dyn_reflect
{
  ; Just reflection
  vertex_shader
  {
    file=dyn_standard_reflect_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_f.cg
  }
}
This adds reflections to the material. If you leave it at this, default settings for Fresnel will be used - the Fresnel curve is the way the material reflects depending on the angle you look at it. The primary texture's alpha channel is used to determine reflectivity - this maintains compatibility with most old cars, but you may have to invert the channel (as discussed above).

Code:
vf_dyn_reflect_window
{
  vertex_shader
  {
    file=dyn_standard_reflect_window_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_window_f.cg
  }
}
A reflective transparent material, such as glass. The primary texture's alpha channel is used to determine transparency. Again, you may need to invert the texture's alpha channel to make it appear correctly.

Code:
vf_dyn_bump
{
  tangents=1
  vertex_shader
  {
    file=dyn_standard_bump_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_bump_f.cg
  }
}
Bump mapped using a second texture to indicate the texture normals. Also available in combination (eg. dyn_standard_bump_reflect) with other shaders - see references.


1.3.2 Material Shaders
The second half of each shader is the part you need to update: the material sections. Most cars will already have this - each material is described as a section that looks like:
Code:
shader_[COLOR=red]material[/COLOR]
{
  ...
}
Material will be the name - frequently the same as the texture, eg. body.
To update these, you want to transfer the old settings to a new shader that performs the same function. To this end, I'll try to provide a comprehensive list of shaders. If something's not here, ask about it in the thread.

First up, the basic matte material shader.
Code:
shader_[COLOR=green]grass[/COLOR]
{
  cull=back
  layer0
    {
        map=[COLOR=green]grass.tga[/COLOR]
    }
}
Becomes...
Code:
shader_[COLOR=green]grass[/COLOR]~vf_dyn_standard
{
  cull=back
  layer0
    {
        map=[COLOR=green]grass.tga[/COLOR]
    }
}
Green indicates values that will vary by material, but don't need to be updated. You want to look at the structure outside that to figure out what the material does, then edit it to update. In this case the change is straightforward, add vf_dyn_standard. If this is a track material, you could just use vf_standard.

The reflective car shader. Ubiquitous, and made much easier by the new system.
Code:
shader_[COLOR=green]body[/COLOR]
{
 layer0
 {
  map=fresnel.tga
  texgen_s=sphere_map
  texgen_t=sphere_map
  emission=1 1 1 1
  mipmap=0
 }
 layer1
 {
  map=[COLOR=green]$trackenvmap[/COLOR]
  texgen_s=reflection_map
  texgen_t=reflection_map
  texgen_r=reflection_map
  blendfunc=filter
  shininess=[COLOR=green]24[/COLOR]
  specular=[COLOR=orange]0.75 0.75 0.75[/COLOR]
 }
 layer2
 {
  map=[COLOR=green]body.tga[/COLOR]
  blendfunc=one src_alpha
  mipmap=0
 }
}
Or
Code:
shader_[COLOR=green]body[/COLOR]
{

layer0
{
 map=[COLOR=green]body.tga[/COLOR]
 mipmap=0
 shininess=[COLOR=green]24[/COLOR]
 specular=[COLOR=orange]0.75 0.75 0.75[/COLOR]
 emission= [COLOR=red].07 .07 .07[/COLOR]
}
layer1
{
 map=[COLOR=green]$trackenvmap[/COLOR]
 texgen_s=reflection_map
 texgen_t=reflection_map
 texgen_r=reflection_map
 blendfunc=one_minus_dst_alpha one
} 
}
Becomes...
Code:
shader_[COLOR=green]body[/COLOR]~vf_dyn_reflect
{
  shininess=[COLOR=green]24[/COLOR]
  specular=[COLOR=orange]0.75 0.75 0.75[/COLOR]
  layer0
  {
    map=[COLOR=green]body.tga[/COLOR]
  }
  layer1
  {
    map=[COLOR=green]$trackenvmap[/COLOR]
  }
}
This is the type of shader most cars will use for the main body texture - reflective, possibly with a fresnel map (first example uses one, second doesn't). I've added a couple more colours here - orange indicates values that may need to be changed, while red indicates values that are definitely out of place. In this case, the specular= value is most likely too high - the newer renderer makes specular bright relative to the sun, which has gotten way brighter. The emission= value was used fairly often in old versions to brighten up cars - it should only be used on materials that actually glow now, and in most cases should be removed. The texture map in the layer0 is the texture map, body.tga, while layer1 contains the reflection map. You can see that in the old fresnel example, the textures appear in a different order.

The transparent glass shader. Tricky to get right, because you have to correctly mix layers together and render them in the right order.
Code:
shader_[COLOR=green]glass[/COLOR]
{
 layer0
 {
  map=glass.tga
  depthwrite=0 
  shininess=128
  blendfunc=src_color one_minus_src_alpha 
  mipmap=0
 }
 layer1
 {
  map=[color=green]$trackenvmap
  depthwrite=0 
  texgen_s=reflection_map
  texgen_t=reflection_map
  texgen_r=reflection_map
  blendfunc=src_alpha one_minus_src_color
 }
 layer2
 {
  map=[COLOR=green]glass.tga[/COLOR]
  shininess=[COLOR=green]40[/COLOR]
  specular=[COLOR=orange]1 1 1[/COLOR]
  depthwrite=0 
  blendfunc=[COLOR=red]src_color one_minus_src_alpha [/COLOR]
  mipmap=[COLOR=green]0[/COLOR]
 }
}
Becomes...
Code:
shader_[COLOR=green]glass[/COLOR]~vf_dyn_reflect_window
{
  sort_offset=1
  reflect=1.0
  shininess=[COLOR=green]40[/COLOR]
  specular=[COLOR=orange]1 1 1[/COLOR]
  layer0
  {
    map=[COLOR=green]glass.tga[/COLOR]
    blendfunc=[COLOR=blue]blend[/COLOR]
  }
  layer1
  {
    map=[COLOR=green]$trackenvmap[/COLOR]
  }
  [COLOR=blue]fresnel
  {
    bias=0.04
    scale=0.96
    power=4.0
  }[/COLOR]
Another colour introduction: blue means values that can be tweaked to personal preference, but are new with the new system. I will try to include reasonable values for these, but a particular situation may need particular changes. Instead of blendfunc=blend, you may want to try blendfunc=dst_alpha one_minus_src_alpha. This will most likely work best with more transparent windows.
For the fresnel section, Cosmo° recommended
Code:
        bias=0.04
        scale=1.0
        power=2.0
These are not massively different, but you can get an idea of what tweaks to try.

1.3.3 Pre-tweaked Shaders
The previously materials cover the majority of what you're going to need, if you just want to transfer old settings over. If the car doesn't come with shaders, you're unsatisfied with how they look, or you're just confused by the settings, there is an alternative. You can choose to use shaders already tweaked to look good. Here are some of those.
Code:
vf_dyn_gloss_paint
{  
  vertex_shader
  {
    file=dyn_standard_reflect_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_f.cg
  }
  fresnel
  {
    bias=0.05
    scale=0.95
    power=3.0
  }
  reflect=1.0
  specular=0.1 0.1 0.1
  ambient=1 1 1
  diffuse=1 1 1
  shininess=16
}
A nice glossy paint. Suitable for general usage. Materials will look like:
Code:
shader_[COLOR=green]material[/COLOR]~vf_dyn_gloss_paint
{
  compression=0
  layer0
  {
    map=[COLOR=green]texture.tga[/COLOR]
  }
  layer1
  {
    map=$trackenvmap
  }
}
This is quite simple on the material end of things, because many values are copied from vf_dyn_gloss_paint. So you can just use that shortcut to save having to write stuff out every time.

2. Car Specific Files
2.1 views.ini
Unlikely to be a problem.
2.2 torque.crv
Unlikely to be a problem.
2.3 car.ini
Usually a problem.
See Cosmo°'s post for now.
3. Track Specific Files
3.1 spline.ini
Unlikely to be a problem.
3.2 track.ini
Will need minor updates.
3.3 ai/
Unlikely to be a problem.
3.4 tod/
Entirely new.
3.5 geometry.ini, movables001.ini
Will need minor updates.
3.6 special.ini
Always a problem.
4. QLOG.txt Errors
Likely to be arranged in alphabetical order, or by subject. The final step before sharing your work.

Will continue to add info, sleeping and such for now. Looking for suggestions on organization, formatting, etc. early on so I don't have to change much. Thanks!
 
Thanks a lot for putting this up Stereo :) I find your post well organized and it seems to cover pretty much all the basics on the shader topic so far. Perhaps it would be useful to add one sample material tree for the bump and reflect_window shaders each, since they require some additional lines.

Example for typical tyre bumpmapping, mandatory are tangents and mode settings, whereas shininess and specular are just for added effect:

Code:
shader_material~vf_dyn_bump
{
	compression=0
	shininess=16
	specular=0.10 0.10 0.10 1.00
	tangents=1
	layer0
	{
		map=texture_diffuse.tga
	}
	layer1
	{
		map=texture_bump.tga
		mode=linear
	}
}

Standard window glass:

Code:
shader_material~vf_dyn_reflect_window
{
	compression=0
	reflect=1.0
	fresnel
	{
		bias=0.04
		power=2.0
		scale=1.0
	}
	layer0
	{
		map=texture.tga
		blendfunc=blend
	}
	layer1
	{
		map=$trackenvmap
	}
}

I'm not entirely sure about the fresnel.scale settings. There seem to be contradicting statements in the sample code, documentation and the web as a whole. So, slightly offtopic perhaps:
From my understanding, bias gives the strength of the reflection at 90° to the object surface (looking straight at a piece of paper), while scale gives the strength at 0° (somehow looking just over the thin edge of a paper sheet). Power represents the interpolation exponent between the two.
I'm calculating the bias setting based on the refractive index of the material in question (bias=[(N_air-N_material)/(N_air+N_material)]^2; where in the above example N_air=1.0 and N_glass=1.5), but whether bias+scale always has to be exactly 1.0, can maximally be 1.0, or whether scale should actually be 1.0 all the time and bias is material specifically "arbitrary"... would be nice to know for sure.



Racer also supports .mp3 audio files, though it's not the preferred format for sure.
 
Not sure exactly which order they go in, but the fresnel coefficients are best seen as 0deg incidence angle to 90deg incidence angle and the exponent of the falloff between the two values set.

So larger scale pushes the value you set for 90deg incidence further to the edge. I *think* a scale of 0, or maybe 1, might mean a linear movement between the 0deg and 90deg values with the 0-90deg incidence angle, and as your scale value goes up, it becomes more heavily weighted for to the 0deg incidence value for longer.

Or something like that. Really easy to see the fresnel output by putting rgb.out = fresnel or whatever it was again, and then you can visualise the map in greyscale on a sphere or whatever...

Dave
 
Thanks for starting this, I've already learnt a few things. It's very well wrote and the organization/formating looks good too. If you lived in the UK I'd be sending you lots of cookies!
 
I believe if bias+scale > 1.0, it'll just truncate any larger values and still return something between 0 and 1. So you basically hit 1.0 - total reflectance - at somewhere less than 90 degrees. This only really happens moving from a slower to a faster medium, eg. if you're underwater and look at the water-air transition, you get total reflectance at about 60 degrees?

Because window glass goes air->glass->air, through approximately parallel interfaces, you never get total reflectance on the glass->air - it only makes it into the glass at angles under critical. If you have a glass sphere or something, or a glass of water, it's a lot easier to get it on the curved inner surfaces. Diamonds have really high IoR so they reflect internally all over the place.

I'm going to add examples of material shaders when I get another chance to edit - what the old looks like, what the new looks like (so you don't have to understand either - just identify the pattern, copy texture/material names and some values across). If you can post up what the pre-CG bump shader looked like that'd be a big help, I'm having to grab them from old cars and the Racer.nl tutorial.

On the subject of bump shaders, tangents=1 should probably go in vf_bump of any kind. It's always necessary, should be in common values. I'll toss that in when I edit, too, figure this is a good time to think about best practices for each kind of shader.

Is it worth discussing the domain of 'realistic' values on ambient/diffuse/specular/reflection? If you max them all out (and set bias to 1), you get a material that just cannot happen purely due to reflection of incoming light. It needs some sort of internal source of extra light, which should more properly be an emission value. Same with glass... if it's reflecting at 50%, it can't pass through more than 50% of what's behind it, or the numbers don't add up.

fresnel values: Perpendicular to the surface is 0 (angle of incidence 0), parallel to it is 1 (angle of incidence 90).
bias - base reflectivity at 0.
scale - amount reflectivity increases as you move to 1.
power - exponential curve used.
If you use the variable f to refer to the fresnel value (0 to 1), then the equation used is
bias + scale * (f^power)
As you can see, at f=0, fresnel=bias. At f=1, fresnel=bias+scale. In between it depends on the exponent to create a curve.
For a linear transition, you'd have power=1. Most materials will use a higher power in the 2-4 range. For something with a constant reflectivity, set bias=1, scale=0. This, combined with reflectivity=1.0, will give you a perfect mirror.
I did some work in Excel to fit best values for glass - I'll try to pull those up. As long as you're close to bias=0.1, scale=0.9, power=4.0, it isn't that important though.

EDIT: Added to the Material Shader section. Added index. Goodnight. :p
 
Thanks for that explanation - I originally thought the base of the exponential function was indicating the angle, so the capping didn't occur to me. Making sense now though :)

Giving some hints on realistic value ranges is a good idea, but I think that one or two sentences - like what you posted above - is enough for this particular FAQ. Otherwise it ends up being more of a setup guide in general. Especially when it comes to special.ini and car.ini settings it can be a bottomless pit, requiring more background information to make sensible choices anyway.
 
Same with glass... if it's reflecting at 50%, it can't pass through more than 50% of what's behind it, or the numbers don't add up.

Getting into refraction a bit there maybe? Lensing of light?

The sum of light can end up being whatever it needs to be at any given point. Has anyone modelled an actual parabolic reflector in Racer to see if you can capture the sun light over a large area and have it all match the sun intensity level?!

Right now I'm using 0.04 0.97 ish kinda values which feel about right for car paints etc... diffuse/spec are ok at 1 assuming the control textures use real numbers, or vice versa, use 0-255 rgb values in the maps, but then trim the diffuse/ambient values appropriately (ie, deepest black is maybe 0.03, brightest white maybe 0.9 ish... apparently some yellows are the colours with highest reflectance?!


All gets a bit complicated in our rationalised lighting/material world :D

I just say as long as diffuse behaviour is about right, and the reflected world is in the right kinda magnitude of kLux, same with ambient/diffuse sun/sky special.ini values that match the environment they 'come' from, then you are generally gonna end up ok :D


Toughest one to get right, that someone did a while back, was the light lensing shader for headlights and tail lights, which I used on the Lambo... makes those emission materials work much more as you'd expect (lights that project)


Hmmmm

Dave
 
Thought I'd add to the next section, since I'm quite familiar with that.



2.3 car.ini

car.ini deals with all the parameters that define the physical representation of the vehicle. Over the years, new features have been added, some have changed in meaning and some have become obsolete.

Since Racer uses a fallback system that looks up missing parameters in the default/car.ini file, the only truely mandatory change is the version number found at the top of the file.

If you set both "note_ini_fallback=1" and "note_ini_unused=1" in racer.ini.dev, at the bottom of the file, Qlog.txt will list all the missing and obsolete parameters for you to work through. Depending on the age and thoroughness of the original work, there can be quite a lot of messages.

Since racer.nl's documentation already explains every available paramter, I'll be focusing on those changes where new parameters significantly enhance the model, or have changed meaning from before.



2.3.1 Version number

Let's start out with the car section, comparing an old file to it's updated counterpart:

Code:
car
{
    name=Chevrolet Camaro Z/28
    year=1969
    credits=Model & Textures: Cube396 & BigBlock; Racer Adaption: LB, Some1, Outlaw & Cosmo°
    comments=v1.1
    id=69_camaro_z28
    [COLOR=red]version=050f[/COLOR]
    wheels=4
    [COLOR=red]skid
    {
        sample=skid.wav
    }[/COLOR]
    shadow
    {
        texture=shadow.tga
        width=1.836
        length=4.686
        offset_z=0
        intensity_dark=0.75
        intensity_light=0.25
    }
    cg
    {
        x=0
        y=-0.254
        z=0.2552
    }
}

New:

Code:
car
{
    name=Chevrolet Camaro Z/28
    year=1969
    credits=Model & Textures: Cube396 & BigBlock; Racer Adaption: LB, Some1, Outlaw & Cosmo°
    comments=v6.11
    id=69_camaro_z28
    [COLOR=red]version=090[/COLOR]
    wheels=4
    shadow
    {
        texture=shadow.tga
        width=1.836
        length=4.686
        offset_z=0
        intensity_dark=0.75
        intensity_light=0.25
    }
    cg
    {
        x=0
        y=-0.254
        z=0.2552
    }
    [COLOR=blue]ff_factor=0.40
    ff_gain=1.00
    ff_damping=0.00
    ff_friction=0.00
    ff_inertia=0.20
    ff_stickfriction=0.50[/COLOR]
}


Most importantly, the version tag has to be 090 or else Racer will quit with an error message while attempting to load the vehicle.

All audio information now resides within the main audio tree - formerly, skid and engine sounds were listed separately.

The section in blue includes new force feedback parameters that are missing from almost every release. Racer uses default settings that are quite strong and obviously generic. If you want to retain the original feedback characteristics, set ff_gain=0, as this factors in with the four following parameters and then leaves only the pure tyre forces (which are controlled in magnitude by ff_factor).



2.3.2 Differentials

While the following old syntax for the differential section is still working, the newer version is preferred:

Code:
  [COLOR=orange]differential[/COLOR]
{
    [COLOR=orange]type=1[/COLOR]
    ratio=3.73
    inertia=0.1
    [COLOR=orange]locking_coeff=90[/COLOR]
}

New:

Code:
  [COLOR=orange]differentials[/COLOR]
{
    count=1
    diff0
    {
        [color=orange]type=3[/COLOR]
        ratio=3.73
        inertia=0.1
        [COLOR=blue]friction=100[/COLOR]
        preload=50
        [COLOR=orange]power_ratio=2.000
        coast_ratio=1.000[/COLOR]
        output0=2
        output1=3
    }
}

Note the plural "s" for the tree header.

Several differential types have been added, each coming with another subset of parameters that define the locking characteristics. In this example, the old system only offered a type=1 viscous differential, whereas the new version has a more appropriate type=3 LSD type differential equipped.
If we left the same type=1 differential, power_ratio and coast_ratio would be replaced by the original locking_coeff=90 in this code.

The parameter friction defines the drivetrain losses that were previously included in the engine.max_torque factor. Now, for a non-AWD vehicle, we leave max_torque=1 and add a certain amount of friction instead. Around 50 to 150Nm would be appropriate, but it's easy to verify with in-gear acceleration tests. By using friction instead of eg. max_torque=0.9, the engine response is not affected by losses that actually occur further down the drivetrain.



2.3.3 Suspension

The suspension section has seen the most dramatic upgrades, as the addition of spring and damper definition by .crv files allows for very finely tuned vehicle handling. Since this is purely optional though, I'll refer you to the documentation for more on those.

There is one change, however, that came as a result of the new spring curve feature that I'll list here, because of it's big influence on the setup process.

Old:

Code:
susp_front
{
    y=0.000
    z=1.4865
    [COLOR=red]restlen=0.498[/COLOR]
    minlen=0.355
    maxlen=0.545
    [COLOR=orange]k=39927
    bump_rate=3724
    bump_function=0
    rebound_rate=6318
    rebound_function=0[/COLOR]
    anti_pitch=0.25
    roll_center
    {
        x=0
        y=-0.837
        z=0
    }
}

New:

Code:
susp_front
{
    y=0.000
    z=1.4865
    [COLOR=red]restlen=0.590[/COLOR]
    minlen=0.355
    maxlen=0.545
    [COLOR=red]warplen=0.430[/COLOR]
    [COLOR=orange]k=23607
    damper_curve=suspension_damper_front.crv
    bumpstop_len=0.050
    bumpstop_k=100000
    bumpstop_damping=5000
    reboundstop_len=0.010
    reboundstop_k=100000
    reboundstop_damping=5000[/COLOR]
    anti_pitch=0.25
    roll_center
    {
        x=0
        y=-0.837
        z=0
    }
}

While minlen and maxlen retain their original meaning, restlen has been redefined. Before, it used to be a point inbetween minlen and maxlen, that directly determined the static ride height of the vehicle. Now, restlen refers to the free length of the spring, with no load applied to it. Thus, by definition it has to be a larger number than maxlen's, because every automotive spring experiences preload (a certain static compression that keeps the spring safely in place even when the suspension is fully extended).

By adjusting the distance between maxlen and restlen you can influence the static ride height of the vehicle without changing the actual spring stiffness. Think of it as an adjustable spring perch on an aftermarket coilover suspension, for example. It used to be impossible to preload the suspension in the old system. So as a result, many vehicles ended up with compromised stiffness settings - this is why you see a softer spring in the newer code example (not just because of this effect, but it played a role).

Another important point is the fact that restlen is also the reference point for all wheel kinematic effects - camber and toe settings further down in the wheel sections are based on it, so they will need to be redone whenever restlen changes.

warplen is a new parameter that sets the initial suspension length when spawning. It's usually kept close to the static ride height setting.

The orange sections show old vs new damping and "rubber" stop parameters. While it's not required, updating to this system is highly recommended.



2.3.4 Ackerman

In the wheel section there have been numerous additions too, but I'll only mention the ackerman definition here in the new version sample:

Code:
wheel_front
{
    y=0
    z=0
    steering=1
    reverse_steering=0
    lock=53
    [COLOR=orange]ackerman=1.1[/COLOR]
    mass=40
    inertia=1.3
    radius=0.339471
    width=0.1684
    rolling_coeff=0.014
    max_braking=3000
    max_handbrake_torque=0
    braking_factor=0.60
    inboard_brakes=0
    brake_dissipation=0.0005
    brake_heating=0.0004
    brake_max_temp=800
    tire_rate=200000
    tire_damping=250
    tire_damping_lowspeed=2500
    tire_damping_threshold=5
    pacejka~pacejka
    {
        max_slip_len=6.0
    }
    tire_model
    {
        damping_coefficient_lat=0
        damping_coefficient_long=0
    }
}

In the very old versions, before the last Racer final v0.5.0, ackerman was already defined in the same way as now. Somewhere inbetween then and now, there was a period where it changed and had to be used for each steered wheel individually, with opposing signs for both sides (positive and negative). Qlog.txt will warn you about the negative value, if that should be the case.
 
Yeah, I'll try to stick to basics rather than explaining what everything does, that sounds good. A peek at the help threads says that people are more concerned with the gross errors (sky is black, car is transparent, wheels are too far out) than with specifics anyway.

I'm definitely going to need help on the track section, with knowing what's okay to leave default (probably don't need to actually explain TOD, just link to some info on the Racer site, and suggest the defaults are alright) but that can come later. I'm more familiar with the car graphics than anything, which is why I'm spending so long on the shaders. :p
 
It's simply in the order of my car.ini files, yes, but I'd say that for almost every new release I try the force feedback settings in the first part are really also the first things I check/correct. So, in a sense the order is also reflecting the importance or relevance.
 
Can anyone remember the name of that GUI utility that allowed one to define fuel, driver, engine, transmission point masses and get some Center of Gravity position data from it?
 
Hello everybody,

first of all, big thanks for setting up this howto! I'm trying to learn how to do the upgrading of cars to 0.90 and the howto is very helpful. I try to update the Aston Martin DB9 by Bumper (found on tracciontrasera), so I started with the car.shd and by copy&pasting from this howto with halfway switched off brain and having a look at some other cars' car.shd files I got the body, the interior and the windows to look more or less ok. However, I still struggle to get the brake lights and the tires right, both are somewhat transparent. Here is a screenshot of the problem:

Arbeitsfl%C3%A4che1_24-08-2014_20%3A21%3A44.png


and here is how the car.shd currently looks like:

Code:
;Aston Martin DB9 shader by Bumper
;;;;;;;;;; Standard presets ;;;;;;;;;;;;
vf_dyn_standard
{
  vertex_shader
  {
    file=dyn_standard_v.cg
  }
  fragment_shader
  {
    file=standard_f.cg
  }
}

vf_dyn_reflect
{
  ; Just reflection
  vertex_shader
  {
    file=dyn_standard_reflect_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_f.cg
  }
}

vf_dyn_bump
{
  tangents=1
  vertex_shader
  {
    file=dyn_standard_bump_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_bump_f.cg
  }
}

vf_dyn_reflect_window
{
  vertex_shader
  {
    file=dyn_standard_reflect_window_v.cg
  }
  fragment_shader
  {
    file=dyn_standard_reflect_window_f.cg
  }
}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;; Aston Shaders ;;;;;;;;;;;;
shader_db9body~vf_dyn_reflect
{
  shininess=10
  specular=0.5 0.5 0.5
  reflect=0.2
  layer0
  {
    map=db9body.tga
  }
  layer1
  {
    map=$trackenvmap
  }
}
}

shader_db9brakel~vf_dyn_reflect
{
    layer0
    {
        map=db9blights.tga
        emission=2 2 2 1
        shininess=0
        specular=0 0 0 1
        blendfunc=blend
    }
}

shader_db9whl~vf_dyn_bump
{
  shininess=16
  specular=0.1 0.1 0.1
  tangents=1
  layer0
  {
    map=db9whl.tga
  }
  layer1
  {
    map=$trackenvmap
     blendfunc=filter
  }
}

shader_db9mirror~vf_standard
{
  diffuse=.1 .1 .1
  layer0
    {
       map=$mirror
    }
}

shader_db9blights~vf_dyn_reflect
{
  shininess=24
  specular=0.75 0.75 0.75
  layer0
  {
    map=db9blights.tga
  }
  layer1
  {
    map=$trackenvmap
  }
}

shader_db9trans
{
    layer0
    {
        map=db9trans.tga
        blendfunc=blend
        depthwrite=0
    }
    layer1
    {
        map=$trackenvmap
        texgen_s=reflection_map
        texgen_t=reflection_map
        texgen_r=reflection_map
        blendfunc=src_color one
        depthwrite=0
    }
}
shader_db9windows~vf_dyn_reflect_window
{
  sort_offset=1
  reflect=1.0
  shininess=40
  specular=1 1 1
  layer0
  {
    map=db9windows.tga
    blendfunc=blend
  }
  layer1
  {
    map=$trackenvmap
  }
  fresnel
  {
    bias=0.04
    scale=0.96
    power=2.0
  }
}
shader_db9decals
{
    layer0
    {
        map=db9decals.tga
        blendfunc=blend
    }
}
shader_db9interior~vf_standard
{
    layer0
    {
        map=db9interior.tga
    }
}

shader_db9interior_n~vf_standard
{
  sort_offset=1
  layer0
    {
       map=db9interior_n.tga
       blendfunc=add
       ;texenv=replace
       emission=80 80 80 1
    }
}
shader_db9stw
{
    layer0
    {
        map=db9stw.tga
    }
}
shader_db9inbody~vf_standard
{
    layer0
    {
        map=db9body.tga
    }
}
shader_db9gauges~vf_standard
{
    layer0
    {
        map=db9gauges.tga
    }
}
shader_db9gauges_n~vf_standard
{
    layer0
    {
        map=db9gauges_n.tga
        blendfunc=add
        emission=1 1 1 1
    }
}

shader_driver
{
    layer0
    {
        map=driver.tga
    }
}
shader_db9whl_blur0nt~vf_dyn_bump
{
    layer0
    {
        map=db9whl_blur0.tga
    }
}
shader_db9whl_blur1nt~vf_dyn_bump
{
    layer0
    {
        map=db9whl_blur1.tga
    }
}
shader_db9whl_blur0~vf_dyn_bump
{
    layer0
    {
        map=db9whl_blur0.tga
        blendfunc=blend
    }
}
shader_db9whl_blur1~vf_dyn_bump
{
    layer0
    {
        map=db9whl_blur1.tga
        blendfunc=blend
    }
}

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Therefore I'd like to start understanding what I'm actually doing and what one is supposed to do to get things look right. :)

Thanks for any input,
PhotonX
 

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: 281 27.4%
  • 100% offline racing

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

    Votes: 4 0.4%
Back
Top