Unreal Engine

Referencing

This concept is pretty simple but not always intuitive. The concept of reference is that assets don't need to include other assets within them in order to utilize them. For example, when you apply a material or material instance to a skeletal mesh it looks like you have added it to the mesh; however, you have only told the engine/game where to find the material so it can be used. The same thing applies to materials when you assign a parent to a material instance. The game will inherit all the attributes of the parent item being referenced but the attributes aren't actually held within the material instance.

You can visualize this concept by simply going into an asset and hovering over another asset you have incorporated in it and see the file path to where the asset actually is. If you were to move the asset to a different location and re-check the reference you will see that it has changed.

Referencing and Modding

This is an extremely powerful tool for modders as it allows us to redirect the game by telling it to follow a different file path and lead it to our custom assets or a different asset within the game. It can also save us time from creating an asset (e.g. material or Customize_Item asset) when we have no intentions of changing them.

Important Notes

• In-game references MUST be the same name and in the same position within the editor as they are in the game.
• In-game references MUST NOT be included in your mod; otherwise, it will replace the thing you are referencing with what you put in the mod which may/may not be created correctly and defeats the purpose of referencing
• Custom assets MUST be included in the mod in order to be used, the reference alone is just an instruction and the game will follow the path and find nothing to load.

Inheritance

UE relies on a concept of inheritance in performing almost all of its functions. This is the concept that assets can be based on other assets and automatically contain all of the attributes of the original asset without having to identify this in the new asset. This concept is also synonymous with parenting where the child (or derivative asset) inherits the properties of its parent. This is most evident with how UE handles shaders/materials.

Material Inheritance

UE uses a robust node based material shader simply called a Material (M) or Master Shader. In the material, a dev will indicate some static (unchangeable) and dynamic (editable) functions and parameters. Devs can then make linked copies of these materials called material instances (MI) and can continue to make additional MI from another MI. Although the MI does automatically inherit all of the functionality of its parent, only dynamic functions/parameters will be editable in the MI. Some functions can be overridden; however, if this is done then it will need to recompile it and it will become a unique version of its parent that inherits everything but also incorporates the change.

Inheritance and Modding

At the current time we cannot use "custom" materials. A custom material is just a material that does not already exist in the game which means we can't include it in our mods or create compiled MI's that change static functions. Hopefully, this will not be a forever situation but for now it's important to understand to prevent getting fatal errors when loading your mods.

Luckily, the concept of inheritance is something we can make good use of by creating an emulated MI, what I call a dirty MI, and a scripted MI. All of these types of MI rely heavily on the concept of inheritance.

• An Emulated MI is one where a modder has reversed engineered a material in full or part which allows them to see the changes in real-time. How close it looks in editor compared to in-game is up to how knowledgeable the emulator was when creating it. Anything that the emulator didn't incorporate is automatically inherited by the MI from its parent. Both Umin and I have emulated several materials that are available for use on this GitHub and/or in the modding zaibatsu discord.

• A Dirty MI is also an emulated MI but includes only the very basic things. Its purpose is to rely heavily on inheritance but lets a modder make those specific changes. I call them dirty because they can look very messy in the editor and also have messy results in game if a modder doesn't understand the concept of inheritance.

• A Scripted MI is new to T8 thanks to discord member Peek who has found a way to import materials and material instances thru the use of python scripting. These MI expose all available dynamic functions of the material but are not set up to look accurately within the editor. His script also brings in the game's settings for the parameters which you can change as you see fit but won't know the impact of the change until you see it used in-game.

Dirty MI Scenario

A modder notices that a character has a lower body item Dress that uses MI_CH_pop_btm_dress and looks very nice in game. A modder wants the same look but since they are using it for a custom mesh they want to have a different diffuse/color texture. The modder can create a Dirty MI based on a poorly emulated (dummy) material by adding only the parameters they wish to change. The need to verify that the parameters they add are actually in the material their desired MI is parented to in order for them to work.

The modder creates the Dirty MI by making a material and names it MI_CH_pop_btm_dress (they are using a M instead of a MI because you can't add anything to a MI). They place and name the dirty MI be exactly the same in their editor as it would be in-game. In the material they add a 2DTextureParameter named "BaseColor". They then make their custom MI and set its parent as the dirty version of MI_CH_pop_btm_dress and call it MI_flowerskirt. When they open their MI and set its parent they don't see any parameters to change. This is because you can't just create the parameter, it needs to be connected to it's material stack. They make the change and connect it to base color input in their material and when they open up MI_flowerdress they can now see the BaseColor parameter with whatever default texture they loaded in the dirty MI. They set up their mod and check it out in game but the coloring looks all crazy. This is because they didn't understand inheritance and a or Modders

Physics (Cloth) (In-development)

Physics (Bone) (In-development)

Data Asset / Mod Packaging (In-development)

3d Modelling

ID Masking/Coloring (Materials)

Key Terms to Understand

Textures: Images made up of 4 channels: Red, Green, Blue, Alpha

Channel: Part of a texture that holds values ranging from 0 (black) to 1 (white). These can be fully filled images or greyscale images depending on their intended use.

Flat Texture: The visual combination of all 4 channels.

Channel Packed Texture: A texture built with the intent to use each channel separately rather than as a whole.

Masking: The process of isolating a specific area of a texture.

ID: A specific mask within a texture.

Standard Color Combinations with channels:

• Red = RGB/100
• Green = RGB/010
• Blue = RGB/001
• Cyan = RGB/011
• Magenta = RGB/101
• Yellow = RGB/110
• White = RGB/111
• Black = RGB/000

Common Masking Methods:

Black and White Masks (Flat Texture) 1 ID:

• Black is used as a color or as a part to ignore
• White is the area that will be colored 2 ID:
• Black and white are both used as a separate ID.

• Red and Black are also very commonly used

4 Color ID Simple (Flat Texture)

• Typically uses only Red, Green, Blue, and Black
• Each section of the texture is used as an ID

4 Color ID Packed (Channel Packed)

• Each channel is used and may overlap.
• Values in the channel are typically 0 or 1 with no gradient

8 Color RGBA CMYK ID (Flat Texture)

• Allows for the use of 8 different masks based on the isolation of these primary colors
• This requires the use of a function within the shader to isolate specific color values. For example: C/Cyan is made from

Weight Painting (In-development)

Rigging Concepts (In-development)