RE4UHD SMX Tool 2018

Tools created by Son of Persia

Tutorial prepared by Mr.Curious
Another interesting file that is embedded in the UDAS archive is the .SMX file. This file is responsible for
several functions of the game, most notably its role as intermediary between models and light sources.
Essentially the SMX file can be used to control how light affects a 3d model in game (excluding ITM &
ETM models). There are other functions of the SMX too, like the ability to implement scrolling textures
and the ability to allow some models to move in game. We can also set models to have their polygons to
be seen on both sides.

While the SMX is a very diverse and important tool with modding stages, we aren't always obliged to use
it. It is however imperative in certain instances when we are dealing with models that have transparent
textures as the SMX file is responsible for the arrangement of transparency hierarchies. If we are creating
custom rooms we will most definitely need to use the SMX.

WORKING WITH THE SMX TOOL

Like many tools by Son of Persia this tool simply extracts the SMX into a .txt file that we can edit the
values of however there is no .obj file created by this tool as it is not needed. This file is strictly dealing
with data values and not coordinates of any kind.

Extraction and repacking are as straightforward as using the provided .bat files. These files will instruct
the tool to either repack or extract the file. Make sure to save any changes to the .txt file before
repacking.

A note about the SMD & SMX

Before we get started looking at the SMX.txt file let us first understand the relationship of the SMX with
the SMD file. In the SMD there is a config file called the 'ModelData.txt' file that contains information for
the BIN models that are placed in the game, particularly the model coordinates & scale. There is also one
small section in each ModelData.txt entry that is dedicated to the SMX ID. This entry simply tells the
Game exe which model is assigned to which SMX ID that is listed in the SMX.txt file that is generated
upon extraction. This way we can assign each model an individual SMX ID of its own if we want to, or we
can assign multiple models to the same SMX ID. There is lots of flexibility with this option.

So why use the SMX ?

As explained above we have more control over how a model reacts to light when it is assigned a unique
SMX ID. We may wish to make one model darker or perhaps even change the color balance of the model
without changing the color balance of the light that is affecting the model. We may wish to change the
color balance of numerous models together without having to edit each model. Another common
objective is to calibrate the transparency hierarchies in order that some transparent models come out
looking right.

TRANSPARENCY HIERARCHIES
Transparency hierarchies are basically an arranged hierarchy of each SMX entry so that transparent &
opaque models which are all visible at once can be seen properly when visible in the same field of view.
We use this feature in a way to arrange what is more visible. SMX transparency hierarchies allow us to
decide which model will be seen in the front and which models have the least priority when stacked
against another model.
An example of this is when we have textures that use transparency. How should a model that is
transparent behave when it is seen in front of another model that is transparent? What happens when
there's 3 transparent models? The SMX allows us to decide which model has priority by means of
transparency hierarchy.

It should be noted that some effects will not be visible when seen through other models with transparent
textures (like a window) unless we set the transparency of the models SMX Entry to OpacityHierarchy =
0x1

LIGHT-CONTROL VALUES
This is the meat of the SMX file and it still as eluded the best modders to date. We don't really know how
to makes this work perfectly but there has been some success. One common objective while working
with the SMX is the desire to create a scenario where a light hits one model but not another. This is so
very tricky and I have no concrete answers to share with you how to achieve this. You simply have to
experiment with the LightControl values. Remember that setting all of these to FF will guarantee all
lights are hitting the model.

My guess about this part about the SMX is that the 4 LightControl values combined with Offset[8..11]
represent the amount/direction of /and or type of light that is allowed to touch a model. This is just a
working theory and until some genius or Capcom employee tells us otherwise we simply have to
experiment to get the results we want.

My best results came from copying & pasting the values from other entries in other files to see what
worked best in each scenario. One method I used was to set a light to be all red and have huge radius.
This way when dealing with the LightControl values we can see which lights are hitting which models.
Feel free to take values from other SMX files and see what results you get. Remember this though. A
model can only be affected by a maximum of 6 lights at once.

EXAMPLE OF SMX ENTRY

EntryCount = 12 (amount of SMX entries in file)
# SMX Entry 0
ID = 0x0 (SMX ID as seen in the ModelData.txt file of the SMD file)
Mode = 0x0 (set to 0x1 for rotating models)
OpacityHierarchy = 0x3 (sets hierarchy for transparent models)
Offset[3] = 0x0 (set to 0x2 for double sided models)
LightControl_0 = 0xFF
LightControl_1 = 0xFF
LightControl_2 = 0xFF
LightControl_3 = 0xFF (determines which lights hit the model)
Offset[8..11] = 0x2
Color_R = 0xFF
Color_G = 0xFF
Color_B = 0xFF (sets color range of affected model)
Color_A = 0x0
Angle_X = 0.000000
Angle_Y = -0.000000
Angle_Z = 0.000000
Swing_1 = 0.000000
Swing_2 = 0.000000
SwingIntensity = 0.000000
SwingSpeed = 0.000000
Offset[44..47] = 0.000000
Offset[48..51] = 0.000000
Offset[52..55] = 0.000000
Swing_3 = 0.000000
Swing_4 = 0.000000
Swing_5 = 0.000000
TextureMovement_X = 0.000345 (example of scrolling sky texture movement)
TextureMovement_Y = -0.000000

Assigning scrolling textures

To assign your texture to be scrolling we use the TextureMovement offset. Make sure your model has
only one texture assigned to it otherwise all textures of that model will be scrolling. If we want to isolate
one area of a model to have the texture scrolling it must be exported as its own unique model and
assigned a unique SMX ID.

example of SMX entry with scrolling texture:

# SMX Entry 0 - scrolling sky txture

ID = 0x1
Mode = 0x0
OpacityHierarchy = 0x3
Offset[3] = 0x0
LightControl_0 = 0xFF
LightControl_1 = 0x1D
LightControl_2 = 0xFF
LightControl_3 = 0xFF
Offset[8..11] = 0x2
Color_R = 0x9B
Color_G = 0x9B
Color_B = 0x91
Color_A = 0x2
Angle_X = 0.000000
Angle_Y = -0.000000
Angle_Z = 0.000000
Swing_1 = 0.000000
Swing_2 = 0.000000
SwingIntensity = 0.000000
SwingSpeed = 0.000000
Offset[44..47] = 0.000000
Offset[48..51] = 0.000000
Offset[52..55] = 0.000000
Swing_3 = 0.000000
Swing_4 = 0.000000
Swing_5 = 0.000000
TextureMovement_X = 0.000980
TextureMovement_Y = -0.000000
Rotating & Swinging Models
Another interesting feature of the SMX file is our ability to make models rotate. It's important to make sure
that we use the ModelData.txt to handle the coordinates of our rotating models because we have to
make sure that the rotating models are placed at 0,0,0, in order that their rotating axis is in the center.
When dealing with moving models we must use Mode = 0x1 with combinations of other values like
Angle parameters. Example:

# SMX Entry 60 - rotating fan

ID = 0x50
Mode = 0x1
OpacityHierarchy = 0x3
Offset[3] = 0x0
LightControl_0 = 0xFF
LightControl_1 = 0xFF
LightControl_2 = 0xFF
LightControl_3 = 0xFF
Offset[8..11] = 0x20
Color_R = 0xFF
Color_G = 0xFF
Color_B = 0xFF
Color_A = 0x0
Angle_X = 1.160428
Angle_Y = -0.000000
Angle_Z = 0.000000
Swing_1 = 0.000000
Swing_2 = 0.000000
SwingIntensity = 0.000000
SwingSpeed = 0.000000
Offset[44..47] = 0.000000
Offset[48..51] = 0.000000
Offset[52..55] = 0.000000
Swing_3 = 0.000000
Swing_4 = 0.000000
Swing_5 = 0.000000
TextureMovement_X = 0.000000
TextureMovement_Y = -0.000000

Other models that move are those that sway or swing are quite similar but use Mode = 0x2. These types
use different paramters to move the object. Example:

# SMX Entry 63
# plant pots swaying

ID = 0x53
Mode = 0x2
OpacityHierarchy = 0x5
Offset[3] = 0x0
LightControl_0 = 0x7F
LightControl_1 = 0xFF
LightControl_2 = 0xFF
LightControl_3 = 0xFF
Offset[8..11] = 0x0
Color_R = 0xFF
Color_G = 0xFF
Color_B = 0xFF
Color_A = 0x0
Angle_X = 0.000000
Angle_Y = -0.000000
Angle_Z = 0.000000
Swing_1 = 247974.000000
Swing_2 = 5.000000
SwingIntensity = 0.110000
SwingSpeed = 0.110000
Offset[44..47] = 9.967492
Offset[48..51] = 0.130000
Offset[52..55] = 0.090000
Swing_3 = 0.000000
Swing_4 = 0.000000
Swing_5 = 0.000000
TextureMovement_X = 0.000000
TextureMovement_Y = -0.000000

Making Double sided models

There are certain scenarios where we need to have a model illuminated on both sides of its
polygons. This can often save us the trouble of having to duplicate a model's polygons and then
flipping them. A perfect example of when we need to do this is when we have a pot or vase that
we can see down inside. Another example might be a wall that we want to have both sides be
seen without duplicating the polygons and flipping them.

In the example of the vase, if the model is not set to be double-sided only the outward facing
polygons will be visible when we look at it. When looking inside the vase from above we will
essentially see through teh mdoel. In this case the model will look invisible when viewed at certain
angles. This problem can be remedied by using Offset[3] = 0x2. This setting will make the
model’s polygons visible at any angle.

It should be noted that sometimes this function can look strange if we use a model with a
transparent texture. Feel free to experiment to what results you get. You may wish also to change
the OpacityHierarchy value if things don’t come out looking right.

Beware of some SMX entries

As explained in the SMD tutorial, some models that move in the game are assigned a special SMX
ID which cannot be absent if we want the game to load properly. These entries are linked by
scripts to the game exe for particular rooms. We should not overwrite these entries if we want
things the game to load. To know if any particular SMX entry is already assigned this special
status, make sure to check your extracted ModelData.txt to locate any entries that have
Offset[68..71] = 0x9. These type 0x9 SMD entries are assigned to moving models via scripts so
it's best to not delete these entries in the ModelData.txt or their corresponding SMX entries.

Although these special SMX entries are linked to the moving models, it does not seem that any of
the values in these entries actually play any role in the moving model behavior. The truth is we still
don’t understand why or how the SMX really interacts with these 0x9 type SMD entries other than
being essential for the loading of the SMD file. If we are dealing with a room that has these type of
events, its best to just ignore them and work with other entries.

CREATING NEW SMX ENTRIES

Whether we are creating custom rooms or simply adding a new model to a room and we wish to
have new SMX entries for our new model(s) we may wish to have full control of how each model is
affected by lights. If we want to have full control of each model then we must have a unique SMX
entry for each model that is shown in the ModelData.txt file that is generated from the extracted
SMD file.

First we must always update the EntryCount for each new SMX entry that is added. Also we must
remember not to overwrite (or use the ID as) any of the entries from the ModelData.txt file that
have Offset[68..71] = 0x9.

If we simply do not want to use the SMX the game will still load the models. Also, as a default we
can assign models SMX_Entry_ID= 0xFE in the ModelData.txt file if we arent sure which SMX to
assign while working.

Conclusion
This file is fun to play with so feel free to experiment to see what results you get.

Happy Modding!
Mr.Curious
12 - 2018
https://www.youtube.com/user/kalamalkakid/
http://residentevilmodding.boards.net/user/5592