Figure 1: The Basic Car Hierarchy layout
Cars in TDR2000 are reasonably complex and are created using a hierarchy system which uses different dummy nodes to define the various properties of the car. This document explains the different mesh and object types needed to create a fully functional TDR2000 Car. This is not a tutorial.
The cars are made up of several parts.
- Render Meshes
- The actual car geometry.
- Collision Meshes
- A Mesh which defines the bounding area of car part.
- Dummy Nulls
- A Dummy used either to define a point on the car or for Userdata Application.
- Pivot Polygons
- A Polygon that represents points for a panel to rotate about as it falls off.
Render meshes are meshes that actually get rendered in the game. These actually only make up a small part of what is required for a complex car.
lod[1/2/3/4][1/2/3/4]_) (#)Render meshes support Level of Detail (LOD) which must be separate meshes in the car hierarchy. A LOD mesh is represented by the prefix lod##_ in the mesh name. The first number after lod is the number of the LOD, and the second number tells how many LODs there are in the series. So lod12_engine reads LOD 1 of 2 engine LODs, and lod34_driver reads LOD 3 of 4 driver LODs. Car parts can be defined as either detachable, deformable, non detachable and deformable or static. The type of mesh depends on the userdata placed on the mesh.
If a mesh doesn't have the LOD prefix, the mesh will be rendered all the time regardless of how far it is from the camera.
Collision meshes are used in the game to detect whether the car or car part has collided with any other objects or land. It is critical that it has a low polygon count to keep the game running at a good speed.
There are 3 types of Collision meshes that make up a car:
This collision mesh is used in the game to detect whether the car has hit any other objects or land, and it is critical that it is as low polygon as possible, to keep the game running at a good speed. Simply create a very low poly mesh surrounding the car. This collision mesh must be the highest collision mesh in the tree. All other parts of the car (apart from the main chassis graphics data) are a child of this mesh.
The car's weight, center of mass and other physical attributes are described in the userdata for this mesh, and these must be tweaked to get the desired driving characteristics for the car. Collision userdata is distinguished from normal userdata, by the file prefix CUD_. The XYZ components of the inertial axis and the center of mass can be either floats or the word Auto. If Auto is used, the exporter plugin calculates them using the bounding box of the shape. Userdata will be fully explained later in this document. The Carbody collision mesh is is given the name data_chassis.
As with the Carbody Collision mesh, body part collision meshes are made up of polygons and you should keep the polygon count as low as possible. These collision meshes are meshes surrounding each car part which will fall off, such as doors, bumpers and panels.
This collision mesh must have body part userdata on it. The Collison data mesh is given the data_ prefix. Eg, data_bumper.
This collision mesh should be modeled for all cars. It is similar to the normal carbody collision mesh in all respects except it has vertices on the z=0 plane, to facilitate bending. This mesh therefore has extra vertices/edges/polygons but is only used when the car is bent. Export the collision data, and then place it in the car directory. The filename of the bend .dcol must be entered in the car descriptor.
Nulls are used in cars to represent points in space for events to occur, or to define a child object's properties. A Max object Dummy is used to represent a Null.
This null is arbitrary oriented in space and one of its axis is used to rotate the subtree. This axis is chosen in the userdata as well as the minimum and maximum angles. The null is centered on the pivot point of the tree. The number of the userdata is 4. The axis must be 0 for X, 1 for Y, 2 for Z. When doors or bonnets open, they are pushed out as follows. You will need to align the pivot null center so that doors, bonnets, hatches, etc. open outwards.
Pivot axis is X, push out on negative Y axis of the pivot point null orientation.
Pivot axis is Y, push out on negative X axis of the pivot point null orientation.
Pivot axis is Z, push out on negative X axis of the pivot point null orientation.
Burn nulls are points where smoke and fire is produced when the car is damaged. The first null is for the engine, and gets activated as the engine gets damaged and the other nulls get activated when the car gets wasted. No more than four (4) burn nulls can exist in a car at the same time and the nulls must be specified in the car's descriptor file.
Wheels are created at the origin in the world with the wheel rotation about the X Axis. Only 1 master wheel is necessary with Nulls placed around the car to define the placement of the other car wheels. The wheels are described in the car's descriptor file.
Wheels have several different variations which are defined in the cars descriptor file:
Driving wheel: -3 = driving backwards, don't fall off
Driving wheel: -1 = driving backwards, fall off
Driving wheel: 0 = non-driving, fall off
Driving wheel: 1 = driving, fall off
Driving wheel: 2 = non-driving, don't fall off
Driving wheel: 3 = driving, don't fall off
Steering wheel: -1 = Steer backwards
Steering wheel: 0 = Non-steering wheel
Steering wheel: 1 = Steer forwards
Userdata is extra information that is assigned to an object to define specific properties about the object. This includes information about deformation properties, mass, textures, detachability and rotation and translation. For any object which requires userdata, right-click on the object and select Properties. Under the User Defined tab, enter the required userdata.
The different Userdata types:
Detach userdata is assigned to a Dummy Null, not the actual mesh. All child objects of this Null are detachable.
1 // This flag is 0 if the child is attached and 1 when it's detached I 0 // The next one is a pointer to the rigidbody created when the child is detached I 0
Assigned to a part that Deforms and Detachs such as panels, bumpers, etc. The userdata is assigned to a Dummy Null, not the actual mesh. All child objects of this Null are Deformable and Detachable.
It must have a Null with userdata type 1 as its parent. Detachable meshes and collision objects are placed as the child of this Null.
3 // Softness F 0.5 // Crush type I 0 // Ease of detachment F 0.5 // Current damage F 0.0 // Texture damage level 1 texture pointer I 0 // Texture damage level 2 texture pointer I 0 // Threshhold for level 2 F 0.2 // Damage level 1 texture (undamaged) S "Limey" // Damage level 2 texture S "Limey_Damaged"
Softness: Default 1.0. Higher is softer, lower is harder. This multiplies the force that is being applied to the mesh when deforming.
Crush Type: Default 0. Zero is for deforming, 1-4 is for glass that smashes when the sides of the object is hit.
Ease Of Detachment: Default 1.0. The higher this value, the harder it is to break this bit off.
Current Damage: Default 0. Leave it at 0.0 always.
Threshold for level 2: Default 0.5. How hard it is to get to the second damage level (damaged texture smashed glass). The higher this is, the harder it is to get to the 2nd level of damage.
Damage Level 1 Texture: Base car texture without the TGA extension.
Damage Level 2 Texture: Damaged car texture without the TGA extension.
Assigned to a Null to define the point of rotation for any detachable part that needs to rotate such as doors, hood, boot (trunk), etc.
The Axis Null must be the parent of the detach null in the hierarchy.
4 // Rotation Axis X = 0 Y = 1 Z = 2 I 0 // current F 0.0 // current delta F 1.0 // min rotation angle from current F 0.0 // max rotation angle from current F 75.0
Assigned to any meshes that deform, but never detach, such as the main car chassis. If using a LODed non detachable deformable, put userdata on each lod mesh.
6 // Softness F 0.5 // Crush type (unused, get rid of it) I 0 // Ease of detachment F 0.5 // Current damage F 0.0 // Texture damage level 1 texture pointer I 0 // Texture damage level 2 texture pointer I 0 // Threshhold for level 2 F 0.2 // Damage level 1 texture (undamaged) S "Limey" // Damage level 2 texture S "Limey_Damaged"
Softness: Default 1.0. Higher is softer, lower is harder. This multiplies the force that is being applied to the mesh when deforming.
Crush Type: Default 0. Zero is for deforming, 1-4 is for glass that smashes when the sides of the object is hit.
Ease Of Detachment: Ignored.
Current Damage: Default 0. Leave it at 0.0 always.
Threshold for level 2: Default 0.5. How hard it is to get to the second damage level (damaged texture smashed glass). The higher this is, the harder it is to get to the 2nd level of damage.
Damage Level 1 Texture: Base car texture without the TGA extension.
Damage Level 2 Texture: Damaged car texture without the TGA extension.
The spinner is a mesh which rotates at a constant rate throughout the game. The rotation is centered on the center of the mesh, and the rotation occurs around one of the three axis, chosen in the userdata. The speed of the rotation is also selected in the userdata.
// spinner node 7 // axis I 1 // current F 0.0 // current delta in degrees per second. F -360.0
This is assigned to a polygon that represents the points a detachable mesh will rotate about as it falls from the car. The Pivot polygon must be a child of the collison mesh of the detachable part.
// pivots points 11
A Pumper is any object that moves back and forth, such as the blades on the Limey. This userdata is assigned directly to the mesh. Generally Pumpers don't need another userdata or Nulls.
// pumper node 8 // Translation Axis X = 0 Y = 1 Z = 2 I 0 // current F 0.0 // Speed in meters per second F 2.2 // Minimum translation F -1.17 // Maximum translation F 0.0
The Limey.max file included in the TDR2000 SDK shows most of the features available in TDR2000 cars. It includes pumping parts, detachable panels, opening doors and hood, breakable glass, panel pivots, breaklights and fire/tow points.
To Easily view the car hierarchy layout, it's best to Uncheck ALL options in the Schematic view options dialogue and use the vertical layout option.
The Basic Car hierarchy:
Figure 1: The Basic Car Hierarchy layout
The MAIN_NULL is a Dummy Null that defines where to start the Car exportation. When the car is exported this null should be selected.
Wheels are parented directly to the MAIN_NULL. If the Wheels have LOD, create a Dummy Null as the Master Wheel, then parent the LOD meshes of the wheel to the wheel_master.
Figure 2: The Wheel Master
You can Also have Multiple wheel types each with LOD. Create separate master wheels for each wheel type and parent them both to the MAIN_NULL.
Figure 3: Multiple Wheels Masters
The actual wheels of the car are simply nulls at the points you want the wheels. These Nulls should be parented directly to the MAIN_NULL as well. These can be seen in Figure 1 as inst_FL, inst_FR, etc.
The ViewFX Null is the parent of all other car parts. Any Non Detachable meshes should be parented directly to the ViewFX Null.
The Main Car collision mesh (data_chassis) is parented to ViewFX and all other car components are children of the collision mesh.
Figure 4: The View FX Null
Everything else gets parented under data_chassis. Doors, detachable parts, flame points, the tow point, and the driver hierarchy.
Figure 5: Data Chassis
The Detach/Deform tree is used for any parts of the car that fall off such as panels and bumpers, etc. Eg for a bumper: Create 2 Nulls for the switch_detach_bumper (give it userdata 1) and switch_deform_bumper (give it userdata 3) and parent all LOD and collision meshes for the bumper to these. The Pivot polygon is then parented to data_bumper and given userdata type 11.
Figure 6: A Detachable mesh
Any Rotating Axis objects like doors etc. is created the same as a detach/deform object except an axis_ null is placed between the data_chassis and the switch_detach null. The axis_ null is given userdata type 4. These object types don't require a pivot null as the object will rotate about the axis point when falling off.
Figure 7: An Axis object. Doors etc
Flame Nulls are simply a Dummy Null placed at a point you want flame to come from the car. The first flame null should be placed at the engine, others can be anywhere on the car. You can have up to 4 flame points.
The Tow Point is where objects like the Mutant Tail Thing get attached to the car. It's also used to attach bombs in some missions. It's also just a dummy null placed at the rear of the car.
The Driver Null is a Dummy that is the parent of all objects that should be removed when the player is driving from the incar view. Items such as the Driver mesh and the car windscreen should be parented to this Null.
Figure 8: The Driver Hierarchy
Glass windows etc. should be given userdata type 6 with the texture names renamed to that of the glass texture. If the window is part of a car door or other rotating object it should be a separate mesh and parented to the collision data of the door.
The base Car texture cannot contain more than 2 levels of alpha transparency (it must be ColorKey). If more than 2 levels are used alpha rendering problems may occur.
Only 1 texture can be used per mesh object. This is because when the object swaps to the damage texture only 1 damage texture is used. So Any polygons using a second texture will change to the damage texture of the main car.
All TDR2000 cars use 1 512x512 base texture for the entire car and 1 other texture for the car windows of size 64x64. The base texture is duplicated and modified for the damage texture. More textures can be used but is not recommended due to the large amount of texture memory required.
All nulls for standard detachable objects must be placed at the origin of the world and their transforms must be reset.
All Door nulls in the hierarchy must be placed at the same position as the axis null and must also have their transformations reset. For a standard car the left door axis must be rotated –180 about the Z axis for placement. This makes the door open outwards instead of into the car. The right door will work with transforms reset.
Any Texture can be defined as 2-sided or environment mapped simply by clicking checkboxes within the material editor. For 2-sided polygons, simply check the 2-Sided box and for environment mapped check the Reflection checkbox.
You can create as many copies of the material as is required to obtain different properties and any images used in the materials will be exported by the plug-in. Using 2-sided allows both sides of the polygons to be seen in the game.
The purpose of this section is to explain the editing of the vehicle descriptor text file. This file is found in the specific car's folder and is named <CARNAME>_descriptor.txt. (eg eagle4_descriptor.txt)
Some examples are given, and should be used as a guide to the setup process, but experimentation is advised, as it will give a better understanding of how changing one parameter affects another, and how ultimately, the final settings will be a compromise between all contributing factors. Most settings in this file refer to objects which can be found in the vehicles .h file.
TEXTURE DESCRIPTOR (#)
"McKilemtexturedescriptor.txt"HIERARCHY FILENAME (#)
"McKilemMain_Null.hie"HIERARCHY FILENAME (#)
"McKilemMain_Null.h"DYNAMIC OBJECT FILENAME (#)
"nofile.txt"SHADOW DCOL FILENAME (#)
"McKilem_data_body.dcol"DEFORMATION FILENAME (#)
"McKilem_Deform_Bits.txt"HORN SFX (#)
"SIREN"ENGINE SFX (#)
"SPORTSCAR1"BRAKE LIGHT TEXTURE NAME (#)
BRAKE LIGHT SIZE (#)
NUMBER OF BRAKE LIGHTS (#)
2"MCKILEM_LEFTBRAKE""MCKILEM_RIGHTBRAKE"NUMBER OF DOORS (#)
2"MCKILEM_AXIS_LEFTDOOR""MCKILEM_AXIS_RIGHTDOOR"NUMBER OF BONNETS (hood/hatch/trunk/boot) (#)
1"MCKILEM_AXIS_HATCH"CAR SHELL NODE NUMBER (#)
"MCKILEM_VIEW_FX"TOW BAR NODE NAME (#)
"NONE"TRAILER DESCRIPTOR (#)
"NONE"ENGINE FIRE and SMOKE NULLS (#)
3"MCKILEM_FIRENULL1""MCKILEM_FIRENULL2""MCKILEM_FIRENULL3"NUMBER OF GEARS (#)
DIFFERENTIAL RATIO will also produce faster gear changes, better acceleration, but will reduce overall speed.7.0 and 12.0, while a fast sports car may have anywhere between 2.0 and 5.0, so it is able reach higher speeds.
A typical setting for a five-speed car (including reverse gear) is as follows...
5 (Number of gears) -3.00 Reverse 2.50 1st Gear 1.30 2nd Gear 0.90 3rd Gear 0.70 4th Gear 5.00 (Diff Ratio)
One of the most important aspects of the gear and diff set up is making sure the engine noise sounds correct with the gear changes, so experimentation and constant play testing (and listening) is vital.
CLUTCH TORQUE (#)
ENGINE INERTIA (#)
GEARBOX INERTIA (#)
ENGINE IDLE REVS (#)
300.0 is sufficient.NAMING OF THE EIGHT FUNCTION CURVES (#)
Name of torque curve function "McKilemTorqueCurve.func" Name of tire slip curve function "McKilemRoadSlipCurve.func" Name of tire load curve function "McKilemTireLoadCurve.func" Name of Camber thrust curve "McKilemCamberThrust.func" Name of Camber grip curve "McKilemCamberGrip.func" Name of Front Down force curve "McKilemFrontDownForce.func" Name of Rear Down force curve "McKilemRearDownForce.func" Name of Roll resistance curve "McKilemRollResistanceCurve.func"
NUMBER OF WHEELS (#)
4WHEEL THICKNESS (#)
0.40 (length is in meters)WHEEL DATA (#)CENTERED HIERARCHY NODE (#)
"MCKILEM_MASTER_WHEEL"OFFSET INSTANCE NODE (#)
"MCKILEM_FL"DRIVING WHEEL (#)
1 is to be used. (If not, use 0).STEERING WHEEL (#)
1 is to be used. (If not, use 0).MASS (#)
10.0X-AXIS MOMENT OF INERTIA (#)
SUSPENSION DIRECTION (#)
1.0 should be used.MAXIMUM SUSPENSION OFFSET (#)
0.5 to 0.6 is sufficient.MINIMUM SUSPENSION OFFSET (#)
–0.1 to 0.1 is sufficient, (Depending on the Y position of the wheel instances when exported into the game).CAMBER ANGLE (#)
2.0 to 6.0 degrees (either positive or negative values).RADIUS (#)
SUSPENSION SPRING STIFFNESS and SUSPENSION SHOCK ABSORBER DAMPING (#)
SUSPENSION SPRING STIFFNESS (#)
"100000.0", but if you were to set up a 4X4 vehicle, and require a softer suspension setting, a value of "50000.0" to "80000.0" would be sufficient.SHOCK ABSORBER DAMPING (#)
"5000.0" would provide slow movement (ideal for a 4X4 vehicle), and a value of "10000.0" would produce a quick response (ideal for a racecar).At the end of the descriptor is the InCar view setting. An ingame "shitter" is used to place the cockpit accurately.
Once you have your car working ingame use F6 to get to the Incar view.
At the console type b_physics 0
Then enable Mousecam ******
At the console type setshitter 7
Then the incar view can be moved around using the mousecam or the following keys:
Pageup/PageDown – moves the camera Up/Down
Home/End - moves the camera Left/Right
Insert/Delete – moves the camera Forward/Back
Holding down the B key while using the pageup/down etc. keys will move just the steering wheel and not the camera.
When the camera placement is ready type the command setCockpit 1. You can then drive the car with the new cockpit placement.
If you're not happy with the placement repeat these steps. Once you're completely happy with the cockpit placement, use the command setCockpit print. The cockpit coordinates are then written out to a file dbg_cockpit.txt in the TDR2000 install directory. The cockpit placement details then need to be copied into the end of the car descriptor file.
// Cockpit description info follows // Marker used by TCarCockpit to find this info COCKPIT // cockpit hierarchy to use "incarwheelconvsoftnull1.hie" // cockpit camera position in carspace x y z 0.39 1.01 0.40 // cockpit camera lookAt position 0.38 1.04 1.39 // camera to steering wheel offset -0.04 -0.07 0.02 //Yo Artists! Driver null string goes here! "LIMEY_DRIVER" // The Driver Hierarchy Null.