Difference between revisions of "SWB FBX Tools"
| (One intermediate revision 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 44: | Line 50: | ||
*'''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:
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.
