| Home | Every physical aspect of the car should be in the car.ini file. |
|
|
|
Introduction
This page details how to define wheels in the car.ini file.
Several sections on wheels exist:
Generally there are 4 wheels. You can set this in car.wheels. From 2 to 8 wheels are supported. Note though that motorbikes are not supported; you can make one, but motorbikes tend to rely on a lot of gyroscopic forces, which aren't simulated in Racer (v0.5).
Wheels are normally powered through the differential, but you can fake a power link by setting wheel<n>.powered to 1. Normally, this value isn't used unless you want to fake 4WD; see the tutorial on differentials for more information on this.
The tire is located mostly by the suspension it is attached to. There was an additional offset for the contact patch center, specified in wheel<x>.x; but this value has become obsolete since around v0.6.5, and should now always be set to 0. To offset the 3D model of the wheel, use wheel<n>.model.offset.x instead. Also, wheel<n>.y and wheel<n>.z are unused; to move the wheel physically, modify susp<n>.x/y/z.
Specify a 3D model in wheel<n>.model.file. The tricky bit is to get the right model at the right wheel. See the image here for a graphical view of where the wheels should be located. The radius of the wheel is defined in wheel<n>.radius, which is important to get right so the car doesn't sink into the surface (much). The tire's width is defined in wheel<n>.width but is currently unused. It may be used in the future for skidmark widths.
You may specify multiple 3D models, depending on the spin velocity. This is done like below (an extract from car.ini); multiple 3D models are specified, and the right one is selected at runtime. The high-speed models have modified textures that are blurred. As the entire model is swapped, you can elect to use simpler polygons that are non-transparent for the sides, which may be faster while rendering.
wheel0
{
... model
{
file=Wheel_LF.dof
}
model2
{
file=wheel_blur1_lf.dof
velocity=15
}
model3
{
file=wheel_blur2_lf.dof
velocity=25
} ... }
This specifies how much (in degrees) the wheel is able to rotate (around its spin axis) due to steering input. Pass a number (in degrees) in wheel<x>.lock. For the wheel to actually follow the steering wheel, set wheel<x>.steering to 1. If you want 4-wheel steering, set wheel<x>.reverse_steering to 1 for the rear wheels to get logical steering responses.
Notice there are problems with real-life vs. simulated steering, since most of the times, a computer sim wheel will not be able to rotate as much as a real wheel. This gives problems since too much lock will make the car feel very sensitive, since the steering wheel's input is more sensitive than a real steering wheel. Non-linear steering can help this, but this is personal preference; generally hardcore simmers will run close to linear steering, while non-linear may feel easier for others.
Camber is the roll angle between the tire and the track surface. The suspension geometry decides what amount of camber is actually present.
Specify static camber in wheel<x>.camber (in degrees). Negative camber means the tire will lean inward to the car. Positive camber means the tire will lean outward. This defines the amount of camber when the wheel is in its rest position (no suspension compression, no steering).
Camber is dynamic, meaning effects like steering affect the total amount of camber. See the suspension section for more details on camber changes.
Toe gives a slight static change in tire direction. 5 degrees toe means the tire will rotate 5 degrees counterclockwise (as seen from the top of the tire looking down). You specify the amount of toe in wheel<x>.toe.
A bit of front toe in seems to be able to give a slightly better (more stable) turn-in. Similar effects can be achieved with toe on the rear wheels.
Note that this means that for toe in you will need negative toe values on the left wheels/side of the car, and positive values on the right wheels. Using positive value on both sides will lead to steer pulling, same with both negatives values.
The tire's mass is specified in wheel<x>.mass, and the inertia is in wheel<x>.inertia. Note that this mass encompasses the entire wheel, so not just the rubber tire, but also the hub, brakes and all that moves vertically and is part of the unsprung mass. This mass pulls the tire down (according to gravity). The inertia is a single value indicating the spin inertia; any engine or braking torque uses the inertia to decide how fast the wheel will spin up or slow down.
Rolling resistance is mostly friction that makes the tire slow down. You can specify the coefficient in wheel<x>.rolling_coeff. It is multiplied by load (Fz in the SAE axis system) to come up with a generic torque slowing the tire down. Rolling resistance is taken to be linear (although some books use a quadratic relationship). In real life, you can get to a point where vibrations will occur in the tire, making the rolling resistance go up a lot, but this is mostly at a point at which the tire wouldn't work well anyway (all tires have a maximum speed they can be driven at).
For typical values, a regular car's tire usually has a coefficient of 0.007-0.012 (0.7%-1.2%). Truck tires generally have less, around 0.005 to 0.007. Note that this is related to load. From v0.8.8, you can see the actual rolling resistance force relation (F_rollResistance/load) live in the Ctrl-1 debug screen (2nd page probably; press Ctrl-1 twice).
Note that MF5.2 (Pacejka) defines a more elaborate roll resistance torque (My=SAE coordinates, so the tire moment around the spin axis):
My=R0*Fz*{ qSy1+qSy2*Fx/Fz0 + qSy3* |Vx/Vref| + qSy4(Vx/Vref)^4 }
However, linear approaches seem ok enough, and Racer doesn't implement this (yet?). So the debug screen will currently show a constant number (only switching from positive to negative, depending on the spin velocity of each wheel, always working to slow down the wheel).
Tire force buildup (relaxation lengths)
Commonly known as relaxation lengths.
Relaxation_length in the car.ini file actually comes in 2 parts; relaxation_length_lat and relaxation_length_long (in wheel<n>.tire_model). They determine the lag in the tire's flexing towards a slip angle. If you're driving slow, and turn your steering wheel, the tire doesn't immediately give you the lateral force. It takes a while; the rubber must still adjust to the new settings. There is no minimum speed for this (low speed is where the effect is most noticable) but there is a point where slip ratio/angle is calculated directly because the tire rotates so fast that integration of slip ratio is worse than calculating it directly (however this is only at high speed around 200 km/h).
Relaxation is implemented longitudinally & laterally. Normally the longitudinal relaxation length is around 10 times less than the lateral relaxataion length (since tire stiffness is much higher longitudinally than laterally). Typical start values are around 0.9 for lateral and 0.09 for longitudinal for a passengar car, more like half of that for sport tires.
Tire forces are generated in a couple of directions. One of them is vertical, also known as the load (Fz in the SAE axis system, although in Racer, Y is up).
Racer uses a contact-point tire model. This means that a single line is traced from the suspension downwards to find a single point on the surface. So this gives the penetration distance (into the surface) for a single point. Ofcourse, a tire is a rubber ring where an area really is responsible for what the tire 'feels' as load. A solution to this is to filter the incoming surface noise signal. A direct calculation of tire load would be: load=tire_rate*penetration_depth. For example, if the tire rate is 200000 and the penetration is 0.005 (5mm), you get a load force of 200000*0.005=1000N. Road noise is high frequency though, but really a lot of that is filtered out in the rubber area of the tire. Thus, if we filter the road noise, we simulate the rubber.
Racer v0.8.34+ uses a 2nd order Tustin filter (Tustin filters are very stable even at high step times, and also very fast) to process the road noise signal. This smoothens out harsh steps to a more curvy character. Effectively it tries to simulator the area of the tire, to simulate what the tire feels instead of looking only at the contact-point derived force. The problem with using contact-point forces directly is for example that when turning, you feel a lot of noise in the steering wheel. This is because:
The solution is to filter the noise signal to reflect the properties of rubber more. Filtering load/penetration depth has been tried but leads to time-lags, giving wobbly cars.
The parameters affecting noise damping then:
You can test how your filter is doing. Run a race, then enter these console commands (with ~):
This will show the road noise both filtered and unfiltered.
Tire forces - lateral & longitudinal
Tire forces are also generated in the horizontal plane:
Notice that the .crv files, previously used for lateral/longitudinal forces, are obsolete (replaced by Pacejka curves for many years).
Combined slip force methods are a complex subject, so were placed on their own page.
Braking torque is specified with these parameters:
Given these parameters, brake bias is defined implicitly. Maximum braking torque is defined as max_braking*braking_factor, so the brake bias can be defined as this product for the front wheels, divided by this product for the rear wheels.
You can also control the brake disc temperature with a few extra
parameters; brake_heating, brake_dissipation
and brake_max_temp. Check the tutorial
on brake discs for more information.
The wheel<n>.skidding parameters define when skidding occurs. This is used mostly for audio.
The tires are the main contact points touching the surface. Racer uses a single contact point, where a real tire has a contact patch area, instead of just that single point. This leads to effects where a single point sees more surface movement than a real tire would, where the contact area filters out a lot of the surface noise. Racer v0.8.14+ adds a 2nd order filter which is optionally usable (still experimental).
(last updated October 2, 2013 )