Assembling Multi Part Assets (Decorations, Rooms, etc)
This Guide is still under development but is considered to be in a useable state.
Incomplete sections are marked with an exlimation mark (!) before their importance level.
This guide will focus on finding and assembling assets which are comprised of multiple sub-objects and are not default orientated for assembly in Blender. This is useful for assembling Stronghold decorations and some vehicles which can be easily searched on TORCommunity. By the end of this guide you should have a basic understanding of SWTOR GUI Slicer's 'Node Viewer' feature, how models are assembled in game, and how to translate SWTOR's coordinate system to Blender's coordinate system. We will also be covering the different types of decorations, and the difference between SWTOR's and Blender's coordinate systems.
Additionally, there will be two recommended tutorial decorations to assemble which I highly recommend doing as it will teach you everything you need to know about assembling assets in Blender.
For the entirety of this guide I'll do do my best to refer to rooms, decorations, structures, etc. that you would find in SWTOR as 'assets' to differentiate them from Blender's objects. These assets can be comprised of a single object, or multiple. This will be explained in greater detail below.
The first part of this guide is more informational than practical, if you want to skip straight to the nitty gritty, please scroll down to 'Translating SWTOR Coordinates to Blender (Critical)', although I would recommend reading through the guide in its entirety as this is a fairly complex process. Additionally, just because this guide as been written in a way that makes sense to me, does not mean it will you. Please reach out via the Slicer's Discord if something is confusing, wrong, or could be worded better.
- Slicers GUI
- GR2/SWTOR Importer Plugin (Current or Legacy)
- Blender Software
- Access to TORCommunity
- You have a Full and up-to-date Extract of SWTOR from the GUI Slicer tool.
- You're already familiar with importing GR2 files and Blender's coordinate system.
- You're familiar with the basics of parenting objects to skeletons/other objects.
- You're capable of applying Shaders and Textures to objects in Blender.
When importing models from SWTOR there are four different.
- Single GR2, single object, assembled.
- Single GR2, multi object, positioned.
- Multi GR2, multi object, positioned.
- Multi GR2, multi object, un-positioned.
The following section of this guide will explain them so you understand the difference, and why there's no 'simple fix' for importing assets. All images in this section can be clicked on to expand so you can see the Blender object names with the object itself.
|
These assets are the easiest to work with, simply find the GR2 file you want, import it into Blender, and you're set to go. Even if the asset made up of multiple different 'parts' from a world perspective, they're still all bundled together in a single object. Because of this, any transformation, rotation, or scale changes you make effect the object in it's entirety. An example of this is: \art\static\area\all_all\item\caves\all_item_caves_mushroom_03.gr2 |
 |
|
Typically identified by 'mash' or 'mashed', these assets are easy to find and reasonable easy to work with as all objects required to make up the asset are all neatly packed into a single GR2 file. That means when you import the file, you'll be surprised with a collection of various parts all perfectly positioned which all share the same origin. If you try to transform any part of this object however, it will separate from the rest. To get around this, it's recommended to group all the objects together and parent them to the 'main' portion of the decoration to keep the asset bundled together. For example, food items to a plate. This can be done the same way we parent outfit objects to a skeleton, but rather than using a skeleton we're simply using another object. An example of this is: \art\static\area\all_all\item\misc\all_items_misc_mash_food_plates.gr2 Many screens, consoles and windows are also examples of this which all come with their own MultiUVExtraction object. |
 |
|
Objects that make up these assets are spread out over multiple GR2 files which all share the same origin, and are easy to assemble and reasonably easy to work with (once you've finished your scavenger hunt). The most common example of multi GR2, multi object, positioned objects are the player ships, which when imported into blender mostly line up as you would expect. There are a few exceptions, however, such as the doors which all load in at 0,0,0. Additionally, many of these pieces can be mashed files, with multiple objects being contained in a single file. Whilst it's perfectly acceptable to simply import all the relevant files in one batch, the more methodical method of importing one by one into their own collections may save later confusion as random 'Object00x' files start appearing. Similar to the previous example type, groups can be parented to a single 'main' object for easier transformation in blender. An example of this is: \art\static\area\spc_ps\sith... |
 |
|
The fourth type of object group is, bluntly, a hot mess for us, but efficient from a development perspective. Rather than create entirely new assets, BioWare's Dev's typically take existing objects, smash them together to make an asset, and then tell the game how to assemble them on scene loads. That means when we want to make an asset in Blender, we need to find every single sub-asset which often have nothing to do with each other, import them all into blender, and then position them exactly as they are in game relative to each other with no shared origin, scale, or rotation. Rather than reinvent the wheel however, we can cheat. By using GUI Slicer's Node Viewer we can find all the relevant GR2 files, and transformations required to make these assets. A large majority of what we see in game is this type of asset, whether it be as Stronghold decorations, or world objects such as consoles with a special interactive panels. Recreating them in Blender by hand is by far the most complex and time consuming part of creating a larger scene, and is exactly why this guide exists. An example of this is is the Egg Incubator Decoration. The only downside to this method, is SWTOR and Blender use different coordinate systems, which means we not only need to find all the objects, and manipulate them, we also need to translate from SWTOR's coordinates to Blenders as we manually enter every detail. |
 |
So, what is a Node? Put simply, a node is a all the data required for an aspect of the game. Whether it be a decoration, ability, NPC, or something else. The GUI Slicer tool grants us the ability to inspect these nodes, which allows us to find every piece of information required to assemble an asset. This guide will only focus on Node Viewer from a decoration perspective, and will be used in conjunction with TORCommunity so we can quickly and easily drill down into the various Node Trees that make up the game's structure to find the exact node we want.
This section will focus on the Egg Incubator decoration. The very first thing we need to do is head over to TORCommunity and do a search for Egg Incubator. You should be greeted with the following search results.
It's important to make sure you have the Decoration tab selected (highlighted in green), and not any other tab. Once you've double checked you have, click on the link to the Egg Incubator's database entry and swap to the 'Detailed Data' tab. A large majority of this code is useless when it comes to this guide, but there's a very specific thing we're looking for; the node tree. You can find this under the DecorationFqn heading.
Now we know were to find the Node you should copy the path to the clipboard and then open up Slicers GUI and load the Node Viewer. Simply start up the program like you would when doing an extraction, and click the 'Node Viewer' button.
Please be aware that SWTOR has a lot of nodes to process, so it could take a couple seconds for all of them to fully load. You'll know it's done loading when the number next to the 'Node Tree' heading stops racing towards zero, and vanishes fully. You can now begin to navigate down to the decoration's node, which you found the path for earlier (you did find it yourself, right? Just reading from the screenshot won't help you long term!). If you did find it yourself, and copied it to the clipboard as recommended, you can also jump straight to the node by pasting it into the 'Node-Loader' box at the top of the node tree, and then pressing enter. The node should load up straight away, and you'll now see the following screen. Take a few moments to read through the first dozen or so rows of the table, see what sticks out to you, and then continue on.
This Node can be exported to be opened with your favorite text editor, but for the sake of this guide we're going to use the Node Viewer directly. During your read through you may have noticed four fields of interest.
-
dynVisualFqn, which is a GR2 file - Green Underline. -
dynPosition,dynRotationanddynScalewhich are all X,Y,Z values - Blue Underline.
All the dynPosition, dynRotation and dynScale (dynValues) have data for a coordinates system in them, and will always be a series of three numbers when present which look something like 0.11,0.11,0.11. This are X, Y and Z values respectively for SWTORs Left Handed, Y Up system. Whenever you read these values, always read them as 0.11(X),0.11(Y),0.11(Z)
You'll also notice that this node is huge, and there are dozens of dynVisualFqn rows. To assemble this asset, we'll need to import every single one of them into Blender, and we'll need to transform them per the dynPosition, dynRotation and dynScale values. As mentioned earlier, however, SWTOR and Blender utilize different coordinate systems, so you can't directly copy and paste the values and call it good. We need to manually translate them to line everything up.
When dealing with coordinate systems, there are four main types made up of two different options. Left Handed/Right Handed, and Z Up/Y Up. Functionally, there's little to no difference in how they operate, but it is important to know what system your workspace utilizes as it's vital to orientating models correctly. In the case of Blender, coordinates are Right Handed, Z up. Unfortunately for us, however, SWTOR's HeroEngine utilizes a Left Handed, Y Up coordinate system. This complicates extracting models from the game and interpreting data found in Node Viewer. A visual representation of the four different systems can be found below.
Created by @FreyaHolmer on Twitter
Fortunately for you, all the hard work on understanding and translating SWTOR to Blender Coordinates has been done already. Although it's generally pretty accurate, it isn't foolproof, and there is the occasional exception which will require some manual intervention. We also need to factor in the fact that the GR2 Importer by default rotates all objects by 90d in the X-Axis.
The below table contains the rules you need to know when translating SWTOR's Node coordinates to Blender's coordinates. If a dynValue isn't listed (For example, if a dynVisualFqn GR2 has no dynRotation) it is treated as 0 and no value is entered into Blender.
| SWTOR | Blender | Notes |
|---|---|---|
| dynPosition | ||
| X | X | X in SWTOR is X in Blender. Take the X value from the node and enter it into Blender's X field. |
| Y | Z | Y in SWTOR is Z in Blender. Take the Y value from the node and enter it into Blender's Z field. |
| Z | -Y | Z in SWTOR is -Y in Blender. Take the Z value from the node, multiple it by -1, and enter it into Blender's Y field. |
| dynRotation | ||
| X | X+90 | X in SWTOR is X in Blender, however objects are rotated by 90d. To compensate for this the Importer Plugin automatically rotates everything by 90d for us. If the rotation is 0 or unlisted in the Node, leave it as 90d. If the rotation is greater than 0 in SWTOR, add 90 to `dynRotation` value. |
| Y | -Z | Y in SWTOR is -Z in Blender. Take the Y value from the node, multiple it by -1, and enter it into Blender's Z field. |
| Z | Y | Z in SWTOR is Y in Blender. Take the Z value from the node and enter it into Blender's Y field. |
| dynScale | ||
| X | X | X in SWTOR is X in Blender. Take the X value from the node and enter it into Blender's X field. |
| Y | Y | Y in SWTOR is Y in Blender. Take the Z value from the node and enter it into Blender's Z field. |
| Z | Z | Z in SWTOR is Z in Blender. Take the Z value from the node and enter it into Blender's Z field. |
So whilst we've looked into the Egg Incubator decoration a lot, the first asset we assemble is going to be far more simple - the Imperial Crate Pallet decoration. For a first time assembly experience it's the perfect mix of complex, yet easy to visualize, and you'll be exposed to every combination of Position, Rotation and Scale. All together its nine pieces, so a reasonable amount, but shouldn't take too long to finish and several are duplicates.
We're not going to go over how to find the asset information for this decoration again as the steps to finding this assets Node is the same as the Egg Incubator. If you're not sure, scroll back up and have a read through Nodes, dynValues, and Where to Find Them (Critical). Once you've loaded up the Node in Node Viewer, we can get started.
The very first dynVisualFqn object we're going to add will be the Imperial Locker (item_con_locker_imperial.gr2). You'll notice it has a dynPosition and dynScale row, but no dynRotation. This is a good time to remember that when a dynValue row isn't present, it's treated as 0, except for the X Rotation in Blender which should remain at the default 90d. Make sure your using the Rule Table to translate the dyn X/Y/Z values to the Blender X/Y/Z values, if you're not, you'll realize pretty quickly. Once you've finished with that, you can move onto the next dynVisualFqn object - Oh look, its another Imperial Locker. As we already have one in scene, you can either duplicate it, or simply import another one; the choice is yours. Translate the relevant dynValues to Blender values and hopefully they're now sitting next to each other, ready for the third dynVisualFqn object.
Adding the pallet base should have your asset looking incomplete, but properly aligned like the above picture. If you find that the Imperial Crates are sticking through the Pallet base, or the crates are on the wrong side of the Pallet when viewed from the -Y Scene perspective in Blender, you've made a mistake, and now is the time to double check your translations from dynValues to blenderValues.
If everything looks good, great, go a head and continue on yourself. It's important to finish this asset but there's no need for this tutorial to step through every single object as once you've done a few, you're usually set. There is, however, a catch and an intentional simplification in the Rules Table that leads to a subtle error when assembling this decoration. If you're observant, you may have already noticed that all_item_imp_crate_open.gr2 isn't angled correctly when using a Blender Z Rotation of 135d (-135*-1=135d). If you leave the rotation as -135d and pop that straight into Blender, it works perfectly, but why?
Well, to make this guide easier to follow, and assets to quick to assemble, the equation to find the opposing angle of a rotation has been simplified (and is wrong). What we should actually be doing is (dynYRotation+180) mod 360, but no one wants to whip out a calculator or WolframAlpha every time you sit down to assemble an asset. We're smart enough to recognize something looks wrong, and to manually correct it on the fly. This open crate is a minor example of that, and a very simple fix. You may also notice similar issues with the ore objects as well.
There's no more hidden tricks with this asset, finish adding in all the objects, and you're done. The final step to 'complete' the asset would be parenting all the objects to a single base, in this case, the pallet is a perfect object for that task. Parenting all the objects together will keep the asset assembled when you transform it, making it easier to pose in Blender scenes. To do this all we do is:
- Highlight every object (either from the outliner or viewport display)
- Select
kor_vodl_item_shipping_palletas the Primary Object so it has glowing yellow boarder (SHIFT + L-Click in the Viewport Display, or CTRL + L-Click in the Outliner) - Press CTRL + P and Select 'Object'.
Once you've done that, clicking and moving the Pallet should move everything with it, and your Objects should all get stored under the parent kor_vodl_item_shipping_pallet in the Outliner as well making for a cleaner space.
Congratulations, you've assembled your first asset and hopefully without any major hiccups! Add in your UberTextures and you're 100% done. You should be good to venture out into the wider galaxy and create anything you want straight from Node Viewer using it's dynValues. If you want a real challenge, however, tackle the Advanced Tutorial below where you can assemble the dreaded Egg Incubator.
Now you've successfully completed your first Asset, it's time for something more difficult; the Egg Incubator decoration. This whole guide was put together because of this decoration, and it's complexities. Whilst it generally follows the rules outlined in the above section, there is at least one object that, for some reason, does not. You will notice the occasional oddity when assembling assets where a dynValue just won't line up as you'd expect it to from the Node Viewer. In this case, we have to manually intervene much like with the Imperial Pallet.
As this is such a complex asset built with so many individual assets, this tutorial will focus on some "best practices" to help make assembly of the asset easier.
The more objects you have to import to create an asset, the harder it becomes to manage and find different parts should you need to make adjustments. Additionally, when it comes to appending your created asset into a new scene, it can become even more messy. To keep everything organized, we're going to utilize Blender's Collections feature. From the Outliner window, right click, then select New Collection. Name your new collection Egg Incubator. Once that's done, right click your Egg Incubator Collection and create another three; they should automatically nest under your existing collection. Name these three Base, Pipes, Battery.
Whenever importing new objects, you should sort them into one of these three sub-categories, or import them directly under the Egg Incubator category and manually sort them once you know their purpose. You can also create as many categories as you feel is appropriate, and things can always be reorganized later. Using a Pipes category will also speed up assembly later on as it will allow us to simply duplicate a whole collection to create the mirrored counterpart on the opposite side of the base.
You'll very quickly notice when you begin importing GR2 files from the Node that the very first objects you'll be loading is a series of pipes. Due to the size, and location of these objects, they're terrible for gauging how your assembly process is going. In fact if you scroll through the file you won't find a 'major' object until about half way. Because of this, the best practice is to load in two or three larger objects which will act as the 'base' to structure everything around, and help orientate us. Skimming through the various dynVisualFqn rows you may be able to pick out some larger objects, but as that sort of recognition comes with time and familiarity with BioWare's naming scheme, here's a list to get you started:
all_item_tech_holo_terminal.gr2all_item_con_tank_asy.gr2all_item_tech_controlpanel_keyboard03.gr2
Start by importing and positioning these three objects, and you'll now have an easy to visualize base for your asset.
