Assigning materials and textures to environmental and architectural elements, furniture, props, ships, vehicles and weapons - SWTOR-Slicers/WikiPedia GitHub Wiki

In this guide we'll show you how to find the materials and texturemaps of SWTOR models such as mountains, buildings, ships, vehicles, etc, and their interiors, their furniture and other props, and weapons, too (even if the latter are a bit of a special case deserving its own guide). They are all stored in our game assets extraction's resources\art\static folder.

Those models are characterized by their use of the simplest SWTOR material types, typically "Uber" or "Creature" ones. They only need three or four types of texturemap files and a few settings, whose data can very easily be found among our assets extraction files and read with any text editor.

Which makes this the easiest thing to automate, by the way: we have a couple of add-ons that are able to do that at the click of a button. Still, we'll show you how the process works, because that can help you understand SWTOR's ways, solve any unexpected trouble, and even encourage you to try building your own tools.

Overview:

The short version of it is:

1. When you import a SWTOR .gr2 object into Blender, it comes with one or more empty materials, as in just groups of polygons in the object that are assigned a material name. Blender fills those materials with a default Principled BSDF Shader, useless to us.

2. Those materials' names happen to match the names of the .mat files stored in resources\art\shaders\materials. .mat files are human-readable .xml-type files that we can open with any text editor such as Notepad, where we can find:

   • The type of shader they use: usually "Uber" for static objects.
   • Some very basic material attributes such as type of transparency if any, double-sidedness, etc.
   • And, most importantly, which texturemaps to use and their filepaths relative to resources\art\.

3. Knowing that data, we can delete Blender's default Principled Shader from those materials, add the relevant SWTOR shader (produced by our SWTOR .gr2 importer add-on), apply the texturemaps, done!

   …Or use any of the automated Uber material processing add-ons we have, because manually solving all of a player character spaceship's hundredsome materials is mindnumbing stuff (we have some unsung heroes in the Slicers server regarding that).

Let's try an example.

Finding the materials' names in an imported static object:

This is a section of a Copero building, stored in resources/art/static/area/cop_copero/arch as a file named cop_arch_building_01.gr2. Once imported through any of our .gr2 importer add-ons, we can see that it is composed of two meshes, one with four materials assigned to it, and the other one with a single one (by the way: sometimes a material is shared by several objects for efficiency's sake). Each material covers a non-overlapping set of polygons in the mesh they belong to.

If we check the materials in the Shader editor, we'll notice that Blender, by default, has filled them with a generic Principled BSDF Shader and Material Output Node. That's useless to us, but the names of the materials are very much useful: we are going to search for those names in the assets extraction folder where SWTOR stores their descriptions, in resources\art\shaders\materials.

Locating the materials' information:

Let's go for the "cop_arch_building_trims_01" one. The quickest way to do it is through Windows' File Explorer's instant Search. We just copy the material's name from Blender, then paste it in Explorer's search field, add to the name the .mat extension (as there might be other files sharing the name, such as texturemaps, which not always are the ones belonging to this material), and there it is!

(If for some reason Windows Search doesn't seem to find it or is taking it too much time, maybe out of some indexing hiccup, we can navigate to resources\art\shaders\materials and do the search there, or just locate it following the alphabetical order)

Let's open this cop_arch_building_trims_01.mat file with, say, Notepad. This is what we see: a series of opening and closing tags indicating the types of information they enclose, and the information as such. Let's check the most important ones.

What does it all mean:

• Derived refers to the type of material it is and, so, which Shader to apply. As expected, it is an Uber material and shader. That said, it's not unusual to find in static objects some other materials, such as "EmissiveOnly" for holo signage and glass-like bits, AnimatedUV for animated screens, etc. We'll see about them later on.

  (There are many other possible shaders the objects could require: "water", "ice", etc., although those are more typical in exterior environmental stuff. As we don't have Blender equivalents for those yet, we'll have to improvise based on Blender's shader building blocks and what the object's looks in the game suggests)

• AlphaMode refers to how the shader should deal with the opacity channel it will find in one of the texturemaps.

  • None means that it must disregard that information completely.
  • Test means that it should do a simplistic check for whether the greyscale values in the opacity channel are above or below a threshold (typically of 0.5 grey) and interpret that value as fully transparent or fully opaque.
  • Blend, which behaves like the traditional alpha channel in apps such as Photoshop, allowing for semitransparency.

• AlphaTestValue is the threshold used when meeting an AlphaMode of type Test. Yes, we can see that, despite this material being of type 'None', AlphaTestValue shows 0.5. That's just because it's the game's overall default value: in this particular case, we can disregard it.

• IsTwoSided refers to the object's polygons being visible from both sides or only one. We don't need to care for this, as Blender, by default, will show their surface and texture from both sides. But knowing about this is interesting, because it can become very useful when setting up complex scenes inside this kind of objects.

Now comes the truly vital part:

• DiffuseMap: the diffuse color texture map. This is the first of the material's texturemaps and, as we can see, it's followed by a filepath:

  \art\static\area\cop_copero\arch\texture\cop_arch_building_trims_01_d

  These paths in .mat files are incomplete, in the sense that they lack two things:

  • A resources preceding it.
  • A .dds image file format extension.

  So, the path is:

  resources\art\static\area\cop_copero\arch\texture\cop_arch_building_trims_01_d.dds

  (if for some reason we need a lower resolution version of the texturemap, we only have to put a .tiny before the extension, giving us cop_arch_building_trims_01_d.tiny.dds. The .tiny. variants are usually applied to low poly versions of the game's objects)

  So, that was the DiffuseMap. Exactly the same applies to:

• RotationMap1: a file packed with normal map channels plus opacity map and emissiveness map channels. In this case, the file is:

  resources\art\static\area\cop_copero\arch\texture\cop_arch_building_trims_01_n.dds

• GlossMap: a specular color map and a shininess map.

  resources\art\static\area\cop_copero\arch\texture\cop_arch_building_trims_01_s.dds

• For other shaders there could be more texture maps.

If you want to know more about these types of texturemaps (they don't behave the way a 3D artist expects but the way a game artist would), there's a rough description here: A look at SWTOR's 3D materials and their texture files.

As for the rest of the data in the .mat file, we largely ignore it, either because our SWTOR shaders for Blender don't use it or because it has to do with game asset-type practices that don't make much sense in a fully fledged 3D content creation app such as Blender.

Applying the information to the material:

With his data, we can proceed to turn the material into a SWTOR one!

1. Back to Blender, we start by selecting and deleting the Principled BSDF Shader (we keep the Material Output, though).

2. Now we add the relevant SWTOR shader (the .gr2 Importer Add-on provides them just by being installed and enabled in Blender), an Uber one in this case, by either pressing shift-a or using the add menu, and link it to the Material Output node.

3. Then we use the data we gathered from the .mat file to set the Uber Shader's options.

As we see, the Derived menu option is already set to Uber (the Shader can be set to other material types, but it would be very rare to ever need to).

The Shader's default Alpha Mode is None, so, it matches what we need. If the .mat's data would have told us to use 'Test', choosing that option in the Shader's menu would produce a Alpha Test Value slider so that we would be able to adjust it if needed:

It's not necessary in this particular case.

As for the texturemaps, by clicking on each row's folder icons we'll be able to select the files that belong to each category.

Once we are done, we get the areas of the object covered by this material already showing their proper looks.

And from there it's lather, rinse, and repeat for each material. Which is a little terrible thing to contemplate. Which is why we have a couple of tools to do it for us.

Tools of the trade:

So far we have two. They mostly replicate the manual work we just went through, and both of them can work with the most recent version of our shaders and the legacy ones, but there are a couple of differences making each of them suitable to different styles of organization and work.

• ZeroGravitas' SWTOR Tools: this add-on is meant to group several disparate tools that I find useful to have around. One of them is a Named Materials Processor.

  • Its main feature is that it's meant to work within the confines of a resources folder, and so, it takes advantage of knowing its structure and using the .mat file's filepath information to get any needed asset directly, without the need to traverse folders and subfolders. That makes it very quick. It also covers the six main SWTOR shaders we usually deal with (for both inanimate and animated models).

  • Other than that, it adds some conveniences, such as a provisional Principled Shader-based glass-like material for the bits of static objects that contain non-Uber materials meant to look like glass; or the ability to collect collision objects (invisible in the game, but very much visible when imported) so that they are easy to find and delete.

• SWTOR Material Linker: authored by Silver Ranger (zedorcic08), this add-on offers a few distinct features:

  • It allows for having the .mat files and texturemaps involved outside the resources folder's organization, and inside our own arbitrary one. What this means is that, once we have collected both the .mat file and the texturemaps, we can move them somewhere else and get rid of the resources folder if it is filling just too much storage space. This add-on doesn't rely on filepaths: only on the filenames. By giving it a directory as a starting position in its preferences, it will scan its contents (nested subfolders included) until finding what it needs.

  • This add-on applies our current Uber Shader. It also offers the possibility of creating Uber-like materials solely based on Blender's Principled BSDF Shader. The results won't be identical to the game's looks, but they might be more adjustable, given the versatility of the Principled Shader.

  • It can work on selections of objects or on all the objects in the scene, including hidden ones.

  Aside from the usage guide in the add-on's repository, there is this one created by Crunch that includes some screencaptures: How to use the SWTOR Materials Reader.

Hints & Tips:

Not-yet-implemented materials.

Even if the major materials in static objects are typically Uber or Creature (the latter adds reflectivity map features), there are lots of shaders yet to adapt to Blender (many of them are known from the time of SWTOR's public beta, as back then the shader code was present as readable text). Those will take time to add (we are a bit swamped with issues in other areas at the moment). Still, a few are kinda easy to fake with a few basic Blender nodes.

Double Sided objects.

As mentioned before, Blender, by default, will treat single-sided objects as if they were double-sided, so, we'll see objects such as non-thick walls (say, the internal compartments of a player character ship) having an outer side, even if they aren't meant to.

But there are cases in which it can be extremely useful to have Blender treat single-sided objects as such. For example, if we need to setup a scene inside a player spaceship, seeing things from outside her rooms is terribly difficult because their outer sides are being rendered in the viewport. By setting the material to cull their backfaces, we'll be able to see through them in a most convenient way.

For example, this is the Jedi corvette's interior, sans her outer hull. Trying to place characters and other stuff inside would require us to switch to Viewport Shading mode with X-rays toggled on, which wouldn't be that great to look at, or create a Booleaning object to open holes to peek through. That, or put the camera inside and try to move around without constantly pushing ourselves through some wall that blocks our view.

Well, this is what we'd see by temporarily activating Backface Culling in their materials. Everything single-sided in nature, when showing their back at us, would become invisible, letting us see through where it counts.

You can find the Backface Culling switch in the Properties Editor > Material Properties tab > Settings section. Also, the ZG SWTOR Tools Add-on has such a switch in its SWTOR Materials subpanel for acting on whole object selections.

Weapons.

Weapons are a bit of a special case. The handling of the materials is just as we've explained here. It's locating the objects what becomes complicated because some of them are determined by SWTOR's FX system. For that we have a guide: Locating weapons' assets.