Unit Models in Rome Remastered
 |
Units in Rome Remastered use the same skeleton, animations and .cas type format as the original game. Remastered allows more detailed units, better 'movement' with vertexes able to be weighted across two bones, and more sophisticated graphical effects using PBR textures.
Feral's tech art guide to Characters provides detailed information on modding units.
Details of how to unpack existing models from the game packs can be found here.
Feral's Cas Converter tool will convert the unit model .cas files to .fbx, IWTE will convert RTW and Remastered models via .dae (Collada) and export in a cas format suitable for Remastered by default. Both tools are primarly designed to work with Blender but the .fbx and .dae formats can be used in other programs such as 3dsMax.
Contents
UV Mapping for Variations
Remastered allows variations of faces, hair and skin textures based on ethnicity. The sections of mesh that use these textures do not need to be in separate groups assigned to the textures, instead the texture used is determined by the relative position of the uv coordinates. The picture below shows a Berserker unit from Remastered with the uv mapping explained.
The textures for the face, skin and hair elements are in a long and thin format with multiple variations that the uv maps tile horizontally across to pick up the variants. The sections of texture selected for hair appear to be determined by the text file descr_unit_variation.txt. The skin and body sections presumably just scroll horizontally through their respective textures.
Ethnic Model Variations
The ethnicity system allows a different model to be loaded for a unit depending on ethnicity. Descr_model_battle.txt has model entries for each soldier type for African, Arabic, Caucasian, EastAsian, Egyptian, Indian & Mediterranean so 7 different models could potential be used per-faction, per-soldier type. If nothing else is specified in the EDU then the game should load the model for the ethnicity your faction uses in descr_sm_factions.
Groups of ethnicities can be assigned to units in the EDU. At the end of the unit 'type' after ownership you can have an ethnicity line per faction, e.g.
ethnicity celts, Wood_shields ethnicity huns, Heaters
would mean the celts use ethnic group 'Wood_shields', and huns would use 'Heaters'
To create a new ethnic group add in the last section of descr_unit_variations.txt code like:
Wood_shields
{
variant
{
ethnicity african
distribution 35
}
variant
{
ethnicity caucasiandark
distribution 65
}
}
This means the unit using 'Wood_shields' will turn up with approx 35% of the African model, and 65% of the Caucasian model (using caucasiandark skin).
There are 12 possible ethnic types that can be used here, they will use the skin/hair/faces of the exact ethnicity specified, but will use the model from the associated major group. The full list of possibilities is as follows:
- african
- arabic
- berber (Arabic model)
- berserker (Caucasian model)
- caucasiandark (Caucasian model)
- caucasian
- culann (Caucasian model)
- eastasian
- egyptian
- mediterranean
- north_african (African model)
- indian
Note that 4 of the skin types actually use the Caucasian model, if you use those for variations you will get different skin/hair/faces but the same models!
All the models within the one soldier type entry in descr_model_battle.txt will use the same texture for that faction. If you have space on the texture you can include variants and map each model differently.
Getting flexibility from this system relies on not needing the original ethnic variety. If you don't need units that look like the berserkers you could give them a copy of the mediterranean skin/faces and use the berserker/mediterranean combination to get two different models to load for all your mediterranean appearance units. If you really don't need certain sections of the skin texture you can move some of your generic cross-faction items there and change the units uv mapping to use it. Units such as fully armoured knights with helms that don't have anything mapped to the skin/face sections could theoretically use a group which selected all 7 possible model types, which would allow 7 different shaped and mapped models which would all be using the same texture.
EDU multiple soldier and upgrade options
From patch 2.0.4 it is possible to specify multiple DMB soldier types to the same export_descr_unit.txt entry. An example using this system can be found in Feral's example mods.
The format is instead of the soldier line you have soldiers. A simple mix would be:
soldiers 60, 0, 1
{
default
{
my_spearmen
my_axemen
my_axemen
}
}
where you would expect to get about two thirds of the unit using the my_axemen DMB entry model/s you can mix soldiers with different animations, but as the sounds and stats will be the same there is a limit to what you can practically mix, and you may also have formation difficulties if you mix movement speeds.
Armour and weapon upgrades can also achieve visual effects using this system. An example for armour upgrades could be:
soldiers 40, 0, 1.1
{
;;default, no armour look
default
{
men_at_arms_padded
}
armour 1
{
men_at_arms_padded
men_at_arms_padded
men_at_arms_chain
}
armour 2
{
men_at_arms_padded
men_at_arms_chain
men_at_arms_chain
}
armour 3
{
men_at_arms_chain
}
}
giving progressively more of the chain-mail clad soldier with upgrade level. You can do the same purely for weapons, or you can add settings for the 16 possible armour/weapon combinations by using:
armour 3, weapon 1
etc as the selector.
Bone Weighting
Unlike RTW Remastered allows full variable weighting for all 'body' components, so each vertex can be weighted proportionately across any two bones.
Primary and secondary weapons however have to each be fully weighted to just one bone. You also CAN NOT have multiple weapon components, e.g. a 'primary' shield on the back of an archer that switches to 'secondary' shield in hand.
Lods
All units must have files named:
- whatever_name_lod0.cas
- whatever_name_lod1.cas
- whatever_name_lod2.cas
- whatever_name_lod3.cas
as the DMB entry is solely to 'whatever_name' and the game then looks up the other lod names automatically. You can however use a lod1 (single weighted version) re-named appropriately if you don't yet have different versions of the model.
