Model Hierarchies

The Scenegraph node uses both pickIDs and tags for retrieving and manipulating information on loaded models. As not all models are the same, let’s see the details for each supported model type and what can be expected.

MWX

In a MWX model, pickIDs and tag paths correspond. For each and every pickID, there is one and only one path and they are exactly the same string.

For MWX, pickIDs (and tag paths) are composed in this way: FILENAME|TAG1|TAG2

Examples:

<Mwx name="myMWX" file="user/mwxFile.mwx" />

• pickIDs for myMWX node model would be mwxFile|TAG1|TAG2

• tag path for the same geometry would be mwxFile|TAG1|TAG2

MwxSoup

In SoupMesh models, pickIDs and tag paths do not correspond. PickIDs represent a geometry in the soup of meshes, while tag paths are metadata associated to the model and its geometries.

For SoupMesh, pickIDs are composed in this way: FILENAME|SoupMeshX§uniqueID

where

• X is an integer number, but can be omitted and the pickID will remain valid.

• uniqueID is an integer number and represents a geometry aggregate in the model.

Examples:

<MwxSoup name="mySoup" file="user/soupMeshFile.mwx" />

• pickIDs for mySoup node model would be soupMeshFile|SoupMesh1§333

• tag path for the same geometry would be soupMeshFile|TAG1|TAG2

POPMesh

POPMesh models work in the same way as MwxSoup: pickIDs and tag paths do not correspond. PickIDs represent a geometry, while tag paths are metadata associated to the model and its geometries.

For POPMesh, pickIDs are composed in this way: POP/FILENAME§uniqueID

where

• FILENAME is the name of the popmesh model

• uniqueID is an integer number and represents a geometry aggregate in the model.

Examples:

<POPMesh name="myPOP" file="user/POPMeshFile.common.jpop" />

• pickIDs for myPOP node model would be POP/POPMeshFile§333

• tag path for the same geometry would be POP/POPMeshFile|TAG1|TAG2

RFC

In RFC models, pickIDs and tag paths do not correspond. PickIDs represent a geometry in the model, while tag paths are metadata associated to the model and its geometries.

It is possible that multiple pickIDs could correspond to the same tag path.

For RFCs, pickIDs are composed in this way: ARF/NODENAME§uniqueID

where

• uniqueID is an integer number and represents a geometry aggregate in the model.

Examples:

<RFC name="myRFC" file="user/rfcFile.zip" />

• pickIDs for myRFC node model would be ARF/myRFC§333

• tag path for the same geometry would be ARF/myRFC |TAG1|TAG2

SPC

SPCs don’t support hierarchy of tags, they only feature pickIDs corresponding to scan sections.

For SPC, pickIDs are composed in this way: spc/NODENAME§SCAN

where

• SCAN is the scan file name.

Examples:

<Spc name="mySPC" file=".GameData/Models/user/SPC/" scans="A.lsc,B.lsc" />

• pickIDs for mySPC node model would be spc/mySPC|A

• tag path for the same geometry would be the same.

SGL

The SGL node doesn’t support hierarchy of tags; it features pickIDs corresponding to the replaylog and the segment id coming from SGL.

SGL guarantees that segments are unique.

For SGL, pickIDs are composed in this way: SGL/NODENAME|seg:{SegmentID}

Examples:

<SGL name="sglReplay" file="user\sglReplay\" replaylogs="sglReplay1.sgl,sglReplay2.sgl" />

A pickID (or tag) for the element {40,0} of sglReplay node model would be SGL/sglReplay|seg:{40/0}