ART DESIGN GUIDE
Models created in XSI can be put directly into the SW Battlefront engine with the proprietary exporter and by following a few simple rules.
Props - 0 - 500 polys
Buildings - 200 - 3000 polys (the higher end of this spectrum represents large buildings with large interiors)
Vehicles - 1500 - 2000 polys
Characters - 1500 - 2000 polys
Every object can be exported by itself, but if you want to see it from a distance you will need a low resolution version of the mesh for LOD purposes.
Those should be approximately 1/3rd of the original model's poly count, and a child of the model's root node.
You must declare it a LOD mesh by appending "_lowrez" to its object name.
Every model also requires collision objects and shadowvolumes to be inserted into the hierarchy.
Textures are required to be scaled in powers of 2, with 512 x 512 being the standard used in the PC version.
They all should be 24 bit (RGB) .tga's, unless there is an alpha channel, then it will be a 32 bit (RGBA) file.
Images should NOT be saved with RLE Compression.
Steps to creating a basic prop:
1. Construct a fairly low-poly mesh (again, 0-500 polys for a prop) in XSI with the center of the root node with a translation of (0,0,0) in the scene.
Try to minimize the number of actual objects in the prop by merging them.
If it is not possible, just make sure all objects belong in one hierarchy, because if you don't, not all of them will be exported.
Clusters are ok, but there can be only one set of textures coordinates.
If you want to use a texture with an alpha channel, see Appendix A.
2. Create a shadowvolume if needed. See Appendix B.
3. Create collision objects. See Appendix C.
4. Export the mesh. See Appendix D.
Each object that cuts terrain must:
Contain an object that is named "terraincutter"
Must be a child of an object.. not hidden on export.
after it is placed in the world through ZeroEditor it must be saved so the terrain file is overwritten.
After updating the world and TER file, there should be a hole in game.
If its position or size changes it must be rexported and the terrain updated/saved again.
terraincutter object can not be concave. Multiples must be used to accomplish that.
if you have multiple terrain cutters they must be named
terraincutter1
terraincutter2
terraincutter3
etc...
Do NOT use an underscore between "terraincutter" and the # (e.g., terraincutter_2)
Follow these steps to create objects that use transparency maps.
1. Create a texture with an alpha channel and save it as a 32 bit TGA.
2. Apply it to the model.
3. Select all polygons that will be affected by the transparency map and run the EDIT FLAGS script.
4. A dialogue box will appear. Select either single or double sided transparency depending on your need or preference. Say OK.
5. If done correctly, you should notice an orange property box in the explorer under the newly flagged object. You can also edit the applied property box by clicking on the orange square itself anytime after the initial application. But, if you want to add additional polygons into the transparency flag, it is best just to delete the property, select all the polygons you want, and re-run the script.
Shadowvolumes are special meshes that are created to mimic the model in shape and profile to cast shadows onto terrain and other objects.
It can also be used for self-shadowing.
Follow these steps to create a shadowvolume:
1. Create a low-poly mesh that is slightly smaller in scale than the original model's mesh. When both the original mesh and the shadowvolume are unhidden, you should not see any of the shadowvolume sticking out of the original model. Try to keep it as low-poly as possible, but pay special attention to the profile from the top down view or whatever angle the sun will be at in relation to the model. The silhouette is what needs the most attention, because this is what gets cast onto other objects. Also, the mesh must be completely closed without any open ends or polygons, and its global center is 0,0,0 (freeze the transforms).
2. Once created, name the shadowvolume mesh "shadowvolume". If there is more than one, name them "shadowvolume", "shadowvolume1", "shadowvolume2", etc.
3. Make the shadowvolume mesh a child of the actual mesh to which it is related. This is especially important when there are multiple shadowvolumes and bones and animated parts in the model. If the original mesh is skinned, then the shadowvolumes should be children of their respected bones. Otherwise, they should just be children of the individual objects.
4. Select the shadowvolume mesh.
5. In the Animate module, select Create > Parameter > New Custom Parameter.
6. In the dialogue box, rename the Parameter Name to shadowvolume. Uncheck the Animatable Characteristic Button.
7. Hide the shadowvolume mesh before export
https://en.wikipedia.org/wiki/Shadow_volume
Collision meshes are simple low-poly meshes that are used by the game engine to calculate when and how objects collide with each other.
There are 2 types of collision meshes used in SW BattleFront: collision meshes and collision primitives.
1. This is usually a low-poly yet fairly conforming version of the original mesh.
It is most often used for soldier and ordnance collision since those are most obvious ways to see collision mesh correctness.
For example, you can see the ordnance collision on an object by shooting at it with any weapon.
If the collision is sloppy and covers gaps or is not correctly aligned with the original mesh, then you will see the laser blasts hit empty space or inside the actual geometry of the model.
The collision mesh has to be named "collision", or if there are more than one, "collision", "collision1", "collision2", etc.
Multiple collision meshes will all get merged into one when munged. This is very important when considering rule #3.
Make the collision mesh a child of the root node or its corresponding node, and make sure its global center is at 0,0,0 (Freeze the Transforms).
2. Enabling the Collision Mesh:
if the vehicle .MSH file has a corresponding .OPTION file, then it might contain the argument "-nocollision".
This is to prevent generation of a default collision mesh using the model's full geometry.
If you have specified a collision mesh in XSI, you'll need to remove this argument from the .OPTION file (if there was one).
3. Collision meshes can NOT be used on moving parts (turrets, bones etc).
When the vehicle is munged, all collision mesh nodes are merged into a single non-articulated collision mesh.
If a moving part on a vehicle requires collision, it will have to be specified with a primitive.
4. If a vehicle has a collision mesh, it will automatically be used when colliding with soldiers and ordnance.
Collision meshes (on vehicles) are not used for any other type of collision.
Primitives must be used when vehicles collide with terrain, buildings, and other vehicles.
Collision Primitives are a cheaper and faster way of computing collision for the game engine.
It is also the only way to have collision on moving parts such as turrets or bones.
Collision primitives can be either cubes, cylinders, or spheres.
Cubes can be scaled in x,y, and/or z to better fit the geometry they are conforming to.
It is best to leave the original size of 8 units as is and scale the cube from there.
Cylinders and spheres CANNOT be scaled. Instead, use the polygon properties such as Radius and Length to control the size of those 2 primitives.
Whether you use cubes, cylinders or spheres you'll need to keep the default Subdivisions.
Also very important, primitive collision objects CANNOT be frozen (Freeze or Freeze M) or lose their primitive properties.
DO NOT move the center or Freeze the Transforms of collision primitives or else the proper information will be lost.
This information is taken directly into the game engine and if it is lost, the engine will most likely ignore the primitive collision.
There is a limit of 64 collision primitives per model (or 63 primitives + 1 collision mesh).
NEW BFII UPDATE FOR COLLISION AND USING PRIMITIVES
The game now supports the use of new naming conventions in XSI – no more ODF magic required!
The old naming conventions are still valid – naming primitives "p_name" and mesh "collision_name" - but if you use these you still need to do soldier/vehicle/etc separation the old way through ODFs. Nothing old will break, but there’s no reason to do anything new using ODF definitions.
New names:
Collision Primitives
p_-xxx-name
"p" underscore hyphen [types] hyphen name
"p" underscore hyphen [types] underscore name <This will work too (see rep_walk_oneman_atst.msh)
Collision Mesh
collision_-xxx-name
"collision" underscore hyphen [types] hyphen name
xxx is replaced with the type definitions below…
[Types] is any combination of the following:
s – Soldier (soft) collision
v – Vehicle (rigid) collision
b – Building (static) collision
o – Ordnance (ordnance :^) collision
t – Terrain collision
f -- Flag collision -used on flyers specifically for Space CTF to collide with the flag
So if you made a cube and wanted it to be used for soldier and vehicle collision, you’d name it
"p_-sv-SomeName"
Or if you wanted it to be used for ordnance collision only, you’d name it
"p_-o-SomeName"
Typically ordnance collision needs to be more accurate so you could make a mesh and, you’d name it
"collision_-o-SomeName"
** A word about meshes:
Multiple collision meshes for one object that you have are (and always were) MERGED at munge-time into ONE collision mesh.
So you can’t have 2 collision meshes, one for ordnance and a different part for soldier.
They will be merged together and used for one or the other.
So how does the new naming stuff work with this?
If you have multiple collision meshes, and you name ANY of your collision meshes with the new scheme, that name will be applied to ALL the parts.
Example:
You have 3 mesh parts, "collision_1", "collision_2", and "collision_-s-3".
They will be merged together, and the resulting goop will be used for soldier collision.
Or
You have 3 mesh parts, "collision_1", "collision_2", and "collision_3".
They will be merged together, and the resulting goop will be used for all types, Soldier, Vehicle, Building, Ordnance, and Terrain collisions which can be costly to framerate.
Granted any object can still be exported with one mesh collision called "collision_SomeName"
And it will work just fine, but Typically you will be Using p-collision for the easy parts, and collision mesh for the complicated situations, If you want those frames-per-second back, it’s gotta happen.
The maximum allowed number of collisions per object is now 64 That is, 64 TOTAL objects, so:
64 primitives
-or-
63 primitives and one collision mesh.
(Remember that all collision meshes are merged into one mesh at munge time, so basically 63 primitives and some meshes.)
The Mesh Exporter is a program/script that takes geometry models created in XSI and converts them into a .msh file that the SW Battlefront engine can understand and use in the game. Here are the steps needed to export a model:
1. Make sure the root node (dummyroot) is centered in the XSI world at 0,0,0. If this is not so, you may get an unexpected center or position of the exported model in the game.
2. Branch select (middle mouse click) the object(s) you want to export.
3. Run the XSI2Mesh Exporter script (File>Pandemic Tools>Export Mesh).
4. This opens a dialogue box. In this you:
a. In the Path box, browse or put in the correct path that you would like the .msh to be exported into.
Also type in the filename in the filename box.
b. Check the first box "Export Selected Models Only"
c. Check the "Export Animations" box ONLY if the model is animated and will potentially have a *.zaabin or *.zafbin file
d. Check the "Export Textures" box if the texture is not in the target location of the .msh file. (optional)
5. Another pop-up box will show the progress of the export, once this closes, your export is complete.
The CheckSel function in the export dialog can detect some problems.