From MTG Wiki
Jump to: navigation, search

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:

Hierarchy setup.png

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
  • COL_type_name
    • Same types available as with extents just one used for collision one used for bounding
  • FLOR_name


  • 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

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'

Effect attribute.png

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.