SWB FBX Tools
FBX import hierarchy
The SWB FBX importer works like most other FBX importers - by relying on the user having constructed their model with a particular hierarchy. As an example:
Details described below (mostly planned - most of this doesn't work right now...)
Appearance nodes:
NB. hardpoints need only live on the top level
- MESH_name - .msh top level
- HPNT_ - hardpoints
- MESH_radar - reserved for radar mesh
- CMP_name - .cmp top level
- {MESH/CMP/LOD}_name - child appearances (written before)
- Collision nodes
- MESH_radar - reserved for radar mesh
- CMP in its final implementation is a little bit trickier as we want to ignore global evaluation of transform - can gloss over this for the moment. It highlights the difficulties in referencing also.
- LOD_name - . lod top level
- Test/write shape meshes - bounding volume and test volume for dPVS (MESH_test, MESH_write reserved names)
- MESH_radar - reserved for radar mesh
- {MESH/CMP/LOD}_name - child appearances (written before)
Collision nodes:
- EXT_type_name
- EXT_SPHR_, EXT_BOX_, EXT_MSH_, EXT_CYLN_
- COL_type_name
- Same types available as with extents just one used for collision one used for bounding
- FLOR_name
Portals:
- POB_name - .pob top level
- CELL_name
- PRTL_name - portal list (max one)
- PRTL_name - portals, look at the geometry to determine doors attached
- COL_name - collision root node
- FLOR_name - optional floor
- LGHTS_name - lights list
- LGHT_name
- {MESH/CMP/LOD}_name - appearance
- PRTL_name - portal list (max one)
- CELL_name
Custom attributes
Custom attributes will be used to control the more swg-specific aspects of importing. This is mostly unimplemented, currently support attributes are:
- Materials
- eftFileName - The effect file name to be used by the material. e.g. 'effect/theeffect.eft'
On referencing:
- Assume we want to re-use a model in multiple files, say a door used on multiple pobs. How does that work?
- Best idea so far is simply to rely on naming - onus is on the user to manage their source files appropriately and name nodes in larger creations appropriately so as not to generate disjointedly named duplicates.
- In terms of local (to file) referencing fbx has the notion of instancing and we should harness that. It should be relatively simple to support.