The currently exporter has pretty straight forward behaviour. It'll grab the current active scene and export it as a .msh file that can be consumed by Zero Editor, modelmunge, and zenasset.
Triangle strip generation can be slow for meshes with thousands of faces and is off by default to enable a fast mesh iteration workflow if desired.
In order to improve runtime performance and reduce munged model size you are **strongly** advised to turn **Enable** triangle strip generation for your "final" export.
For very complex scenes with meshes that have tens of thousands (or more) faces Blender may freeze up for a couple minutes while triangle strips are generated. Either minimize it and do something else on your PC while you wait and it'll eventually finish.
| None | Export the current active scene without animation data. |
| Active | Export the current active scene with animation data extracted from the active Action on the scene's Armature. To save space, the exporter will exclude geometry data from the resulting .msh file but will ensure the root object has some geometry and a material for munge compatibility. |
| Batch | Export the current active scene with animation data but produce a separate .msh file for and named after each Action in the scene. Exported files will be placed in the selected directory. If a file is selected, they will be placed in that file's directory. This option essentially repeats the export behavior of "Active" for each Action in the current Scene. Be sure to remove an Action from the scene if you do not want it exported! |
There should be few things that can cause an export to fail. Should you encounter one you can consult the list below for how to remedy the situation. If you're error isn't on the list then feel free to [Open an issue](https://github.com/SleepKiller/SWBF-msh-Blender-Export/issues/new), remember to attach a .blend file that reproduces the issue.
As of Blender 2.8 after an export has failed you can look in the "Scripting" workspace and in the bottom left corner you should be able to look for and find the description of the "RuntimeError" that caused the failure.
The "RuntimeError" at the top of the callstack should contain the error message. The [System Console](https://docs.blender.org/manual/en/latest/advanced/command_line/launch/windows.html?highlight=toggle%20system%20console#details) should also contain the error and can be easier to read.
#### "RuntimeError: Error: Object does not have geometry data"
This is currently known to only happen for [Grease Pencil](https://docs.blender.org/manual/en/latest/grease_pencil/index.html) objects. There is currently no support in Blender for easilly converting a Grease Pencil object into a temporary mesh in Python the same way you do for other objects, hence no direct support for exporting them.
To solve this error you can manually convert the Grease Pencil object to a mesh before exporting.
#### "RuntimeError: Object '\{object name\}' has resulted in a .msh geometry segment that has more than 32767 vertices! Split the object's mesh up and try again!"
This error indicates that after turning a Blender mesh into geometry segments for a .msh file that one of the geometry segments
had more vertices than is supported in a .msh file.
.msh geometry segments are created by iterating through a mesh's faces and assigning them to a segment based on their material. A mesh produces as many geometry segments as materials it uses. So a mesh that uses 3 materials will produce 3 geometry segments.
To solve this error you must cut the offending Object's mesh up so that no single geometry segment made from it has more than 32767 vertices.
#### "RuntimeError: Object '\{object name\}' is being used as a sphere collision primitive but it's dimensions are not uniform!"
This error indicates that an object marked as a sphere Collision Primitive X length, Y length and Z length are not equal.
Rather than export a collision primitive that doesn't match what you see in Blender the exporter instead raises the error to let you know and provide you the chance to fix it.
Fixing it should be as simple as making sure the sure representing your Collision Primitive is indeed a sphere and not an ellipsoid. Make sure it's [Scale Transform](https://docs.blender.org/manual/en/latest/scene_layout/object/editing/transform/basics.html#scale) is uniform and that you have not made any changes to the vertices or faces that would cause the mesh to cease being a sphere. (Or an approximation of one.)
If all else fails, simply add a new UV sphere or Ico Sphere with the intended radius and location of the problematic Collision Primitive. Then delete the old one and try exporting again.
#### "RuntimeError: Object '\{object name\}' is being used as a cylinder collision primitive but it's X and Y dimensions are not uniform!"
This error indicates that an object marked as a cylinder Collision Primitive X length and Y length are not equal. Cylinder Collision Primitives in .msh files require a uniform radius.
Rather than export a collision primitive that doesn't match what you see in Blender the exporter instead raises the error to let you know and provide you the chance to fix it.
In order to fix this first ensure the problematic object's [Scale Transform](https://docs.blender.org/manual/en/latest/scene_layout/object/editing/transform/basics.html#scale)'s X and Y axes have the same value. Then make sure there are no faces/vertices that are outside the intended radius of the cylinder and try again.
If all else fails, simply add a new Cylinder with the intended radius, length, location and rotation of the problematic Collision Primitive. Then delete the old one and try exporting again.
#### "RuntimeError: Object '\{object name\}' has no primitive type specified in it's name!"
This error indicates that an object in your scene has "p_" in it's name, indicating it is a Collision Primitive but does not also contain a Collision Primitive type in it's name.
To solve this error consult the [Collision Primitives](#collision-primitives) section and rename the problematic Collision Primitive accordingly. Usually by adding "sphere, "cylinder" or "box" to the name.
#### "RuntimeError: Object '{object name}' has unknown LOD suffix at the end of it's name!"
This error indicates that an object in your scene ends with what looks like an LOD suffix but that the suffix will not be recognized by modelmunge. This error is purely intended to help catch typos.
To solve this error consult the [LOD Models](#lod-models) section and rename the problematic objects to use the correct LOD suffix.
#### Materials for .msh files must be managed through the added UI panel named "SWBF .msh Properties" is added under the Material context.
Unsurprisingly Blender's modern and sophisticated materials don't map down well/easilly to what .msh files support. Thus seperate properties are provided for all .msh material properties.
See the Materials section in this document for more info.
#### Meshes and Transforms are converted from Blender's coordinate space to .msh file coordinate space during export.
This involves swapping the Y and Z axes and mirroring the X axis. In most cases this should just create the result you expect as the resulting .msh file should be aligned the same way in Blender, ingame (after going through modelmunge) and in Zero Editor.
#### For UV layers and vertex colors layers it is the active layer that is exported.
Unlikely to come up since if you're working on a model for SWBF you're unlikely to have multiple layers to start with but incase you do, there you go.
#### If a scene has multiple "roots" they will be reparented to a new "root" added during export.
This is to make sure the .msh file only has one root in it. Any object that doesn't have a parent is considered a root.
There is no need to explicitly make sure your scene only has one root as a result of this, it is fine to let the exporter add one and perform the reparenting.
#### Object scales are applied during export in world space.
Despite `.msh` files have a field in their transform section for scale it seams to get ignored by modelmunge.
As a result there is no point in even trying to export the scale. Instead it is applied to a the vertex coordinates during export.
The world space scale is fetched for an object and applied to all the vertex coordinates.
#### Object types with no possible representation in .msh files are not exported unless they have children.
Currently the exporter considers the following object types fall in this category. As I am unfamilar with Blender it is possible that more object types should be added.
- Lattices
- Cameras
- Lights
- Light Probes
- Speakers
If an object with one of the above types has children it is always exported as an empty.
#### Objects whose name starts with "sv_", "p_" or "collision" will be marked as hidden in the .msh file.
This should be consistent with other .msh exporters.
#### Dummy frames for the scene root will be included when exporting an animation.
If the scene root is not keyed in the Action(s) to be exported, dummy frames for the scene root with no translation or rotation will be added to the exported animation.
If you wish to import animation data from one or more .msh files or a single .zaabin file, check this box. This will only work so long as you have preselected an Armature! The imported animations will then be added to the Armature as Actions. If an Action with the same name already exists, the importer will replace it.
If the .msh model to be imported has nodes with meshes that are weighted to or animated, the mesh data on that node will be lost upon import. This is because nodes that are weighted to or animated must be converted to bones in an armature, and bones in an armature cannot be meshes. Eventually we will add functionality to preserve the mesh as a specially named child object of the relevant armature bone.
SWBF's rendering engine uses Shadow Volumes for it's shadows. What this means is that the mesh for the shadow is seperate and different from the main mesh. And in order for your model to have shadows you must make the shadow mesh.
modelmunge will handle the actual Shadow Volume generation for you. You just have to make sure you follow a couple rules.
The first is that any shadow mesh in your scene should begin with "sv_", this will mark it as a Shadow Volume.
Next your the mesh for your Shadow Volume should form a completely enclosed mesh. It should have no gaps that let you see inside it.
Finally because of the way Shadow Volumes work for performance concerns it can be advisable to not have your shadow mesh be full detail and instead have it be a reasonable (and believeable of course) low-resolution approxomation of your real mesh.
That's all there is to it. Basically just make sure your shadow meshes' object names start with "sv_", they're enclosed and not wasteful with their polygons. The exporter and then modelmunge will take care of everything from there.
In .msh files any object starting with "terraincutter" results in it "cutting" terrain when it is used as a prop in Zero Editor. Below the results of this can be seen for a cube named "terraincutter_Cube".
For anything that isn't a player model (they get their own collision from the game) or a weapon you'll probably want it to have collision so the player can actually interact with it.
Pandemic's orginal documentation for collision reccomends Collision Primitives wherever possible
and Collision Meshes where you need accuracy.
All collision objects are created by giving an object a special name. Either "collision_\[-flags-\]meshname" for meshes or "p_\[-flags-\]primitivename" for primitives. The Collision Flags are optional.
| Name Examples |
|:------------------ |
| p_-tb-cylinder |
| p_cube |
| collision_-os-mesh |
| collision_mesh |
There is a limit of 64 collision objects per model file. Collision meshes are merged by modelmunge and as a result they only ever take up one slot.
> NOTE: The limit for collision primitives in SWBF1 is 32.
object and are preferred to collision meshes whenever reasonable.
Unfortunately Blender does not seam to have a way to just have a Sphere, Cylinder or Box based on it's dimensions. It has to be a mesh. This a problem because the game defines collision primitives based on their type and dimensions.
In order to provide support for exporting them the addon requires you to follow some conventions.
First all collision primitive objects must start with "P_", this let's the addon know the object is a collision primitive.
Next the object must contain one of the below strings in "Possible Name" column to let the addon know the shape it should use for the primitive. So "p_hitbox" would define a box primitive, whereas "p_icosphere_crithit" would define a sphere primitive.
| Type | Possible Name |
|:--------:|:---------------------------:|
| sphere | "sphere", "sphr" or "spr" |
| cylinder | "cylinder", "cyln" or "cyl" |
| box | "box", "cube" or "cuboid" |
Finally the addon will grab the dimensions of the object and use those as the size of primitive. If the dimenions do not make sense for a primitive type (for instance if the dimensions of a sphere indicate would define it as an ellipsoid) then an error will be raised on export in order to prevent you exporting collision that does not match your visual representation of it.
### Collision Meshes
Collision meshes are for when Collision Primitives are not able to represent the collision accurately. They should be a low-resolution version of the original mesh. In order to provide accurate collisions they should completely enclose the original mesh. (That is no face in the collision mesh should dip below a face in the original mesh.)
A useful tool for quickly making collision meshes is the [Convex Hull](https://docs.blender.org/manual/en/latest/modeling/meshes/editing/vertices.html#convex-hull) vertex tool. For plenty of meshes the convex hull of the mesh will provide believable collisions ingame, be fast to make (you just need to make a copy of the mesh and then Blender can do it for you), perform well and use little memory.
Collision meshes are combined by modelmunge. So if two collision meshes have conflicting flags (like "collision_-os-mesh0" and "collision_-v-mesh1") it is unspecified which flags will be used. If one of the meshes does not have flags like (like "collision_-os-mesh0" and "collision_mesh1") then it's flags will become that of the other mesh.
Furthermore because collision meshes are combined by modelmunge they can not be animated/moved at runtime (they'll move, just all as one part and relative to the objects root only). If you need moving parts (for say a turret on a vehicle) to have collision you must use Collision Primitives.
### Collision Flags
| Flag | Meaning |
|:----:|:----------------------------------- |
| s | Collides with soldiers. |
| v | Collides with vehicles. |
| b | Collides with buildings/props. |
| t | Collides with terrain. |
| o | Collides with ordnance/projectiles. |
> NOTE: SWBF1 does not support the collision flags naming scheme and must instead explicitly call out primitves as being only for soldiers/projectiles/etc in the .odf.
### Vehicles and Collision
Vehicles have a couple special cases with collision. Below there are going to be some references to .odf files since they are where the special cases come from. Explaining .odf files and there place in SWBF's toolchain is outside the scope of this documentation.
The first is that the collision the AI aim at can be customized by setting "TargetableCollision" in the vehicles .odf to the name of a Collision Primitive. Nothing will actually collide with the set primitive. However units inside the "targetable" Collision Primitive will be able to enter the vehicle as though they were touching it.
The second is that if the vehicle has "Body Springs" (through "AddSpringBody" in .odfs) then the collision flags of both Collision Primitives and Collision Meshes will be ignored. Furthermore they actually won't be used at all unless explictly called out in the .odf. The following properties must be used to manually reference all of the vehicles collision primitives.
Using them in your .odf is as simple as using any other .odf property.
```
SoldierCollision = "p_-s-cube"
```
To reference a Collision Mesh using these properties you must do the following. Using the name of the Collision Mesh from Blender/.msh file will not work.
```
SoldierCollision = "CollisionMesh"
```
> NOTE: The above is also how collision primitives must be setup in SWBF1.
Finally vehicles can also set a Collision Primitve to be their "critical hit" spot using "HitLocation" in the .odf.
```
HitLocation = "p_icosphere_crithit 3.0" // The trailing number is the damage multiplier for the critical hit.
Any [Empty](https://docs.blender.org/manual/en/latest/modeling/empties.html) object that begins with "hp_" is treated as a hardpoint by modelmunge. Hardpoints are used as reference points for a variety of things, like attaching a particle effect to a model or setting the seat location of a vehicle to name a couple.
Other empties/objects can be hardpoints but modelmunge must be explicitly told to keep them, see "-keep"/"-keepall" in [Appendix .msh.option Files](#appendix-mshoption-files).
Models can have Level of Detail copies of themselves that will be used by the game instead of the full detail mesh when the model is far away from the camera or is almost out of view of the camera. When properly utilitized LOD systems can cut down on the GPU cost of a scene without compromising the end result.
A Blender object can be marked as being part of an LOD model by using one of the follow suffixes. The table is listed in order of the intended detail level of each LOD model.
> TODO: Document what rendertypes/flags are multipass and cause the model to be drawn more than once. And explain the implications of that.
### Materials.Rendertype
Rendertypes in .msh materials confer unique information about how the material. Such as
if the materials textures scroll or if the material has an environment map.
> One could argue that "rendertype" should be stylized as "render type". I thought about that and decided I'd rather spend time writing the addon than thinking about that.
#### Materials.Rendertype.Normal (SWBF2)
Basic material.
Can optionally have a Detail Map. Tiling for the detail map can specified with Detail Map Tiling U and Detail Map Tiling V.
#### Materials.Rendertype.Scrolling (SWBF2)
Like Normal except the textures have scrolling. Useful for water, monitors with scrolling content, interlaced holograms, etc.
Scroll speed and direction is specified with Scroll Speed U and Scroll Speed V.
Can optionally have a Detail Map. The Detail Map will not be affected by scrolling.
#### Materials.Rendertype.Envmapped (SWBF2)
Uses an Environment Map to show reflections on the model. Useful for anything you want to look reflective or
metallic.
The reflections from the Environment Map are affected by Specular Colour. And if Specular Material Flag is checked then reflections will be affected by the Gloss Map.
Can optionally have a Detail Map. Tiling for the detail map can specified with Detail Map Tiling U and Detail Map Tiling V.
#### Materials.Rendertype.Animated (SWBF2)
Use an animated texture. The animation's frames should be packed into NxN squares where N is the square root of the number of frames in the animation. So a 25 frame animation should be packed into 5x5 squares in the Diffuse Map.
Set frame count with Animation Length and frame rate with Animation Speed.
Can optionally have a Detail Map. The Detail Map will not be subject to animation.
#### Materials.Rendertype.Refraction (SWBF2)
Distorts/refracts the scene behind the material.
The Diffuse Map's alpha channel controls the visibility of the scene while the Distortion Map controls the distortion.
When distortion is not needed but transparency is the Normal rendertype should be used as this one comes at a performance cost.
The Material Flags are not exposed by the addon for this rendertype as most are unsupported by it. The Blended Transparency flag is supported and **required** but is set automatically by the addon.
#### Materials.Rendertype.Blink (SWBF2)
Oscillates the diffuse strength of the material between full strength and a supplied strength.
Blink Minimum Brightness sets the strength of the material's diffuse at the bottom of the "blink". Blink Speed sets the speed of the blinking.
Can optionally have a Detail Map.
#### Materials.Rendertype.Normalmapped (SWBF2)
Enables the use of a Normal Map with the material.
Can optionally have a Detail Map. Tiling for the detail map can specified with Detail Map Tiling U and Detail Map Tiling V.
Enables the use of a Normal Map with the material.
Uses an Environment Map to show reflections on the model. Useful for anything you want to look reflective or
metallic.
The reflections from the Environment Map are affected by Specular Colour. And if Specular Material Flag is checked then reflections will be affected by the Gloss Map.
Can optionally have a Detail Map. Tiling for the detail map can specified with Detail Map Tiling U and Detail Map Tiling V.
Enables the use of a Normal Map with the material. Tiling for the normal map can be controlled with Normal Map Tiling U and Normal Map Tiling V
Uses an Environment Map to show reflections on the model. Useful for anything you want to look reflective or
metallic.
The reflections from the Environment Map are affected by Specular Colour. And if Specular Material Flag is checked then reflections will be affected by the Gloss Map.
These tools currently do not support render types not previously listed. If you select "Other" from the rendertype dropdown menu, you'll be able to set the number value of the exact rendertype you want. Since the meanings of the specific textures and data values are not supported yet for these render types, they will be listed as texture0-3 and data-value0-3 respectively.
Additive transparency, objects behind the material will appear brighter because the material will be "added" on top of the scene.
#### Materials.Transparency Flags.Hardedged
Hardedged/alpha cutout/clip transparency. Any point on the material with an alpha value below the threshold of 0.5/0x80/128 will be discarded. Useful for leaves, flowers, wire fences and all sorts.
### Materials.Flags
#### Materials.Flags.Unlit
Makes the material unlit/emissive. Useful for anything that is meant to be giving light but not reflecting any/much.
Same as 'Unlit' but also enables the use of a Glow Map in the diffuse texture's alpha channel. The material will be significantly significantly brightened based on how opaque the Glow Map is.
Note that despite the name this doesn't automatically create "glowing" materials. What it does do is let you brighten a material enough so that it'll pass the game's bloom threshold (which is set by the map) and then the bloom effect will cause it to "glow".
Calculate lighting per-pixel instead of per-vertex for diffuse lighting.
#### Materials.Flags.Specular Lighting
Use specular lighting as well as diffuse lighting. A Gloss Map in the diffuse map's and normal map's alpha channel can be used to attenuate the specular lighting's strength. (More transparent = less strong).
The Specular Colour controls the colour of the reflected specular highlights, like the diffuse map but for specular lighting and global across the material.
#### Materials.Flags.Doublesided
Disable backface culling, causing both sides of the surface to be drawn. Usually only the front facing surface is drawn.
All textures should be the names or paths to .tga files. SWBF's toolchain does not support .tga files with RLE (Run Length Encoding) compression or paletted .tga files. They should either be 8-bit greyscale, 24-bit RGB or 32-bit RGBA.
The basic diffuse map for the material. The alpha channel is either the Transparency Map, Glow Map or Gloss Map, depending on the selected rendertype and flags.
Detail maps allow you to add in 'detail' to the Diffuse Map at runtime.
Or they can be used as fake ambient occlusion maps or even wacky emissive maps.
See Appendix Detail Map Blending for a rundown of the details of how they're blended in
with the Diffuse Map.
#### Materials.Texture Maps.Normal Map
Normal maps can provide added detail from lighting. They work much the same way as in any other game/application that uses Tangent Space Normal Maps. See Appendix Normal Map Example if you require a rundown of Normal Maps.
If Specular is enabled the alpha channel will be the Gloss Map.
#### Materials.Texture Maps.Environment Map
Environment map for the material. Used to provide static reflections for the model. Must be a cubemap, see Appendix Cubemap Layout.
#### Materials.Texture Maps.Distortion Map
Distortion maps control how Refractive materials distort the scene behind them. Should be a Normal Map with '-forceformat v8u8' in it's '.tga.option' file. See Appendix .tga.option Files.
Fills in SWBF properties of each material used by all selected objects. This operator will only work with materials that have ```Use Nodes``` enabled and will just fill in the Diffuse Map property with the name of the image used by the material's Principled BSDF node.
Generates shader nodes that attempt to emulate the SWBF properties of a selected material. Call this operator by clicking the `Generate Nodes` button found at the bottom of the selected material's SWBF properties panel. Only transparency settings and diffuse texture mapping are currently supported. When importing a .msh file, this operator is automatically called on each material extracted from the file.
You must click the `Generate Nodes` button every time you edit the material properties and wish to see the results. The generated nodes will not automatically update when the SWBF properties are changed.
It is not necessary to call this operator for materials to correctly export.
This guide assumes you have working knowledge of Blender Armatures and deformation with vertex groups, as well as how to create, edit, pose, and keyframe bones in an Armature.
### XSI vs Blender
XSI has a very free-form take on skeletons and skinning. Models can be skinned to other models in a rather arbitrary manner, whereas in Blender, a model can only be skinned if it is parented to an armature and can only skin to bones in that armature.
Moreover, Zero Editor requires that skinned models be parents of their skeletons, which directly contradicts the structure Blender mandates! The exporter works around this by reparenting skinned objects to their armature's parent, and reparenting the root bones of the armature to the skin object. Note in the examples below that the armature's bones are not technically part of the scene's object hierarchy in Blender, as they belong to the armature object itself.
Upon export, skinned objects are reparented to the armature's parent, and the armature skeleton reparented to the main skinned object:
#### Blender
* dummyroot
* Armature
* bone_root
* bone_one
* bone_two
* skinned_obj
* sv_skinned_obj
* skinned_obj_lowrez
#### Exported
* dummyroot
* skinned_obj
* bone_root
* bone_one
* bone_two
* sv_skinned_obj
* skinned_obj_lowrez
### Example Bone Parent Hierarchy
The same goes for objects that are children of an armature, but are parented directly to bones in that armature, as could be the case in a simple door:
1. Animated msh bones can have have geometry. To accomplish this, create a bone in the scene's armature and a mesh object with the same name as the bone. Parent the mesh object to the bone and make sure their origins are equal. When exported, the bone and the mesh object will be merged into one. The inverse process occurs when importing bones with geometry.
Skinning/vertex-weighting in Blender is a very complex topic, these docs will focus solely on your considerations for exporting a SWBF compatible skin.
1. .msh files can weight a vertex to a maximum of 4 bones. When painting weights, ensure each vertex is meaningfully influenced by a maximum of 4 bones. It won't break the exporter if you exceed 4, but the 4 largest weights per-vertex will be kept and renormalized, and the others will be discarded. It is also worth mentioning however that SWBF2 (PC) only appears to supports 1 weight per vertex, despite the toolchain accepting and processing .msh files with more weights.
2. An object will be exported as a skin if it is parented to an armature and has vertex groups. The skeleton will be reparented to the skin object which is not named as a collision or LOD object.
3. As is the case with exporting in XSI, make sure you apply transforms on your skinned objects before exporting!
## Animation
This guide assumes you know how Armatures work, and how to switch between, create, and edit Actions in Blender.
This exporter can convert Actions used by Armatures to animations compatible with SWBF's toolchain. If an armature is found among the objects to be exported, the exporter can include the armature's currently set Action as an animation in the .msh file. As of now, animation via Armature is the only way to export Blender Actions.
When exporting an Action, all frames between and including the first and last *keyframes* of the Action will be included. For example, if the first and last keyframes are 0 and 5, the exporter will record bone positions at frames 0, 1, 2, 3, 4, and 5, regardless of how many frames are actually keyed. Don't worry about using as few keyframes as possible to save a smaller animation as the exporter will record bone positions and rotations for each frame.
If you have armature bones that are weighted to by a skinned object, but you do not wish for them to be exported as part of the animated skeleton, don't keyframe them. The exported animation will only include bones that are explicitly keyframed at least once in the Action.
3. Don't include multiple armatures in one export!
4. Blender's animation speed defaults to 24 fps. If you want to see exactly how your animation will play ingame, set it to 29.97 in the `Output Properties` section of the `Properties` editor.
.msh files aren't actually the model format used by the game engine. In order to get them into the game engine's format they're ran through modelmunge which exports it into the game engine's format.
Some of modelmunge's behaviour when exporting a .model file can be customized by creating a .msh.option file in the same folder as the .msh file. If you had "fountain.msh", it's .msh.option file would be named "fountain.msh.option".
Below is a list of the most relevant .msh.option arguments. There are more than this but they either don't work (-noprojectionlights), are dangerous to use and can cause crashing ingame (-maxbones) or unclear why you'd ever want to use them (-donotmergeskins).
This is used with the "OverrideTexture", "OverrideTexture2" and "WheelTexture" .odf properties.
#### -scale
- Usage Example: `-scale 2.0`
Takes a scale and applies it uniformly to the .msh file as it is exported. Minimally useful.
#### -vertexlighting
- Usage Example: `-vertexlighting`
Marks the .msh file as being vertex lit.
Any vertex colours in the .msh file will be used as static diffuse lighting and any lights in the game marked as "Static" will not affect any mesh in the .msh file that has vertex colours.
#### -nocollision
- Usage Example: `-nocollision`
If the .msh file has no Collision then prevents automatic creation of a Collision Mesh.
Else prevents usage of any Collision Mesh in the .msh. Has no affect on Collision Primitives.
