MTG Wiki - User contributions [en-gb]

SWB FBX Tools

2018-08-28T13:59:21Z

Sytner:

'''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:

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

*'''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'

[[File: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.

SWB FBX Tools

2018-08-28T13:44:14Z

Sytner:

'''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:

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

*'''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'

[[File: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.

File:Effect attribute.png

2018-08-28T13:43:49Z

Sytner:

File:Hierarchy setup.png

2018-08-28T13:42:16Z

Sytner:

SWB FBX Tools

2018-08-28T13:33:00Z

Sytner:

'''FBX import hierarchy'''

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'

'''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.

SWB FBX Tools

2018-08-28T13:31:41Z

Sytner: 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..."

'''FBX import hierarchy'''

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'

'''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.

Main Page

2018-08-28T13:26:19Z

Sytner:

Welcome to the MTG Wiki.

Topics:

* [[SWB]]
** [[SWB FBX Tools]]

Main Page

2018-08-28T13:26:05Z

Sytner:

Welcome to the MTG Wiki.

Topics:

* [[SWB]]
** [[SWB FBX tools]]

Main Page

2018-08-28T13:25:15Z

Sytner:

Welcome to the MTG Wiki.

Topics:

- [[SWB]]

SWB

2018-08-28T13:24:24Z

Sytner: Created blank page

Main Page

2018-02-14T18:20:41Z

Sytner: Replaced content with "Welcome to the MTG Wiki. Coming soon!"

Welcome to the MTG Wiki.

Coming soon!