Difference between revisions of "SWB FBX Tools"

From MTG Wiki
Jump to: navigation, search
(Created page with "'''FBX import hierarchy''' Appearance nodes: NB. hardpoints need only live on the top level *'''MESH_name''' - .msh top level **HPNT_ - hardpoints **MESH_radar - reserved f...")
 
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
'''FBX import hierarchy'''
 
'''FBX import hierarchy'''
  
Appearance nodes:
+
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:
 +
 
 +
[[File: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
 
NB. hardpoints need only live on the top level
Line 9: Line 15:
 
**MESH_radar - reserved for radar mesh
 
**MESH_radar - reserved for radar mesh
 
*'''CMP_name''' - .cmp top level
 
*'''CMP_name''' - .cmp top level
*{MESH/CMP/LOD}_name - child appearances (written before)
+
**{MESH/CMP/LOD}_name - child appearances (written before)
*Collision nodes
+
**Collision nodes
*MESH_radar - reserved for radar mesh
+
**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.
+
**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
 
*'''LOD_name''' - . lod top level
 
**Test/write shape meshes - bounding volume and test volume for dPVS (MESH_test, MESH_write reserved names)
 
**Test/write shape meshes - bounding volume and test volume for dPVS (MESH_test, MESH_write reserved names)
Line 43: Line 49:
  
 
*'''Materials'''
 
*'''Materials'''
 +
**'''eftFileName''' - The effect file name to be used by the material. e.g. 'effect/theeffect.eft'
  
*'''eftFileName''' The effect file name to be used by the material. e.g. 'effect/theeffect.eft'
+
[[File:effect_attribute.png]]
  
 
'''On referencing:'''
 
'''On referencing:'''

Latest revision as of 13:59, 28 August 2018

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
    • 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

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.