Specs for models to be used in DoW.
This "tutorial" is meant for people who have an experience in modeling and texturing, but who never have modelled for DoW and want to know the constraints to be observed to model something for DoW.
I am not a modeler or animator, so I won't cover the "how to make a model" or "how to make an animation" problem.
00- Essential tools :
3dsmax 6 or higher (previous versions are not supported)
A picture editing program able to handle tga files (Photoshop for instance)
A plug-in to manage DDS files is advised, but not mandatory (see Nvidia site to get a plug in)
Relic's tools are mandatory if you export the mesh yourself, useful if someone else does the export. They are available here :
http://forums.relicnews.com/showthread.php?t=80481 (NB : you must own the game to install them !!!)
Santos Tools are very useful. They are available from this thread :
http://forums.relicnews.com/showthread.php?t=76791
0- The Golden Rule :
The best advice that can be given is to look at the examples given by Relic with the ModTools.
Observing and analysing them solves most problems and explains things better that I can ever will.
1- Folders and files
1.1- Folder path
Respecting Relic's folder path is essential. Even if you don't do the burning yourself, it still must be respected, otherwise, the person who will have to burn your file will have to edit all your paths...
If you are making a model for "unit_X", belonging to "race_Y" that will be featured in mod "mod_Z", you must set a folder like this :
Dawn of War\ModTools\DataSrc\mod_Z\Art\EBPs\Races\race_Y\troops\unit_X
For a building, you must set it like this :
Dawn of War\ModTools\DataSrc\mod_Z\Art\EBPs\Races\race_Y\structures\building_X
In this folder, you must make 2 sub folders.
1st one must be named : Reference
2nd one must be named : Animations
In the 1st one, you must creat a max file called : ref.max
In the second one, you will store your animations. You can name them anything you want.
Textures must be stored in this folder:
Dawn of War\ModTools\DataSrc\mod_Z\Art\EBPs\Races\race_Y\Texture_Share
Warning : even if you are using textures from other races, you MUST add all the textures you use in this folder.
You can add other folders where you can store some meshes that are x-reffed to.
For instance, the Space_Marines race has a base_mesh folder where is stored the "space_marine_unit" from which other space marines are partially x-reffed, but this folder must also have the reference and animations sub folders.
1.2- Files
The ref.max file holds all the basic informations (texture paths, meshes, skin and bones, markers for fx, materials...).
Animation files hold the animations, which means "anything that is different from what is set in the ref file" (see below, part 4).
You don't have to have the same elements in the animation files as in the ref. For instance, you can only have an animated biped with no mesh in the animation file : as long as the biped has bones named the same as in the ref file, the final result will show the ref mesh animated by the animation biped.
You don't have to have any texture in the animation files, except for the animated texture animations.
1.3 Naming conventions
No spaces are allowed. Use _ instead.
2- Models
Only editable meshes are supported. You must convert your editable polys to editable mesh before exporting.
Polycount is around 4000 triangles for a trooper model, including all upgrades, banners and so on.
Models with few upgrades, no banner, etc... can be around 3000 triangles.
Heroes or models with lots of upgrades or random parts can go up to around 5000 triangles.
Buildings are 3000 to 5000 triangles, plus the polycount of the transporter. For instance, the Space Marines HQ is 5000 triangles + 2000 for the ThunderHawk.
All in all, polycount is not a critical issue to memory performances, so you don't have to respect those figures very strictly, but you should try to keep polycount low for units which will be seen in large numbers on the screen.
Meshes that are to be animated must be skinned or declared as bones (see point 5- Special Properties).
In a model where some parts are skinned, non-skinned meshes which are declared as bones should be given the Special Property of "ForceSkinning" (see point 5- Special Properties).
A model can be skinned to any bone hierarchy. Relic uses biped for troopers.
It is advised that a mesh should not be skinned to more than 20 bones, although this is not an absolute maximum. A model that has several meshes can have more than 20 bones in all (for instance, the Guard Basilik has 2 guardsmen, each skinned to a biped, and the bones hierarchy to animate the tank and gun).
All the vertices in a skinned mesh must be skinned to at least 1 bone and no more than 4. Some errors have been reported with vertices skinned to 3 or 4 bones, but if each vertex is skinned to no more than 2 bones, you are on the safe side.
This skinning is normalised.
The exporter often gives an error if one of the weights is too low (0.5/0.5 is OK, while 0.98/0.02 is not). In theory any value is acceptable. Practically, if you get an error for such a vertex, change its values and it should solve the problem.
If you get an error due to skinning problems, the exporter will usually tell what vertices are causing the problem and what is the problem.
In case you already have made all your animations with a mesh whose skin is wrong, you can use Santos Tools to set all those meshes right.
In order to be animated, markers must be attached to bones or meshes declared as bones (if not, the flamer will move, but not the flame, for instance).
Movable unit (infantry, vehicle, monsters...) are attached to a special helper called "master" in the Relic's examples.
It serves to move the unit in game.
/ Added by CLR :
Vehicle Ref setup (Take a look at the predator example) :
The 4 following helpers need to be in the file.
"Tank_Master" : Dummy: Used to move the unit in game
"Body" : Bone: Used to apply overlap and impacts to the chassis
"Right_Tread", "Left_Tread" : Bones : Used to follow the terrain independantly from the body
Note that you don't need the tread bones for hover vehicles, but still need the tank master and body.
/ End of Added by CLR
Markers are usually added to be the starting point of FX (flame, breath, decals on the ground, gun fire, hits, sparks...).
Orientation of the marker is important. Local Y axis should usually point to the direction effect will be played (direction of gun fire for example) but this may be different with some fx.
Some markers are used by the game to make a synchro between the unit and some other units (such as when it impales another trooper) or some elements in game (such as when planting a flag). See the Animations section.
Other helpers can be added, such as manipulators for IK.
You also must include a point helper at the feet of the character and name it "Marker_Icon". The game will use it to position icons for cover or to indicate that it's a builder over its head.
Buildings models, if they are supposed to use stencil shadows the hard edged shadows used for buildings), must have "closed" geometry, or stencil shadows will crash/do a strange result. The same apply to any element that is supposed to use stencil shadow (some maps static meshes does). That is definitely useful to consider from the beginning.
NB : skin modifier disables stencil shadows.
3- Textures
3.1- Texture format :
Relic's exporter works with maps in tga format, with alpha channel.
3.2- Texture size :
It doesn't matter how many times a map is loaded, the memory use is the same. Having 1 soldier or 100 on screen is the same strain on memory as long as they share the same texture map (for what pertains to texture. The polycount, of course, is quite a different problem).
As usual : the smaller the map, the better for memory strain, to be balanced with the level of details you want to be visible (most units will be seen from afar : adding too many details can be useless because they won't be seen, or even detrimental if they clutter the model and make it "unreadable". I know experienced texturers know this but newbies like me may not...).
Textures should usually be in 512x512 format. One model should usually have 1 texture map.
Exceptions :
- small units have smaller maps (64x64 for mines, 512x256 for scouts...)
- big units such as tanks can have several 512x512 maps (3 maps for the Land raider, 2 for the Rhino...)
- some bigger size can exceptionally be used (1024x512 for the Space Marines Ability Building), but 1024x1024 should be avoided if at all possible, since they are reported by CLR to cause issues with the army painter
- some models or model parts are reused for different units. In this case, you can re-use the first map and add the second one.
Example 1 : the Imperial Guard Sergeant uses the regular Guardsman 512x512 map and adds his own 256x256 maps for parts not found in the basic guardsman (head, sword, bolt pistol...)
Example 2 : the Thunderhawk is used as a transport for several buildings : it is modelled separately, with its own texture, and the building has its own texture. The same is true for drop pods or those little bits that help the buildings unfold.
NB : Relic has used different approaches during the development : The Space Marines was probably developped early and crams all the parts needed for the Space Marine, the Space Marine Sergeant, all the Heavy weapon options and the Assault Marines + their sergeant on a single 512x512 map. On the other hand, the Guardsmen and Kasrkin use 2 512x512 and 2 256x256 maps for these 2 units and their sergeants.
I don't know if this has to do with developing team being different, the Game Engine being upgraded, or if, during the time the game was developped, the average video memory of potential gamers is supposed to have increased. Or some other reason.
3.3- Animated textures :
Textures which will be animated (tracks for instance) must have a separated texture map with only the texture to be animated on this map.
3.4- In the texture maps, some parts are to be "teamcolourable", which means the system will build a different colour for these parts, depending on which team the unit is played by. The team colours are set in the Army Painter.
The parts that are to be teamcolourable should be textured as grayscale on the texture map, or at least being dominantly grey 128/128/128 (you can add some bloodstain or some mud, but the effect should stay subtle). These parts will be separated on different layers to be made Army Painter compatible.
3.5- Working material channels :
DoW's engine accepts diffuse and self illumination (ambient) channels.
No bumps, displacement, transparency or such.
Of course, no procedural shaders.
3.6- Transparency :
DoW doesn't manage transparency with textures (you have to use FX for that), but you can set some pixels to be visible or invisible. Semi transparency or transluscence is not possible.
To set a zone as invisible in game, simply paint it black on the tga's alpha channel.
Leave the visible areas white. Don't use grey : it gives weird results at best.
This technique is used on the chainsword's "teeth" maps for instance.
3.7- Multimaterial and badges :
The Army Painter can only add 1 badge per texture map.
If you want the army badge to be displayed on several places on your model, you must make several maps (one for each side of the vehicle, for instance).
For the badge to be added, the texture map must have a square area of 64x64 where the badge will be displayed. The badge will be displayed with no change of orientation : the upper side of the badge image will point towards the upper side of the texture map.
4- Animations
4.1- Generalities :
An "animation" file contains anything that is different from the basic ref file.
You cannot add a mesh, bone or anything else in an animation file and see it in the final result if it is not also present in the ref file.
DoW uses a 30 frames per second rate.
Regarding to timeline, the exporter only exports what he sees in the max file. That means, if your animation goes from frame 16 to 256, and your timeline is define accordingly, it will only export it from frame... 16 to 256. This can be very useful sometime. (for structures build animations for instance)
4.2- What can be animated ?
In an animation file are stored data that are different from the ref file which will add a modification on it.Whatever is not present in the ref file won't be added in the final export. The animations can only modify what is in the ref file, not add or substract from it.
You can have :
- different position of the bones and meshes, with an animation in the usual sense of the term (changing position over time). Only bones can be animated in this sense. To animate a mesh, you have to declare it as a bone (see below : 5- Special Properties).
- different visibility : meshes can be set to be invisible in the max files (see 5- special properties below). Some animations just change the visibility of the mesh, setting it to visible. These are usually called "vis files". If you add a mesh in these files that is not present in the ref file, it won't be exported, though.
- different rigging : you can rig your model differently for a special animation. The exporter will only record the positions of bones present in the ref file, though. You can add IK or helpers for instance.
- different hierarchy : you can make an object attached to another at the start of the animation and detach it or change attachment in an animation. There again, you cannot add a mesh here.
4.3- Default positions :
DoW doesn't calculate transitions between different animations.
So you must set a position that will be the "default" for this unit in certain circumstances. Usually, you need to define one such position for when the unit is idle, when it is in melee, when it is firing, and when it is in cover (if those conditions applyt to the kind of unit you are making).
All animations you make must start and end in this position to get a smooth transition between them.
4.4- Stacking and Overlay animations :
IMPORTANT NOTE : when you are stacking several animations, DoW uses only 1 set of data for each animated thing. It applies to the ref file the data stored in the animation that comes first in the OE stack.
This can have some beneficial effects : You can make several animations to be stacked onto each other in the OE.
Sometimes, you'll want to have an animation that is repeated over several others. For instance, you want to use a running animation made for another character, but add to it different arms movements.
You can make an overlay animation : just animate the arms, and let the rest in stale (see point 5- Special Properties). In the OE, this animation will be stacked upon the others and it will be retained by the Game Engine.
Of course, you can just rework the original animation, and use merge animation to duplicate the changes to different files...
But be warned about detrimental effects : For instance : in your vis file, if you have moved the position of the model's hip to change its position from the basic ref's position, then it means that you cannot combine this vis file with ANY animation using the hip bone.
4.5- Randomising animations :
To make a unit appear more life like, you can make several animations for a single situation for a model.
Usually you have several animations for when the model is idle, but you can also make several fring animations : this works very well for large units which look more life like if the soldiers don't fire all in the same position.
Just make several animations, and the OE integrator will take care of randomising them.
4.6- Different types of animations :
IMPORTANT NOTE : For all of the animations type below, you can make different animations depending on which weapon the trooper is holding (one for the flamer, one for the plasma gun...) or which random parts he has, if those different weapons or random parts compell the model to have different positions. For instance, if 50% of the unit are to be armed with 2 handed hammers, and 50% with knives, you can make melee animations for 2 handed hammer, and animations for 1 handed knife combat.
-- Aim animations : Mandatory for units equiped with ranged weapons.
These are used to point the unit's weapon in the direction of its target squad.
The aim horizontal animation has 37 frames (from 0 to 36). It starts with the weapon facing backwards at frame 0 and goes 360° counterclockwise (seen from front and above), facing backwards again at frame 36. At frame 18, it should point to the front of the unit.
The aim vertical animation has 36 frames. It starts with the weapon facing backwards and being upside down at frame 0 and goes 360° pointing first to the ground at frame 9, to the front at aim 18 (and being in the neutral position), to the sky at frame 27 and to the back again at frame 36.
If this is not clear, just check Relic's example : it's quite easy actually.
You need 1 vertical and 1 horizontal animation for each hardpoint (a hardpoint is a point where one or several weapons are attached).
For troopers, you often have 3 aim_vertical/aim_horizontal sets : one for when the trooper is idle, one for when it is running, one for when it is in cover. You can also have one for when it is ducking fire.
For other special cases, these are to be discussed with the person that will make the export and Object Editor "programming".
IMPORTANT WARNING : aim vertical and aim horizontal should be animated using bones or boned meshes that are specifically dedicated to this task ! If you use the bip spine 1 to do this animation for instance, you must make sure that no other animation changes anything in bip spine 1. Otherwise, you won't be able to combine the aim with another animation. Example : idle_aiming animations are combined with aim animations : don't animate the same bones in these 2 animations (see "stacking animations" above).
-- Tracking animations : Mandatory for units equiped with ranged weapons.
The position assumed by the unit when it tracks an opponent.
These animations are stacked with the aim animations. For instance, the tracking animation shows the trooper aiming in front of him. The aim animation will tell the Game Engine in which direction it should actually point.
Remember to read the "important warning" above.
Usually you have 1 tracking animation for when the trooper is idle, one for when it is in cover, one when it is running.
-- Fire animations : Mandatory for units equiped with ranged weapons.
At frame 1 the weapon fires, then the trooper spends the rest of the animation getting back to its default position and recharge the weapon if need be.
For sustained fire weapons (such as the Heavy Bolter), the weapon fires for the duration of the animation.
Of course, you can make animations where the sustained fire weapon fires for short bursts of fire. This is to be discussed with the person doing the OE integration (since it means different sounds, etc..).
Usually you have 1 firing animation for when the trooper is idle, one for when it is in cover, one when it is running.
-- Idle animations : mandatory for all troops.
What the unit does when it just stays here, waiting for orders.
Usually, there are several such animations, so that the unit appears less uniform.
-- Capture animations : mandatory for units with the ability to capture points.
There are 3 animations to be made :
plant flag 1 : the trooper plants the flag into the point (the animation uses a marker helper so that you know where to plant the flag. See the flag_plant_1 animation in the Marines example). The mesh is away from its master during this animation.
plant flag 2 : the trooper gets back to its default location over its master, and to its capturing position.
capture strategic point : the position that the trooper keeps during the capture of a point.
-- Run animations : Mandatory for all units that walk (including dreadnoughts and such).
The animations should be set so that the footsteps are timed the same way as in Relic's example, since it is the Game Engine which controls the actual speed of the unit.
For some slow units, you may want to have their speed limited by the person in charge of the AE, so that you can make them walk rather than run, but the time between footsteps should be the same.
-- Move : mandatory for all vehicle units or equivalent (eldar gun platforms...).
Used for vehicles.
-- Melee animations : Used for troopers and dreadnoughts. Mandatory for units with close combat capacity.
Attack charge : The unit rushes into melee.
Melee attack : an attack made with the melee weapon. Usually you make several such attacks to avoid everyone in the unit attacking with the same attack at the same time. You should try to have the blow delivered at the same frame as the damage is received in the example animations, so that opponent seem to realy exchange blows.
Melee damage : the unit takes damage from its opponent. You should try to have the blow taken at the same frame as the damage is delivered in the example animations, so that opponent seem to realy exchange blows.
Special Attack : an attack that delivers special damage and effects. It should be represented by a suitably spectacular animation.
SyncKill and syncDeath : see below.
-- SyncKill and SyncDeath : Used for units with close combat capacity. Non mandatory but highly recomended.
In order to add a level of realism, Relic has made this system : sometimes, a trooper will kill another using a special animation that is keyed to a special death animation in the victim. This is called a Synckill.
In order for a synckill to occur, the killer must have a Synckill animation that matches the victim's SyncDeath animation.
Some synckills are character specific (Librarian vs Avatar for instance). To make these you must modify BOTH units. So if you wanted your your new Eldar Avatar to be able to kill the Chaos BloodThirster by braking his spine over his knee, then you'd have to modify both the Avatar and Bloodthirster models and add the correct Synckill to the Avatar, with the correponding SyncDeath to the BloodThirster.
This is a lot of work, so it is better to save it for uber units or special foes.
Since many kind of troops can fight against each other, it would be a huge work to have each troop having a special killing animation against each kind of possible opponent, so these types were standardised. In a Synckill/Syncdeath type 1 for instance, the blow will be always delivered at the same frame, whatever troop is killing the other. So, if you make a Synckill death and/or kill, you must follow the same frame number and same general look as the already existing ones (see Relic's examples to get the timing and general shape of the animation).
Example : Synckill 4 animations :
The general description is : at frame 20, the attacker seizes the victim, holds it in the air (wether in a dreadnought pincers or power fist, or impaled on an Avatar's sword), holds it in the air untill frame 125 and then throws it away (the victim leaves the claw/pincers/sword at frame 125, but the attacker can have a longer animation to finish the movement).
The victim must have a syncdeath 4 animations of 125 frames. The victim is picked up at frame 20, but don't move it in the air in the animation file. Just have it giggle as it is impaled. The Engine will use the syncdeath4 marker present in the victim's ref file to move precisely the rest of the mesh by gluing it to the Synckill4 marker of the attacker.
-- Thrown animations : mandatory for all units light enough to be thrown away.
Units can be thrown away by explosions or during melee combat.
You must make 3 animations :
Thrown : a looping animation where the model is usually spining on itself while in mid air (in max, the model turns, but you don't lift it in the air : the game engine does this. Again, see the examples).
Thrown landing dead : an animation where the unit hits the ground and dies
Thrown landing : an animation where the unit hits the ground but is not dead
Thrown getup : the unit starts from the position in the last frame of the the thrown landing animation, and gets up to get back in the default position set for melee actions (cf point 4.3)
-- Die animations : Mandatory for all units.
The animation played when the model is destroyed.
Usually there are several such animations for troopers and 1 for vehicles or buildings. Those animastions are randomised in the OE.
-- Cover animations : animations used when the unit is in cover. Non mandatory animations.
They are the same as when the unit is idle (run, fire, aim, underfire), but with a usually more ducking position.
-- Build animations : mandatory for builders.
The animation displayed for the builder during the building's construction time.
-- Repair animations : mandatory for units with the repair ability
The animation displayed for the unit when it repairs.
-- Construction animations : animations played when the building is being constructed. Highly recomended for buildings.
Due to the way these are implemented in the OE, the best way to do this is to have several animations separated by a pause where nothing special happens, and that can be looped.
For instance :
Animation 1 : the airship drops the building in a package
Animation 2 : the package rests on the ground, idle
Animation 3 : the package unflods
Animation 4 : the building is unfolded and stays idle
Animation 5 : the last tiny bits deploy (radars, searchlights, tentacles...)
-- Creation animations : Higly recommended for buildings that can create units.
The animation played during the creation of the unit.
For the same reasons as above, separating in several animations is a good idea (ex : the dropship arrives, pause, the dropship enters the building, pause, the building emits several pings and lights, pause, the building reverts to normal).
-- Research animations : Higly recommended for buildings where researches are available.
The animation played during the time that researches are made.
Same remarks as above : if you want to have several stages in the research animation, separate them by a pause animation.
-- Jump animations : mandatory for jump capable or teleportation capable troops.
You need 5 animations :
1 - the troops go from the default idle position (see point 4.3) to a pose where they are prepared to jump
2 - they go up (don't change the altitude of the model, just its attitude)
3 - they are in flight
4 - they go down
5 - they arrive from the jump and resume the default idle position.
Obviously, you need each step's first frame position to be the same as the preceeding step's last frame position.
For Teleporting troops, you just need animations 1 and 5.
-- Rampage animations : Mandatory for troops able to rampage.
You need 4 animations :
1- the unit goes from idle to rampage start position
2- the unit runs and rampages
3- the unit goes from rampage back to default idle position
4- animation played when the rampaging unit is blocked during its rampage.
-- Special abilities : only used to depict a special ability the unit has. Non mandatory animations, to be discussed with the AE and OE integrators.
For instance : the Space Marines grenade throwing.
Possession or Spawning use also a special animation.
-- Vis animations : Non mandatory animations.
These are files where no movement is included, just the visibility properties (see point 5 below). They are used to show only a certain weapon or a certain random part.
-- Animated textures : Non mandatory animations.
These animations store only the texture animation and nothing else. They are used for things such as the Predator track moving, or the chainsword "teeth".
WARNING : you MUST have a texture set in this animation (obviously) and you MUST make sure that the texture it refers to is :
a) named the same as in the ref file
b) stored in the proper folder : Dawn of War\ModTools\DataSrc\mod_Z\Art\EBPs\Races\race_Y\Texture_Share, and not to anywhere else !
-- Custom animations : Non mandatory animations.
You can add other animations to be played when different kind of conditions are met.
For instance, when fighting over snowy terrain, the Guardsman has an animation that makes him cough. You could also make a "run" animation for when the unit enters water, making it hold its rifle above its head.
Discuss with the OE and AE integrators what conditions can be recognised by the game.
5- Special properties
A tutorial has been posted in the Wikki :
http://www.relic.com/rdn/wiki/DOWMod...sBrowser&v=r5r
Basically, DoW's exporter lets you specify some special properties to elements of your scene.
The easiest way to set these properties, is to use the little tool that Relic has given us with the ModTools.
As a rule of thumb :
- declare meshes as "max bones", except those that are skinned, and, possibly, those that are last in a hierarchy chain (nothing attached to them, not even a marker)
- if there is a skin modifier in the scene, set meshes which are declared as max bones to ForceSkinning
- in all the animations, set everything to invisible, except for the vis files where the objects you want visible must be set to visible, and in animated texture animations where the mesh supporting the animated texture should be set to visible
- in each animations, put everything to stale, except the meshes and bones you animate in this animation
Of course, this is just a basic rule : stale and invisible properties can be set as you see fit in any animation.
This is true of everything noted above : if you follow the recommendatiions, you are on the safe side, but experimentatin can bring huge rewards...
