Locating Armor Parts Assets

We are going to show how to find SWTOR's armor gear assets (meshes and materials information) manually.

The steps involved are:

• Obtaining SWTOR's internal IDs for the objects and their materials through either Jedipedia.net or TORCommunity.com's databases.

• Searching those IDs through the fairly human-readable .xml files present among the assets extracted through Slicers GUI or EasyMYP, which will tell us which actual meshes and texture files we must use.

• UPDATED: Using Slicers GUI's Node Viewer to find the re-color data (colors that BioWare applies to old gear parts to create new variations) that, sadly, we can't find through those .xml files. WARNING: Node Viewer is superseded by Jedipedia's File Reader, which is a far more capable tool. Needs a proper guide, though, although the principle is the same.

This guide assumes that we already extracted a collection of Player Character game assets (through the Slicers GUI or the EasyMYP apps).

Obtaining the armor part's ModelID and MaterialIndex

Sadly, we can't get the relationship between an armor part's in-game name (such as "Casual Vandal Jacket") and BioWare's internal naming scheme (ipp.mtx.season4.sexy_v08.chest) through the extracted data. Luckily, thanks to the dataminers and the builders of Jedipedia.net and TORCommunity.com, it's very easy to look for them in those websites. Let's show how it works through Jedipedia, which is the simpler one.

We go to https://swtor.jedipedia.net/en, and introduce in any of its search fields the in-game name of the armor part:

It'll result on a list of occurrences (there might be more than one: different tiers, different game update releases, etc.). In this case, there is a single one:

We click on it and get to the armor part's file:

The bit that interests us is the Appearance panel and the data shown there:

• ModelID: the game's ID for the object. It will lead us to information regarding the paths to the meshes and materials involved.

• MaterialIndex: as the object information can present us with more than one possible applicable material, this MaterialIndex tells us which one to use.

• Attachments: typically, a piece of armor gear is composed of a main mesh object (say, a chest undergarment) and a series of attachments (shoulderpads, pouches, etc.). As, again, the object information usually includes all the possible attachments, we use the Attachments data to know which ones we really need.

• FQN: the "Fully Qualified Name" of the armor part. We'll need it because, sadly, the extracted data doesn't include any way to relate it or any of the other identifying data to the color palette data necessary to correctly re-color the gear. We'll use the FQN to find the color palette's ID through tools such as NodeViewer or NodeBrowser.

  This is necessary in order to give the gear its correct colors. Most of SWTOR's 3D assets are re-colorable: they come with a default color, and then BioWare changes its colors (and other attributes such as their glossiness) to produce variations, or lets us apply Dyes that are a special type of color palette presets. We have posted more information about the way it works here.

If you are afraid this is going to be a slow, laborious process, fear not: by using Windows' desktop search and any text editor with a text search shortcut we might happen to be agile with (Windows' Notepad, Notepad++, etc.) we can zip through this in less than five minutes.

So, let's get started.

The object's assets list

Let's suppose we want to find the assets for a "Casual Vandal Jacket", meant for a male, body type 2 character. The "Casual Vandal Jacket"'s ModelID is 2687044.

Normally, knowing that this is a chest part, we would go to resources > art > dynamic > chest to locate the index.xml file inside that contains all the chest objects' information.

Which is this bit tedious. If Windows has done its work indexing our extracted assets files in the background, we should be able to simply paste that number in a Windows search field and instantly locate the .xml file that mentions that number inside (all these IDs are unique, so at most are mentioned in one or two .xml files at once).

There it is!

We open that file, and do a search for the very same ID, 2687044.

…Which leads us to a block of code headed by that ID, enclosed between the <Asset> and the </Asset> tags.

Let's give it a look.

The object's main mesh

Each asset typically has a main element o "base file". In the case of a game object, the base file is its main mesh. We see this line:

<BaseFile>/art/dynamic/chest/model/chest_jacketskin02_[bt]_archetype.gr2</BaseFile>

It's giving us the path to where this object is stored among the extracted asset files, and yes, we can navigate to where it is, but instead we could copypaste the chest_jacketskin02_[bt]_archetype.gr2 name to Windows' search fields too and save us the aggravation, couldn't we?

Yes, save for a little previous step. See that [bt] bit there?

It's a Body Type wildcard. We have to replace it with the game's internal code for the combinations of characters' bodytypes and genders, because the game has all those variations for each armor part. Instead of, say, BT1, BT2 and so, the code is like this:

• Female BT1: bfa (body female agile or athletic).
• Female BT2: bfn (body female normal).
• Female BT3: bfs (body female strong).
• Female BT4: bfb (body female big).

and

• Male BT1: bma (body male agile or athletic).
• Male BT2: bmn (body male normal).
• Male BT3: bms (body male strong).
• Male BT4: bmf (body male fat 🤨 vs. base female big. It's an easy to miss subtlety).

While at it: the other wildcard we'll typically meet is [gen] for gender. It's replaced with:

• Feminine: f.
• Masculine: m.
• Unisex: u.

Let's suppose we are going to get a Body Type 2 male's chest part. That means using the bmn code.

So, the filename we are going to search for, be it by navigating to the relevant directory or just by searching for it, is:

chest_jacketskin02_bmn_archetype.gr2

There it is! We can copy the file to some folder where to group everything concerning this armor part, and go on with the process.

The object's attachments

After the BaseFile, we meet the Attachments block. It contains lines with ids and filepaths. Sometimes an object has no attachments because the base mesh is all it needs, oftentimes there are more attachments than what the specific armor part needs (to cover for other, more busy versions).

To know which ones we need, we'll use the ids listed in Jedipedia's Appearance panel: it says they are 1002402, 1002403, and 1002398. In this particular case, they coincide with the .xml information. If there would have happened to be more of them, we would discard the ones not mentioned by Jedipedia (or, why not, get them and play with them, too 🙂 )

Just as before, we can either navigate to the directory (it's the same one as before) or do a search for them (there is a ton of files in that directory, by the way, so…). And we can be a bit smart about it. Notice the pattern in the files' names:

• chest_jacket_[bt]_med_sm_a01_arm.gr2
• chest_jacket_[bt]_med_sm_a01_collar.gr2
• chest_jacket_[bt]_med_sm_a01_shld.gr2

This is typical: a common core name (chest_jacket_[bt]_med_sm_a01) with suffixes (_arm, _collar, etc.).

If we take advantage of that, we can put this in Windows' search field (remember replacing the body type wildcard with a "bmn"):

chest_jacket_bmn_med_sm_a01 .gr2 (there is a space where the suffix was)

…And voilá!

We get them all at once with a single search.

Okay. We can see there are two versions of each file: with and without a ".lod" before the extension. What does that mean?

The ".lod" ("level of detail") ones are the lower polygon resolution versions that SWTOR uses when an object is far away enough from the camera for the change in quality not to be noticeable. Usually, we would delete all "lod" objects from our extraction to save hard disk space, but we might happen to want to keep them around: for example, those of us that want to convert SWTOR objects to apps such as Tabletop Simulator could prefer to use those less taxing versions.

So, we put copies of the files in our armor part assets folder, and go on.

The object's material

We see there is a Materials block, containing Material sub-blocks, each having an id, a file path, and a list of ColorSchemes. In this particular example there is just a single one whose id matches the MaterialIndex we found. If there were more, we would choose the id-matching one and discard the rest.

So, the filename the entry points at is chest_jacketskin02_med_sm_a01ac01_[gen].mat. It uses a [gen] gender wildcard. We replace the wildcard with a "m" for male and paste the result in the search field.

Let's open it:

The important parts are:

• The <Derived>Garment</Derived>element that tells us the name of the shader this material uses. We are using those same names for their replicas in Blender, Unreal and other apps they might get implemented into.

• The <AlphaMode>Test</AlphaMode> and <AlphaTestValue>0.5</AlphaTestValue> tells us if the material tests for the existence of an opacity map, usually a channel in the normal map ("RotationMap") file, and what's the criteria for determining what's opaque and what's transparent (in this case, if a pixel in the map is above or below 0.5 gray in a scale of 0 to 1). The Blender versions of these materials are set to that regardless of this information, so it's not something we need to care about.

• The filepaths of the texture files involved in the material and their roles. We have explanations for each type elsewhere in the wiki. For now, we simply gotta have them all!

• Default values for the re-colorable areas' associated palettes (a "palette" is a set of Hue, Saturation, Brightness and Contrast adjustments that turn the object's original colors into the desired ones) and glossiness values. Sadly, SWTOR doesn't store those palettes' IDs here. We'll see how to obtain them further on.

• Other attributes of the material, such as simulated rim lighting. They are being implemented in Blender and Unreal little by little.

The object's texture files

Let's get the texture files. Reading their names, you'll see that they all are fairly similar. Typically, either they all are the same save for the suffix before the extension (_d.dds, _h.dds, etc.), or there are two variants of the name, suffix aside. We can use that to search for all or some of them in a single go or two instead of five searches. So, we copypaste (watch out for wildcards to substitute) and omit the suffix and…

We got three at once, two to go. The ones with the .tiny. in their names are lower resolution versions that the game uses in the lower poly variants of the objects (the ones with a .lod. in their names). The .tex files are short human-readable .xml files describing some of these textures' properties such as the presence of alpha channels and whatnot. We can prescind of them.

Let's get the rest of them.

OK. We are almost done. What we still lack is the IDs of the re-coloring "palettes" we mentioned before. Ideally, the .xml we have examined would tell us that, but it's not the case: SWTOR stores that information in a most definitely NOT human-readable binary file. To examine it, we need to use either NodeViewer or NodeBrowser, the latter, preferably, as its search system is more capable.

The object's re-color palettes

NOTE: The apps mentioned in the following section (NodeViewer, or PugTools's NodeBrowser tool) are now superseded by either Slicers GUI's own Node Viewer tool or Jedipedia.net's online SWTOR File Reader. Their workings are mostly the same, so the following information is fairly applicable to them. We'll update the guide with screencaptures and specific instructions for both tools in the near future.

So, we launch PugTools, make sure that the Asset Folder field (top left) points at SWTOR's Assets folder (the rest don't matter) and click on the NodeBrowser button.

We copypaste the FQN of this object, ipp.mtx.season4.sexy_v08.chest, on its search field and do the deed.

As we can see, the information "node" gives us most of the same information we got out of the ModelID and related .xml file. What wasn't in that file is these:

• AppAppearanceSlotHuePrimary: 1003504
• AppAppearanceSlotHueSecondary: 1003504
• IppColorScheme: 1492799

The AppearanceSlotHues are the ids for the primary and secondary re-coloring areas' "palettes".

The ColorScheme could be even more interesting if we happen to be collecting the assets for a whole armor set, because it'll lead us to all the AppearanceSlotHues for all the armor parts of that set, neatly grouped.

So, we can search our assets collection for 1003504 (by chance, both re-coloring areas use the same color style):

You can see that it appears in two places: in the garmenthue's index.xml folder, and in the ColorScheme too (logical, as the armor part belongs to a set). Let's open the former, and search for the same id inside. We get:

The garmenthue folder is filled with palette information .xml files. As this information says, the one related to the 1003504 id is named garmenthue_jk_h30_p.xml. We search for it:

(the index.xml appearing in the search results is the one we just looked into not a moment ago)

…And open it. It has all the palette information we'll need for re-coloring the primary dye area of the object (and, as it happens, the secondary one, too).

By the way: that same palette information can be gleaned through NodeBrowser. It shows in a more tidy manner, and can be exported, but maybe the .xml version is a bit more copypastable later on.

With those, we have all the assets we need to assemble and texture this piece of armor.

In case we intend to collect the complete set, we might want to see the ColorScheme and get all the AppearanceSlotHues' IDs in one go. We do a search for 1492799…

…And open the index.xml file enclosed in the colorscheme folder. Inside, we look for the same id, and a list will appear with all the primary and secondary AppearanceSlotHues' IDs for each armor part of the Casual Vandal set, which we can search for in the GarmentHues' index.xml.

Conclusion

Alright, yes, this is a bit of a roller coaster ride through the extracted files and other tools. The important thing is that, done once or twice, it becomes almost second nature, and fairly fast.