SMD Tool Tutorial

Tools by Son of Persia

Tutorial by Mr.Curious 2018

SMD tool video tutorial by Mr.Curious is avialble here https://youtu.be/6x6AP0zrl2Q

BRIEF DESCRIPTION OF TOOL FUNCTIONS

The function of the SMD tool is simple. It allows us to to edit, replace, create or remove models that we
see in the game. Also, some of these models can be edited to rotate on an axis, like a windmill model
for example. While some modders may be simply interested in adding a few new models to existing
rooms, there are also those who may be ambitious enough to create entirely new rooms. All of this is
now possible thanks to the good work of Son of Persia when he developed this tool.

CREATING CUSTOM ROOMS

Choosing a room to mod
When we are interested in creating new custom room it is important to understand beforehand that we
are dealing with a limited set of rooms to choose from. There 8 stages and within these stages there
are numerous rooms. Here is a list of the stages in RE4UHD the files of which are located in the main
BIO4 folder:

St0 - unused rooms

St1 - Village
St2 - Castle
St3 - Island
St4 - Mercenaries /Assigment Ada
St5 - Separate Ways
St6 - unused rooms
St7 - unused rooms

It is worth noting that some rooms will not load enemy data properly if we have them loading in strange
order. Other rooms have no corresponding enemy data file and will not load enemy data at all
(St0,St6,St7).
Depending on what kind of scenarios we are interested in creating we will have to choose which rooms
to mod carefully. There are several things to consider before choosing a room:

1 - are we simply adding/removing models from existing rooms without affecting the loading order ?
2 - what kind of enemy interactions do we wish to have in these newly modded rooms?
3 - what kind of effects, events, weather do we wish to have in any custom rooms we create?

Other things to consider when choosing a room

Also it is important to understand that there are certain functions that are 'tied' to many of the existing
rooms. We may wish to consider which kind of events exist in a room before we choose to use it for our
new custom room. The reason for this because we may wish to use some of these events for our new
room. For example, if we wanted to create a custom room with a collapsing ceiling trap we would need
to use a room that already had this event present and build our new custom room inside this room.
Another example is if we wanted lightning to be present in our new room we would need to mod a
room that already has lightning.

To elaborate on this concept we need to understand that each room has a certain set of events that
are particular to that one room. Sometimes we can replicate these events but most times we are not
able to because these events are hardcoded into the rooms by scripts or call functions inside the game
exe.

An example of a function that is tied to a room is the Camp room with the Bella sisters. There is an
AEV event in this room that triggers several things:

1 - the spawning of the Bella sisters once the player enters a certain area
2 - a live cutscene that shows the sisters emerging (one jumping down and the other breaking through
the wall with the chainsaw).
3 - a blocking event that prevents us from entering the hole in the wall where the sister with the
chainsaw broke through.

If we wanted to, we could use and incorporate these pre-existing events inside our new room. (For
example I used the wall breaking event in a modded version of this room to recreate an enemy
breaking through a wall). In this scenario we are able to use the AEV trigger to down these enemies
and a start a cutscene that is controlled by the CAM file. If we wanted to, we could also make use of
the door locking event which requires the camp key.

We are not always able to insert these types of events into rooms without editing the game scripts
(which requires knowledge of coding). Until this type of editing becomes easier (Raz0r is currently
working on some configs we will be able to use with his DLL companion but there are still many
limitations) we need to simply use pre-existing events for some types of events.

There are also other things that are 'tied' to a room such as certain effects. An example of this is the
fountain effect that is present in r20b (garden maze). The trickling water that comes down from the
fountain is unique to this room. Usually effect configs are located the EFF files but sometimes they are
hardcoded in to the game exe, so in this instance we would not be able to replicate this effect outside
of this room.
Other effects (like some lightning and some rain effects for example) are triggered by entries in the
EFF file but can't be ported from room to room. Again, these are events that are specific for certain
rooms so sometimes we need to consider what kind of weather we want our new room to have when
we are choosing a room to mod.

It all comes down to this: this game was never meant to be modded, therefore the programmers did not
write the code so that every room was created equal. Essentially what they did was to have the
producers and artists tell them what they needed on a room-per-room basis making it so that each
room had a unique set of scripts. With this being understood we can't make each room do exactly what
we want. We have to chose the room we want to mod based on the functions and features of the room.
In the future with the help of talented programmers like Raz0r we may be able to insert new scripts into
game memory but presently we are fairly limited in porting certain events from room to room.

How some models are tied to events and/or other UDAS files
Before we start removing/adding/replacing models we should know something about model textures. If
we are to replace exisitng models with custom ones we must understand that there might be pre-
existing relationships to other files that these models might have had, and how they might affect how
our new models behave/look.

For example, if we are to simply empty out the pack file for a room and fill it with all custom textures,
and repack our SMD with all new models, some of the textures may come out looking odd despite that
they are mapped correclty in the 3D application.

The reason for this is that there often effects in the EFF file that call on textures that are located in the
room.pack file, and these effects have their own TextureData file that controls how the texture is
applied. If we have a custom model that uses a custom texture that has the same texture number that
one of these effects is calling, the results can often be undesirable. To avoid this we have several
options:

1 - remove the effect that is calling on the texture (see EFF file tutorial for this).
2 - leave effect textures in place in the room pack file and place all models before and after them to
avoid conflicts.

There are more examples of how models can be tied to events and /or UDAS files, particualrly that of
the SMX file. These relationships to other files are what make may cool things happen, like being able
to use moving models. Please make sure to read the 'Some notes about SMX_Entry_ID values'
section below for more information on thjis special realtionship with the SMX file.

FUNCTIONS OF THE SMD TOOL (and associated files)

Before we get started using the SMD tool let's first observe the files we are dealing with:

This tool works by unpacking the SMD file that is located inside the UDAS archive. This SMD file is not
to be confused with the normal type of .smd model file we are accustomed to dealing with in modding.
This SMD is actually another archive that contains all the BIN models for the room and one TPL file
that serves as an index for all the room materials/textures.

There are a few files that are generated when using the SMD tool:
ModelData.txt file that is generated by the SMD tool that governs how/where the BIN models are
placed in the game.
.tcs file that is generated that shows us if the texture mapping for the TPL has been done properly.
.idx file which serves as an index of all the BIN files and the texture number count.
.OBJ files that are generated for us to edit the models and/or their positions if we wish.
.MTL file that is generated which serves as an index of textures/materials used by the .obj files.

FILE EXTRACTION
To unpack the SMD simply place the SMD file along with the RE4UHD_SMD_Tool.exe and .bat files.
Double click the SMD_Extract.bat file and the tool will automatically generate:

- a new folder with all the BIN models and one TPL file.
- ModelData.txt file.
- OBJ files for all extracted models that we can edit in 3D program along with a master model.obj file
which contains all the room models placed in their proper position/scale/roation as seen in the game.
(We use this for reference only).
- MTL files that list all of the materials & textures used by their corresponding OBJ file.
- an .idx file in the main directory

Once all the files have been extracted we can observe the file naming structure of the models with the
first model starting at 0000.obj then 0001.obj, 0002.obj and so on. The TPL should always be named
1 integer higher than the last model. So for example if the last model number is 0078.obj then the
TPL will be numbered 0079.TPL.
Now that we have unpacked the SMD and have an understanding of how the files are numbered we
can do several things:

- edit existing obj model file(s) save, then repack the SMD
- remove certain models from the SMD and repack.
- add new models and then repack the SMD

We can actually do all of the above if we wish but for beginners I suggest doing one thing at a time until
you get the feel of how it works. This process can get VERY tricky because if the TPL file which is quite
volatile.

WORKING WITH THE TPL FILE

As noted above the TPL file can be very tricky to work with if we are not careful. We must pay strict
attention to detail when working with our texture numbers, and the .idx file. To prepare you for this part
of the process I will explain how the TPL works.

When models are initially extracted a TPL is generated which contains all the textures which are
numbered in ascending sequential order at the bottom of the TPL file (you will not need to look at the
TPL file in hex if you do things right).

When we add new textures it is very important to first make a backup of our existing TPL and to do so
every time we add new models or new textures. The reason for this is that if we do something
incorrectly the changes to TPL file can not be undone. This is what makes the TPL so important in this
process. We must be very careful to write to it correctly or all of our textures will not load properly. I will
expalin more below of two separate methods on how to take good care of our TPL when addding new
textures.

EDITING MODELS
A few important things to know about editing models. There are some polygon restrictions to the tools
(I'm not sure what this is but you can try for yourself). In my experience I have noticed that the tools
work better (and faster) with models that are separated and less than 35000 polygons. I dont mean to
say that if for example we have a chair model that has 3 parts that each part needs to be exported as a
saprate model, but in the case of an entire room it is best to separate the parts to relatively smaller
parts so that the exported models aren't huge file sizes that bog down the SMD tool. It is also worth
mentioning that we have more flexibility with lighting when we have models separated into various
parts via the SMX file (more on this later).

Also worth noting is that the tools work with triangles and not quads so make sure your 3D
application is set to triangles.

To edit a model simply import it into 3dsMax or another 3D application (For this tutorial I will be
explaining the work flow of 3DSMAX but the principles should be universal).

Editing Models - Working with textures & the MTL file

As mentioned earlier its very important that we get all our texture IDs sorted out for the TPL. If we are
not adding any new textures to the models that are being exported we really have nothing to worry
about with the TPL but if we are to add any new textures there are a few things we must do:

1 - the new textures need to follow the same naming principles of all other pack files (numbers from
0000.dds - 9999.dds).
2 - the new texture entries in the MTL file need to be placed in ascending sequential order. To do so
we must edit the MTL file entries so that all the materials are placed in order by their texuture name
order like so:

newmtl Material__139
illum 2
Kd 0.800000 0.800000 0.800000
Ka 0.200000 0.200000 0.200000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ns 0.000000
map_Kd 0024.dds

newmtl Material__119
illum 2
Kd 0.800000 0.800000 0.800000
Ka 0.200000 0.200000 0.200000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ns 0.000000
map_Kd 0025.dds
map_D 0026.dds

newmtl Material__101
illum 2
Kd 0.800000 0.800000 0.800000
Ka 0.200000 0.200000 0.200000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ns 0.000000
map_Kd 0027.dds

newmtl Material__115
illum 2
Kd 0.800000 0.800000 0.800000
Ka 0.200000 0.200000 0.200000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ns 0.000000
map_Kd 0028.dds

you see above that the first material entry has 0024.dds,
the second entry has 0025.dds, then 0026.dds
the thrid entry has 0027.dds
and the last material entry has 0028.dds

This is an example of material entries being ordred by their associated textures in ascending
sequential order

ADDING NEW MODELS

If we are adding new models with new textures we have several 2 ways of dealing with the TPL. We
can use 2 different methods:

Method 1
This method is preferable if we are going to be simply adding or removing models from existing rooms
without making dramatic changes. If we are making entirely new rooms I strongly suggest using
Method 2 below.

Method 1 requires that we rename the TPL file each time before repacking then SMD. What this
method does is updates the same TPL file each time a new model is added and updates the .idx
FirstCustomTextureIndex value to 1 integer above the last texture used by the last model. In
contrast, Method 2 rewrites an entirely new TPL each time the SMD is repacked.

Example of Method 1
For this example in Method 1 we are simply going to be adding one new model to an SMD that
originally had 78 models (with a TPL that was originally 0079.tpl) Our new model that we are adding is
named 0079.obj as the last extracted model was 0078.obj

To make this work we need to rename the 0079.tpl to 0080.tpl since our new model is named
0079.obj. Any new textures included in the new 0079.MTL file should be in ascending sequential
order. This ensures that the TPL entries are in correct order. If we are dealing with adding numerous
new models and textures I strongly suggest using Method2 (see below), because renaming the TPL
and editing MTL file each time is a pain and with any errors you could comprise the intergrity of the
TPL.

If we are to use this method we need to update the FirstCustomTextureIndex value in the .idx file
each time a new model is added (more on this below). This value should reflect the number of the first
new texture that is being added. For example:
We extract an SMD that originally has 78 models and it shows us in the .idx file that there is a value of
FirstCustomTextureIndex = 112. This means that the last model used had it's last texture at
0111.dds and that the SMD tool will write the next texture in the TPL as 112. If we do not wish the
texture of our new 0079.obj model to start at 0112.dds (either because there are other textures
present in the pack file that are being used, like being used for effects or ETM models), then we have
the option of telling the tool where to start from using the FirstCustomTextureIndex value.

For this example we may wish to set the FirstCustomTextureIndex value to = 151 becuase the
textures from 0112 - 0150 are being used by effects. Doing this allows us to skip over blocks of texture
numbers.

So a brief overview of Method 1 is this:

1 - Add new model to our extracted SMD folder named 1 integer higher than the last model.
2 - Make sure all the new materials in the .mtl file of the new model are arranged in numerated
sequential order, meaning that all the materials are ordered in sequence according to the texture
number, starting from lowest to highest.
3 - Add a new entry to the ModelData.txt file for the new model & update the ModelDataCount value.
4 - Backup then rename the existing TPL to one value higher than the last model.
5 - update the FirstCustomTextureIndex value in the .idx file to the number of the first texture used
by the new model.
6 - Repack the SMD, then import new SMD into working UDAS, repack UDAS and replace.

Method 2
This method is preferable if we are going to be making entirely new rooms from scratch or adding lots
of new textures to an existing room. This method requires a different work flow and creates a more
stable process for adding new models. What this method does essentially is to create the first model
with ALL THE ROOM TEXTURES included, so that all the models that follow can be easily exported
wihtout having to update the .idx or TPL files before repacking. This method makes it a breeze to
repack our SMD without worry of damaging the TPL file.

Steps for using Method 2

Import the 0000.obj file (provided with this distribution in the DMY file with TEXTURES folder) into 3Ds
Max. (Later on we will have to move our original 0000.obj file to another number as this DMY file will be
exported as 0000 so that it will load first). This DMY model 0000.obj consists of 256 square planes, 1
for each texture in the pack file (even ones used by the ETM, EFF, and ITM). Below is a picture of how
the textures were assigned to this 0000.obj DMY model.
What this does is creates a stable method of replacing, rearranging, and adding new models without
worrying about the constant need for the TPL to be being updated becuase the first model contains
ALL the textures we are going to need for the following models, and the tool does not create new TPL
entries for the models that follow after 0000.obj as the .mtl for this model contains all the textures
entries used by all models. Having 1 model at the start that contains ALL the used textures creates a
TPL that is solid.

USING THE DMY FILE

The DMY file that has been provided contains 256 plane models, each of which that is assigned a
texture starting at 0000 up to 0255. If you need more than 256 textures for your SMD model then I
suggest you follow the instrcutinons below on how to make your own DMY file. If you do not need more
than 256, then all you need to do is the following:

1 - Import DMY file into 3dsMax. If 3DsMax asks for the location of the textures on import (or says that
there are mssing materials), point it to the DMY file with TEXTURES directory located in the Default
3DsMax scene folder included in this distrbution. In 3Ds Max we can also go to 'Customize--
>Configure User Paths-->External Files Tab and set the directory of the DMY file with TEXTURES
directory.

Once the models are imported they will all be assigned a texture. All we need to do at this point is to
look at how many textures our room has inthe .pack file and export the same amount of planes from
the DMY model. Example:

Our room pack file has 147 textures (starting at 0000-0146). This means that we only need to include
planes 000-0146 when we export the model as 0000.obj. This tells the SMD tool that there are 147
textures being used. Once we export this model any model that follows can be assigned any of the
textures without us having to worry about the order of materials in the MTL files that are exported for
each model.

For this process, each time we add new models & repack the room SMD file we will delete the TPL file,
making sure that the .idx file is always set to: FirstCustomTextureIndex = 0 (more on the .idx file
below in Repacking the SMD file). If we arent adding any new models but simply editing models that
already packed into the SMD there is no need to delete the TPL).

ADDING NEW TEXTURES

If we want to add new textures at any point we can simply include more planes to the DMY model
0000.obj and export it with the new textures applied. If we need more than 0256 planes for more than
256 textures (this would rare), we woudl have to clone the LAST PLANE first (example... we would
clone plane 0255 and it would be a new copy named 0256), then copy 0256 to get 0257 and so
on.This would ensure that each plane is named properly and that the materials associated with it are in
the correct order for the MTL file. We would repeat this process as many times as we need until we get
the amount of planes needed to match our .pack file.

Remember; if we arent using more than 256 textures for models,then we do not need to add more
planes. We simply assign new textures to planes that already exist in the 0000.obj model taht was
imported.

MAKING YOUR OWN DMY FILE

(skip down to Repacking the SMD file if you are using the DMY file provided)

If for some reason we need more than 256 models and updating the DMY file provided isnt working we
can create our own DMY model. While doing this we need to make sure that the order of the textures is
in correct order. Using the steps below will ensure that the texture order is in correct order:

1 - create a layer in 3dsMax and name it 0000 for your first model.

2 - In this layer, create a plane (use only 4 vertices to reduce polycount by using Length Segs and
Width Segs to 1) and make sure it's named plane000.
3 - copy/paste this plane (make sure it's a copy not instance). 3dsmax should automatically wish to
name this new plane 'plane001' if not, manually make it so, and the next time it should do it
automaticly.

4 - do step 2 again, copying/pasting plane002 etc. Do this over and over until you have as many
planes as you need for all your textures. (You can copy/paste more than 2 at a time but make sure you
always copy from the last bunch and not the first as the order of the textuers will get screwed up.

5 - Drag and drop all the textures one by one from the extracted folder of your pack file in windows
explorer to each plane in the viewport (yes this is tedious.. that's why I made a DMY for you)! This will
automatically assign the textures the plane and create a material for it. Remember to drag and drop
0000.dds to plane000 and 0001.dds to plane001 and so on.
6 - Once all the textures have been dropped to the planes in ascending sequential order, export the file
as 0000.obj to the working direcotry where we first extracted the SMD file (make sure you back up the
original 0000.obj file in case you want to use it later). Now observe the new 0000.mtl file and make
sure all of the texture entries are in ascending sequential order as outlined above in the Editing
Models - Working with textures & the MTL file section of this tutorial.

If the texture number order in the MTL isn't in ascending sequential order automaticaly you proabably
made one of the following mistakes:

- copy/pasted the planes wrong,

- the planes weren't named in proper sequential order
- you dragged a texture file onto the wrong plane.

In any case you can go back and start over by simply re-dragging-dropping all the textures again, or
you can do as described in Method 1 and rearrange the entries maunally in the MTL so that the
textures appear in ascending sequential order. Once the materials are arranged by texture number in
ascending sequential order you are safe to repack your model and now any models using these
textures will not have to have their MTL files edited in any way.

Repacking the SMD file

Before we go ahead and repack the file we need to edit another 2 files:
The ModelData.txt file and the .idx file. first lets have a look at the ModelData.txt file (this may seem
like a long read but this is a very important part of the process) =)

Working with the ModelData.txt file

As mentioned above the ModelData.txt file is responsible for the placement and scale of the models in
the game. There are also other parameters that we can edit to change the behaviour of the model with
arrangements that coincide with other files in the UDAS archive, in particular the SMX file. First let's
look at at an example of the ModelData.txt file output:

ModelDataCount = 210
# Model Data Entry 0
# Model Number 5

Translation_X = -1168.552002 (model position)

Translation_Y = 3097.150879
Translation_Z = 0.000000
Rotation_X = 0.000000 (model rotation)
Rotation_Y = -0.000000
Rotation_Z = 22.745286
Scale_X = 11.977829 (model scaling)
Scale_Y = 9.363754
Scale_Z = 10.000000
BIN_Number = 0x5 (model number in HEX value)
Offset[38] = 0xFF
SMX_Entry_ID= 0xD (this is the corresponding SMX ID in the SMX file)
Offset[40..43] = 0x0
Offset[44..47] = 0x0
Offset[48..51] = 0x0
Offset[52..55] = 0x0
Offset[56..59] = 0x0
Offset[60..63] = 0x0
Offset[64..67] = 0x0
Offset[68..71] = 0x8 (model type)

# Model Data Entry 1

# Model Number 6

Translation_X = 0.000000
Translation_Y = -0.000000
Translation_Z = 0.000000
Rotation_X = 0.000000
Rotation_Y = -0.000000
Rotation_Z = 0.000000
Scale_X = 10.000000
Scale_Y = 10.000000
Scale_Z = 10.000000
BIN_Number = 0x6
Offset[38] = 0xFF
SMX_Entry_ID= 0xE
Offset[40..43] = 0x0
Offset[44..47] = 0x0
Offset[48..51] = 0x0
Offset[52..55] = 0x0
Offset[56..59] = 0x0
Offset[60..63] = 0x0
Offset[64..67] = 0x0
Offset[68..71] = 0x9

Above we see the main ModelDataCount and then 2 entries that follow. In the example above the
ModelDataCount = 210 indicates that there are 210 entries (I only showed you the first 2 for this
example). The first entry is 0, the second is 1, the third is 2 and so on. Simpy put the ModelDataCount
is an index of how many entries there are in the file.

With the ModelDataCount we can often remove (not always.. see IMPORTANT below) models from
the game wihtout actually removing the BIN model files from the SMD. We can do this by simply
redcuing the value in the ModelDataCount . Imagine that the ModelData.txt is the 'cue file' for the BIN
files in the SMD. BIN files can be present in our SMD file but without the 'cue' to appear in the game
from the ModelData.txt our model will not be loaded in the game. Imagine the BIN files in your SMD
file as your Library of music, and the ModelData.txt is your playlist.

Normally we would think that there would be 1 entry for each model but there are often times that we
see the same BIN model being used repeatedly (like your favorite song repeated 4 times in a row in a
playlist XD). This would explain why there are often many more ModelDataCount entries than there
are BIN models in the extracted SMD folder. At the top of the ModelData.txt config we have the
ModelDataCount value which shows us the number of entries in the config (NOT THE NUMBER OF
MODELS in the extracted SMD folder). Allow me to elaborate:

With the ModelData.txt file we can repeat the same model more than once by making another entry
and using the same model number. We can then place the model in a different location using the
Translation_ offsets...
The reason for this feature was so that if we have numerous instances of the same model we conserve
file/disk space by using the ModelData.txt config to place duplicate models rather than making
duplicate BIN files. You will see this often in cases where there are many repeating models such as
handrail posts, fence posts and trees, bushes etc. Now that computers are much faster and have much
more memory & storage this feature is not as imperative to use as it once was.

Now lets look at some of the offsets we see in the ModelData.txt config

ModelData.txt DATA VALUES

Translation_data
If the all the Translation_coordinates of our model are set to 0.000000 the model's location will be
determined by the model coordinates as they appear in 3dsMax. This is the easiest way to place
models (and the most commonly used method), but there are other instances when we need to use the
coordinate entries in the Modeldata.txt file to position a model instead of the 3dsMax position.

An example of this is when we have a moving model (like a rotating fan for example). In this case we
would place the fan model in 3ds max at 0,0,0 and the use the Translation_ coordinates offest to
position the fan model where we desire. The reason for this is because the rotation axis of moving
models are always centred at 0,0,0,. Another reason to use the Translation_ coordinates to postion a
model as mentioned above is when we want to have a repeating model without duplicating the BIN file
over and over in the SMD.

Rotation_data
The same principles from the previous offset apply to this. I have never rotated a model using this
offest as I always simply rotate the object in 3DSMax.

Scale_data
The RE4 game developers devised several ways to scale models in the game which gives us a bit of
flexibility. The first way is the absolute scale of the physical model that we can manipulate in 3dsMax.
The second is by the Scale_ factor in the ModelData.txt file. For reasons unknown to me we
sometimes see models scaled differently in the ModelData.txt file (x10 for example). For the most part
though models will usually be scaled x1 in the ModelData.txt file. When working with multiple models at
once it is easiest to simply set the scale of all models to x1 in the ModelData.txt file and adjust their
sizes accordingly in 3dsMax.

It should be noted that some rooms use different scales in RE4UHD. Most rooms use x1 , but take note
of all the Scale_entries before editing yor models as sometimes all the models (or most) models in a
room can be scaled x10, or even x100. This is worth paying attention to in the case where we are
taking models from one room and placing them in another. Dont be surpised when your model comes
out looking GIANT, or that it appears to not be there at all becuase it is so small. Paying attention to
scale can often save you lots of headache!

BIN_Number
This is simply the obj file number translated into HEX values.

SMX_Entry
This offest is sometimes not very important while other times it is the most important part of the
ModelData.txt file. What is SMX you ask? Well if you have ever paid attention to all the files that are in
your UDAS archive you will note there is one file with the extension .SMX. This file is repsonible for
several things:

- governing how lights affect models in the game (how a wall is not lit from a light on the other side of
the wall)
- governing scorlling textures on models (like when the clouds appear to move acorss the sky)
- governing the movement of moving models (how fast a model rotates, like a rotating windmill)

So why is this part of ModelData.txt file? Well, as stated above we might want our model to move a
bit, or we might want the texture that is applied to it to scroll slowly (or maybe really fast)! We might
also want to adjust the lighting on this one particular model in a certain way, perhaps by adjuting which
colors are allowed to be lit. The SMX file is very handy for adjusting lighting, but it needs to know which
models are being used, and this is where the ModelData.txt file comes in. The ModelData.txt file tells
the SMX file which models are assigned to which SMX entries.

So if we look at our example above we see that the first Model Data Entry 0 uses SMX_Entry_ID=
0xD. This means that when we edit the ID = 0xD in the SMX.txt config (using the SMX tool) that the
values there will affect the model in ModelData.txt entry 0. Now you see that these tools work together
and often have vlaues that point to each each other.

IMPORTANT
Some notes about SMX_Entry_ID values
Most often there is one SMX entry in the SMX file for each model entry in the SMD file but this is not
always the case. Sometimes models share SMX entries while other times they simply use the default
value of SMX_Entry_ID= 0xFE. Using this deafult value is a safe way to assign a value when we aren't
sure what to do, or have no intention of using the SMX tools in conjunction with the SMD tool.

In any case if we are adding new models we should be aware of which SMX entry they are assigned
to becuase it can drastically affect how the model appears/behaves in the game. For example, if we
reaplaced the sky model in a room with a new wall model and didnt change the SMX entry data, the
texture on the new wall model might be scolling because the SMX entry for the sky was configured to
have a scrolling texture.
Another more advanced issue with SMX entries in the ModelData.txt is that of models that animated
by sciprts. As descirbed above in 'Other things to consider when choosing a room', each room has
scripts that are hardcoded in the game .exe that perform certain fucntions, often in conjucntion with the
models in a room. In particular these sciprts often determine the movement of some animated models
(not to be confused with rotating models that we can do ourselves with the SMX).

An example of this are trap doors that come crashing down when we trigger an event. This movement
is governed by a script in the game .exe, not the data in the SMX file itself, although the game does
assign an SMX entry to the model for this purpose.

This may seem confusing but essentially what happens is that there are certain animated models in
some rooms that are assigned special SMX_Entry_IDs that are linked to scripts in the .exe. These
special models can be changed to whatever model we wish but their SMX_Entry_IDs can not be
removed from the ModelData.txt file or the game will crash. As mentioned above the ModelData.txt
acts as a cue for the BIN model files and when the game scirpts call on one of these special
SMX_Entry_IDs that is missing the game crashes.

So how do we make sure we dont remove one of these special SMX_Entry_IDs that are so important?
The answer is easy.. take a look at the last offset in any ModelData.txt file: Offset[68..71] = 0x9
When the value is 0x9 (or 0xD) this means that the model we are dealing with is an animated model
that is goverened by a script in the game. exe. You will see these kind of entries in many
ModelData.txt files. An example of a model that uses this feature is a cabinet that opens with a
prompt. The sequence of events works like this:

- There is an AEV event that starts when we enter the AEV_triggerzone. It prompts us to 'OPEN' the
cabinet.
- When we press the button to open a mini-cutscene that is in the .CAM file starts (we see a little
camera pan/zoom on the cabinet)
- while the camera is zooming in, the cabinet doors begin to move (the right cabinet door opens and
the left door opens.. 2 separate models, 2 ModelData.txt file entries). This part of the event is
governed by the script that is assigned to the special SMX_Entry_ID. There is one for each cabinet
door (right and left).

Sounds complicated!! kind of...this game has it's quirks but at least we have figured out how to make
things work or at least how to make them not crash. Now this being said we can do all sorts of fun
things like assign new models to these moving SMX_Entry_IDs or we can simply make dummy files
for them and place them somewhere unseen. In any case we MUST KEEP THESE ModelData.txt
entries for the room to load properly.

One method I developed was to simply keyword search the ModelData.txt file for Offset[68..71] = 0x9
(or 0xD) through the entire file before staritng any work on a custom room. I would then cut any entries
that had this value and place them at the top of the ModelData.txt file. I would then delete all other
entries and then update the ModelDataCount to the number of entries that reminaed. This way I could
still load the room without the game crashing. If we want to remove these moving models completely
we can simply make DMY planes for them and hide them where they will not be seen, or as I
mentioned, we can ge creative and make different model for them and place them wherever we like.

WORKING WITH THE .IDX FILE

The final thing we need to take into account when repacking the SMD file is the .idx file which serves
as an index for all the models and pointer to the correct room pack file. Below is an example of the .idx
file opened in a txt editor:
ModelCount = 82
CustomTexturePackNumber = 44000101
FirstCustomTextureIndex = 112
Type = 0
HeaderOffset[16..19] = 0xC49211AA
HeaderOffset[20..23] = 0x0
HeaderOffset[24..27] = 0xC541926A
HeaderOffset[28..31] = 0x0
HeaderOffset[32..35] = 0x3ECB40FB
HeaderOffset[36..39] = 0x0

The only offesets we work with are those highlighed in color in the example above.

The 1st offset is used as an index. When we add or remove models from the extracted SMD folder
they must also be reflected in the .idx file ModelCount parameter. So if our extracted folder has 81
models, the value seen in the idx will be ModelCount = 82 (rememebring that 0000.obj counts as the
first model, 0001.obj as the 2nd model etc..) Ageneral rule that works is that the ModelCount value
should be the same value as the TPL file.

The 2nd offset is used to tell the tool which pack file will be used. This value should never really be
changed, as we usually only deal with extracted SMDs and then edit them from there.

The 3rd offset is of significant importance becuase it tells the tool where to start writing to the TPL file.
If we are using method 1 as outlined in the 'ADDING NEW MODELS' seciton above, this value will
always need be updated to the first new custom texture that is being added. See Method 1 above for
more details. If we are using Method 2 this value shoudl always be set to 0 as the tools will rewrite the
TPL from scratch.

_AR & _GB obj files Expalined

As you may have noticed after extracting your SMD file there are sometimes extracted models that
have the same name, but with different suffixes. Example:

0021.obj
0021_AR.obj
0021_GB.obj

To make give some flexibility for certainmodels the developpers of Resident Evile 4 gave some bin files
a hardcoded custom brightness/colour/transparency values for every vertex. Sounds crazy right? To
explain things a bit more we should know that in BIN models every vertex has 4 bytes of info:
AA RR GG BB (alpha, red, green, blue)

[TIP: If you want to know quickly if a bin file uses those values or not, simply take a look the 23rd byte
If the value is A0 this means that no custom bright/alpha/colour values are used if the value is E0 this
means that the custom bright/alpha/colour values are used.

This is something the developers used to make some models to look brighter/darker than the
surrounding models without the need of messing with LIT/SMX files. They also used this method to
generate transparencies without using alpha channels, and finally, they also used this to change some
models colour (or part of the model) without the need of using different textures.

IN GAME EXAMPLES
Some examples of this can be seen in-game where we see the yellow tiles where Leon & Ashley need
to press at the same time in room 208 (water room) which use a grayish texture you can see all over
the room but these hardcoded values make them yellow. The same method is used in the church lights
puzzle round dials. They have red, blue and green small arrows which all use the same texture but
each model having a different custom colour hardcoded in the vertices. Another example are the
computer screens in the Island Laboratory. The computer screens are separated bin files with custom
lighting bytes.This is what makes them so bright.

An example of this same method but using transparency hardcoded values is in a lot of shadows in
some areas. They are usually just a black mesh model with some of their vertices opacity values set
"0". This generates gradients from visible to transparent without the need of an alpha channel. A neat
trick indeed.

So what are these AR / GB files we see generated by the tools?

The hardcoded custom brightness/colour/transparency values that some bin files have got lost during
the bin-->obj conversion. And there's no way of implementing these values in 3Dsmax and exporting
them again into the newly generated obj file. So, this new 2018 SMD tool generates 2 extra files when
those hardcoded values are used in the bin file:

XXXX_AR.obj
The U mapping values of this file are the Alpha values of the bin file
1.0 = FF (100% visible) 0.0 = 00 (totally transparent)
The V mapping values of this file are the Red values of the bin file (inverted values)
1.0 = 00 (no red at all) 0.0 = FF (100% red)

XXXX_GB.obj
The U mapping values of this file are the Green values of the bin file
1.0 = FF (100% green) 0.0 = 00 ( no green at all )
The V mapping values of this file are the Blue values of the bin file (inverted values)
1.0 = 00 (no blue at all) 0.0 = FF (100% blue)

Steps to use this feature In 3Dsmax:

- Make sure your XXXX model is 100% finished.
- Clone it (copy, no instance)
- Apply Unwrap UVW modifier and edit the UV values according to the Alpha/Red values you want.
(See value charts in the photos below).
- Export as XXXX_AR.obj
- Clone again.
- Apply Unwrap UVW modifier and edit the UV values according to the Green/Blue values you want
- Export as XXXX_GB.obj

This would be useful to make some walls (or part of them) darker. They'd need really low RGB values
or they'd look too bright in game. To understand this further, lets look at an example with a photo:
So to edit the values of each AR & GB file we must edit the UV mapping of our model in 3dsMax:
Here is an infographic that illustrates some various combinations of values to achieve the results below
Easy, isn't it? XD

A note about EFF texture files

It should be noted that if we are going to be replacing models and adding custom textures that in every
pack file there are certain textures that are assigned to effects. This could be for candles, or flies, or
water etc. If we are going to use these texture slots for our own custom textures this is ok but as
mentioned at teh start of this tutorial, the textures on our new models may look strange.

Basically, some effects use textures in the room .pack file each with their own config to scale the
textures. THis means that any texture IDs previsouly used by effects will be affected by teh effect. If we
wish to correct this we have to edit or remove the effect that is calling on the textures that are affected.

So it is important during this process that we keep a copy of the original .pack file extracted so we can
look at which textures are used by effects, and if we need to repalce one of these textures, that we are
aware that an effect is calling on them.

This concludes the SMD Tool tutorial. Be sure to check out the video tutorial here:
https://youtu.be/6x6AP0zrl2Q

Happy Modding!

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