Vehicles are special geometry objects, which are "driven" by scripts, which also determine the functionality. The information below is based on Crysis vehicles, but can be extended if needed.
Table of Content
General Setup in 3d applications
Vehicles are complex objects that need careful setup in the 3d package. Basically the setup should be applicable to any package. Polycounts need to be carefully calculated, as extended functionality increase object (drawcall) and polycount drastically.
- Important All vehicles have to face towards +Y in the coordinate system (front looking towards up in top view).
- Example: rotation and position of the chassis pivot:
- Every moving part needs to be a seperate object within the 3d package. The pivot needs to be set correctly within the 3d package, as the engine will use the object's individual pivot to make transformations.
Linked objects have the advantage that only the root needs to be selected and exported. All child nodes will automatically be exported. The name and pivot will be derived from the root joint.
- use a dummy as the root, make sure rotation is 0/0/0 and trasnformation in world space is 0/0/0
- All attachments (like doors, sparewheels, glasses, exploding fuel canisters, etc) have to be linked to the main object which is called "hull". It can be the chassis of a car, the fuselage or aircraft, or the hull of the ship. General rule: if the chassis moves in the 3d application, the parts should move, too.
- LODs can also be linked to the respective LOD0. i.e. $lod1_hull to hull; $lod1_wheel1 and $lod2_wheel1 to wheel1.
Naming is needed for scripts to identify the objects and interact with them. The examples below reflect the asset names used in Crysis - they can be different for other games.
- The parts need to be named in a logical way (chassis, wheel1, wheel2.., turret) as the objects will be referenced later in the Vehicle Editor and scripts.
- The scripts for damaged versions of vehicles expect an asset which contains the name of the intact model, plus the suffix "_damaged". (hull -> hull_damaged, door_left_1 -> door_left_1_damaged, etc.).
* Place the wheel object in the correct position.
- Place the wheel's pivot in correct position. (the picture below shows top View in 3dsMax.
- Type "Wheel" in the objects properties. (the picture below shows the 3dsMax Objects property window)
The wheel proxy must be simple enough to be recognized as cylinder by physics. Support for an additional detailed proxy (if the wheel's shape demands it) will follow.
Material Setup(i.e. proxies, breaklights, damage lights, max -> mtl file)
* Create one Multi/Sub-Object Material in 3dsMax which includes all materials associated with the asset.
- You must use Crytek shader in the max files to set up the material file for export.
- in the 3d application, the proxy material must have "Physicalize" turned on. the Value set to "Physical Proxy (NoDraw)". More Info
- Operational breaklights, headlights, different indicators on the dashboards has to be on different material IDs, so code can identify them, and deal with them (like setting glow value from code for example)
Vehicles are complex objects and simplifying collision calculation is very important for performance. Therefore it is advisable to create two physics proxies. one is for collision with the terrain and characters, one for collision with bullets, grenades...
- Vehicles must have a very simple physics proxy which is called "hull_proxy". This is a separate, collision object for character and terrain collision. It should be slightly larger than the enclosed detailed proxies. Polycount for this proxy must be fairly low. For land-based vehicles like cars, tanks and hovercrafts, the proxy should not have parts sticking out in places which can frequently bounce into and slide across walls, like the front and side parts of a truck cabin.
- For collision detection of bullets, grenades etc , the hull - object should contain a more detailed embedded physics proxy. It should resemble the shape of the vehicle more closely, small elements could be left out. It should certainly include cutouts, like holes for the doors, windows, and other open areas.
- Attached parts like doors and bumpers need an own simplified proxy in case the embedded proxy is too detailed and calculation heavy for terrain/water collision. In this case, add the suffix "_proxy" to the object name.
- Proxy material must have "Physicalize" turned on in the shader options within the 3d application (please refer to the Material setup section); the type should be set to "Physical Proxy (NoDraw)".
- LODs do not have to contain proxies, as it will be used from the LOD0. In versions with lower performance settings, where LOD1 is used as the base mesh, the proxy from the High Spec LOD0 is taken into account.
- Damaged model has to contain its own proxy to follow deformed / different geometry (LODs do not need a proxy)
* for general information refer to the LOD Creation
section; for specialties in vehicle creation, please see below.
- Because of the asset complexity it is recommended to link subsequent LODs to the LOD0 version and include the LOD0 name in the suffix. (i.e. "hull" has LODs linked to it called $lod1_hull; $lod2_hull.)
Tip: you can have different number of LOD levels for different parts of the vehicle. i.e. the chassis of a car may have 4 LOD levels whereas the door, being a more simple object, has only 2. Tip: LOD switching is based on screensize, smaller objects will switch earlier than big ones. Keep this in mind when doing LODs
Vehicle Damage Model
The damage model for vehicles is a separate asset which replaces the vehicles on destruction. It can be a simple static model or a complex prebroken object.
- it replaces the original model and therefore needs a separate proxy model
- The damaged objects needs the suffix "_damaged" to its name. (like hull -> hull_damaged, door_left_1 -> door_left_1_damaged, etc.)
- To have some extra debris (if one object is breaking apart to more debris parts), you can add further objects to the damaged model. These should be called the object's name + "_debris_#" suffix. (hull -> hull_debris_1, hull_debris_2, etc.) These will spawn and fly away from the blast when the vehicle explodes. (It happens only when the SpawnDebris damage behavior is set on a vehicle. Please refer to the code guide for this!)
- The damage model can also include LODs
Tip To manage objects easier, it is recommended to sort LODs via layers.
- If the damaged model is very big (i.e. 10m wide, 6m high), an Occlusion Proxy can be added by naming it $occlusion and linking it to the damaged model.Occlusion proxy is allowed to have open edges and need to be as low as possible (something around 2-10 polys).
If a window should be breakable, follow this procedure:
- Each window has to be a seperate object and linked to its parent (e.g. to the door it belongs to)
- It must be fully planar (physics requirement)
- Set the surface type to mat_glass_vehicle
- On the first breaking event, the vehicle will try to apply a spiderweb texture on the window. For this to work, there must be a submaterial available named "broken_windowpanes" containing the spiderweb texture. Surface type must also be mat_glass_vehicle.
* in 3dsMax, the TBC controller for the animations (translation and rotation) must be used. Any other controller will create unpredictable results. Please refer to Animation guide for more details!
- Animations have to be saved as .anm files. To save certain animations, you must select the objects you would like to save the animations of, and add to the export list. If you want to animate the doors closing, then you have to export with only the doors in the export list. File names has to start with the object names + the animation's name. If the vehicle's main file is called car.cga, then the animation should be called like car_door_opening.cga for example.
- Once you animated your objects, you have to export the default state. It has to be called the same like the object .cga file (if the object is tank.cga then the default animation has to be tank.anm ). This default state has to contain all the animated objects.
- Please see exporter documentation for further exporting features and parameters!
Tip: you can test if your animations are exported and playing correctly by loading the vehicle to the character editor, and clicking on the animation on the right!
Position Helpers for Characters
* Character sitting and enter positions need to be indicated with position helpers in the 3d package (i.e. Dummy objects in 3dsMax).
Vehicles are very complex objects and can cause major problems, if the exporting is not done carefully. To avoid complications, the scene
- add the root node to the export window and check Custom File Name; choose an appropriate filename and export.
- Vehicles except Tanks: export all parts as one cga. uncheck "file per Node" and "merge all nodes"
- Tanks: export all parts except the tank treads together as one cga.uncheck "file per Node" and "merge all nodes"
- Tank Treads: Export right and left tank tread seperately as chr. uncheck "merge all nodes"; check "file per node" if you like. Choose only the tank treads object, not the wheels or the bones
- choose the top node and relevant helpers and export only these. the linked children will be exported automatically.
- Tip: setting up named selection sets can help you in re-exporting your assets.
Setup in Sandbox
in order to work properly, a vehicle script needs to exist. otherwise the vehicle can only be judged visually as a Geom Entity.
- drag and drop the item from the entity section in the Rollup Bar or the Entity Library (in the Database View) into the level.
- if no script is available, drag and drop the asset from the Geom Entity section in the Rollup Bar into the level.
There are some useful commands you can use to check your asset, and see if it works as expected. Some of these are listed below. (You can turn off any of these drawing modes by entering 0 after the command instead of the number given here!)
- p_draw_helpers 1 – used to check physique proxies.
- e_debug_draw 1 – used to check LODs. Using this variable you can see the bounding box of the object, see the name of it, number of LOD levels available for the object, the one which is currently displaying, and the polycount of the current LOD.
- e_debug_draw 2 – displays polycount only for the given LOD.
- e_debug_draw 3 – Different LOD levels are represented in different colors, so you can clearly see the transition between two LOD levels. Also see the total number of LODs and the one currently displaying. Blinking one shows up if the given object does not have an LOD.
- e_debug_draw 5 – Shows how many material IDs are in use on the given objects
- e_lod_min 0 - 6 show the specified LOD number as LOD0 - very handy for debugging LODs in the engine.