Unit models and textures - some game conventions.

Post Reply
Patrick Ward
Staff Sergeant - StuG IIIF
Staff Sergeant - StuG IIIF
Posts: 299
Joined: Thu Sep 04, 2014 2:49 pm

Unit models and textures - some game conventions.

Post by Patrick Ward » Tue Oct 17, 2017 7:19 pm

Since some of you guys and gals are starting to make cool looking unit mods I figured it might be beneficial to outline some of the conventions I try to follow. We have to strike a balance between looking good and being usable.

This has been scraped together from posts made during beta and is a bit messed up but it represents some of the conventions I try to stick to.
(But be assured that these are provided by way of explanation only. Don't anyone feel you have to follow them or will be verbally pummelled for ignoring them. You damn well mod them however you wish. :D )


The overall look is based off fairly quick table top paint jobs. Colours are broken into base, highlight and shadow wash and a very simple top to bottom, light to dark shading. Generally you should be able to paint it or stick a transfer on it. Figure proportions are based on older minis that tended to be short and stocky rather than realistic or heroicly proportioned.

- Lighter troops are usually pale in tone. This goes for light cavalry too who'll usually have pale horses. Heavy Cavalry have black horses and anything in between, shades of brown. While I've had requests/orders to mix up the horse colours so they're more realistic .. can you imagine how much more painful it would be if you couldn't tell your lights from heavies at a glance?

- Likewise Raw troops on the whole will be lighter, paler and less decorated. The idea being that you can get a vague sense of where the strengths and weaknesses are in your line without examining every unit one by one.

- Elite troops or generally better troops have brighter, more saturated costumes, often with more detail, colour and decoration. eg. start up a battle of Germanic tribes and you'll see the superior units clearly have brighter and more decorated clothes.

- I use a fairly strict, totally matt or high shine to emphasise the difference between armour and cloth, so armoured units should usually stand out. There isn't really a halfway point so units that are 'protected' ie. have linothorax, animal skins etc. tend to be matt too. Most people couldn't tell the difference between subtly different levels of shine at this scale so you need extremes.

- Re: Metals .. its a combination of diffuse colour, spec colour and gloss. Get either one wrong and at best it'll look silly. For some reason you need your gloss values way down to get a decent highlight.

- Spears are large and oversized. Javelins are much thinner.

- When you have metal shields such as the Pikes and some cavalry, white is raw, bronze regular and iron is elite. Obviously Hoplites, with their variety of patterns on bronze shields, don't follow this. With Romans, usually the less experienced troops have paler shields, so I think its plain leather for Side0 and white for Side1.

- With Barbarians there was a differentiation using shield colour .. better were red/orange, middle yellow, poorer blue/green but feedback suggested it confused their faction. Theres still remnants of it but just for interest.

- Colour coding for side is a general side 0 =warm / side1 = cool. That's both costumes and flags. Again thats a generalisation so that at a distance you can tell them apart but if you get in close you'll find there's a mixture on both sides. Also you'll find that in regular battles with Romans, they will always use their Red costume because, (sigh), that's what people expect Romans to look like. I really tried to avoid the red v blue look thats often seen in games but unfortunately complaints about usability forced me to make some unit colours clearly one or the other.

- costume colour choices. OK so historical accuracy is always the first consideration. Then they go in game, we test out multiple battles and armies and check readability. We then edit the colours and change their ratios so that on a mixed up battle fields there is something distinctive you can latch onto and tell at a glance what they are and they'll look similar enough to all the others of the same type. This screws up all carefully planned ideals for colour blindness suitability but there are limits as to what we can do there. Historically you can look at the dyes that were available. Purple die was stupidly expensive, as was safron (rich golden yellow), were as red and crimson (that faded quickly) was relatively cheap. Plain linen/wool/cotton would be the most common. Richer people might have embroidered patches sown in or patterns applied using simple stamps and obviously this varies greatly from cuilture to culture through the ages. Printed fabrics would start to be seen some time after the opening of the silm road in 114BC but I'd expect it would be decades after that before they'd be popular/cheap enough to be seen in numbers.

- regular versus irregular troops - As a-historical as it is, regular troops - eg. Roman legions, have the same coloured tunic within any give type. Irregular units are mixed up. Makes the former feel like a trained army as opposed to the latter which feels like a rabble.

- Shield colours. Where possible we've tried to be accurate eg. All Romans in a Legion would have their shields supplied and painted a uniform colour for recognition with (in later years at least) a legion emblem on the face . . Its generally agreed that marine legions would, if not dress in blue, have blue faced shields with marine based emblems. Shield emblems should preferably be hand drawn and taken from or based on historical sources but check your time periods. Try to maintain texel density or your shields will look blurry compared to everything else. Please dont use copyrighted illustrations.

-Flag colours have been chosen so they're distinct enough for those with the most common two types of colourblindness to always be able to tell the factions. Yes they could be alot more fancy and decorative but then again they aren't decorative .. they're functional .. and ensuring they stand out as solid blocks of colour against the mass of animated limbs and weapons was paramount.


While I'm sure you can pick holes in everything the realties of time constraints means we have to choose our battles.

So feel free to mod them as you wish but do try to keep to the above conventions so your players don't have to stuggle to see passed the pretty colours. Looking forward to seeing how you guys can expand on what we've done.
Last edited by Patrick Ward on Sat Oct 21, 2017 2:14 am, edited 2 times in total.
............................

Pat a Pixel Pusher

............................

Patrick Ward
Staff Sergeant - StuG IIIF
Staff Sergeant - StuG IIIF
Posts: 299
Joined: Thu Sep 04, 2014 2:49 pm

Re: Unit models and textures - some game conventions.

Post by Patrick Ward » Wed Oct 18, 2017 4:08 pm

The texture setup is simple and doesn't involve the complexities many seem to imagine.

Layout..

Foot soldier textures are in sets of four. So one texture sheet contains 4 texture variations. These are randomly assigned to a unit figure and we have no control over this.
Cavalry/Camels have 2 sets per unit . .the horse and rider. Again their assignment is random.
Chariots and elephants have only one set per texture sheet.

Texture types

Each set requires colour/alpha (base colour/transaparency), normal (the bump map) and spec/gloss maps though the game probably won't fail if you only have colour. A @ after the name indicates transparency to the game . . archers, cavalry and a few Romans needs this. If your units doesn't need any transparency then don't use the @. It reduces the games rendering overheads.

Texture Usage

The unit model, the .s4f, contains links to texture files. This is used for the editor only and requires the archon texture tool to setup.
Once in battle, the model will use textures based on the model name and look in the UnitTextures folders.

So if you duplicate a unit model and duplicate its textures .. ensure their names match. These should be under your unique campaign folder setup, not the main game folders.

You'll notice folders called texture1, texture2 etc. These are colour variations. The game will count up how many colour variations there are for a unit and assign the first half to side 0, the second half to side 1. So in this way we can assign different colours to the same unit type on each side.
In simple terms, you could put the red sides texture in the root of UnitTextures and the blue sides in texture1.
Or .. to add more variety, red in the root and texture1, blue in texture2 and texture3.

What it doesn't do is check if only one side is using a given unit type and then make use of ALL the available textures.
Last edited by Patrick Ward on Thu Oct 26, 2017 10:07 am, edited 1 time in total.
............................

Pat a Pixel Pusher

............................

Jace11
Private First Class - Wehrmacht Inf
Private First Class - Wehrmacht Inf
Posts: 5
Joined: Sat Feb 27, 2016 5:21 am

Re: Unit models and textures - some game conventions.

Post by Jace11 » Wed Oct 25, 2017 4:08 pm

Patrick Ward wrote: Each set requires colour/alpha, normal and spec/gloss maps though the game probably won't fail if you only have colour. A @ after the name indicates transparency to the game . . archers, cavalry and a few Romans needs this. If your units doesn't need any transparency then don't use the @. It reduces the games overheads.
Having looked through the unit textures folder there are many cases of DXT1 textures (no alpha) having the @ suffix. They are easy to spot as they are half the size of those with alphas. Others have alpha channels that are completely white (i.e a transparancy isn't required). Could these @'s be removed to further optimize things?

Patrick Ward
Staff Sergeant - StuG IIIF
Staff Sergeant - StuG IIIF
Posts: 299
Joined: Thu Sep 04, 2014 2:49 pm

Re: Unit models and textures - some game conventions.

Post by Patrick Ward » Thu Oct 26, 2017 10:02 am

Yeah we didn't catch everything as the @ tag was introduced when most of the models where already done
In theory it should work in battles but won't in the editor. The model file itself contains links to the base textures. This is essential for the editor and means that if a @ was present when the s4f was created then it needs to be there to be visible in the editor.
However when it comes to battle, the engine will choose a texture based on the units name and the tag tells it whether to ignore the alpha or not.
............................

Pat a Pixel Pusher

............................

Patrick Ward
Staff Sergeant - StuG IIIF
Staff Sergeant - StuG IIIF
Posts: 299
Joined: Thu Sep 04, 2014 2:49 pm

Re: Unit models and textures - some game conventions.

Post by Patrick Ward » Wed Aug 15, 2018 2:17 pm

Reposting from elsewhere so it doesn't get lost . .
Philippeatbay wrote: I'm finding that looking at them is even more painful than it was in the beginning.....
...
At the end of the day, all that is really required is to put a different and less period-specific kind of helmet on the current Lydian cavalryman (for both early and late periods). ....
....
How hard can it be to reuse the old sprite but give it a different style of helmet?
TLDR: its not as straghtforward as you think.

:cry:

So your description of the graphics as sprites leads me to believe you don't understand the processes required or the assets created. So...

Day 1
1/ Research. As much as I can do in a few hours. Some will of been going on for weeks prior. Often I'll be given a little black and white line drawing and so have to work to find historical evidence of materials, colours, construction methods etc.. sometimes it requires a lot of back and forth between RBS and myself.
2/ The game resolution models are given a first pass for basic volume, to assess any transparency requirements and what assets could be re-used or need creating.
3/ Hi resolution base meshes for each unique component are constructed.
4/ Most of these high resolution base meshes need to be sculpted. So poly counts often reach the 10s of millions.
5/ Every part of the completed sculpt that will correspond to a unique material needs to be given a unique ID colour.
6/ Create a lower resolution, decimated version of the high res and re-model the low res mesh to better conform.
7/ Lay out the Uv's for the figure and all its weapons, ensuring enough island separation to avoid bleeding of mip maps, but making best use of available space and taking into account potential reuse with alternate wepons etc.
8/ Create a game ready mesh and multiple bake targets
9/ Bake the high resolution sculpts and all the vertex information down onto the low res UV'd model to provide the basic 8 control textures.
10/ Repeat for each model part that need to intersect.
11/ Combine all these bakes into one set of control textures that matches the UV map
12/ Use these 8 textures to help define and shape the colour, alpha, normal, spec and gloss for every material of the costume, hand painting any extra details like shield patterns, clothing patterns etc.
13/ Create a minimum of 2 but usually at least 8 texture variations. Some require 16 or 32 because they're used in great numbers.
14/ Render out images for approval
15/ Concatenate these variations into complete sheets for the colour/alpha, normal, spec/gloss maps the engine requires.

(Many of the above steps need to be done multiple times in the cases of cavalry, chariots etc)

Day 2-3
Richard (Evans) gets to animate them. Chariots are his favourite.

Day 4
1/ I get to see the textures in game. Check how they look in their native army list, how they look against potential opponents, check readability when animated and in numbers, functionality and lastly, whether they look good against the terrain and under game lighting from multiple directions.
2/ If theres any issues, repeat any required steps from day one.
3/ Send it off to Beta testing.

Several weeks later..
1/ Feedback from beta testers ocassionally requires repeating most of day one, sometimes of only a few steps. Sometimes the cost involved makes it unfeasable though thats never my call.
2/ Halfway through beta, compress the textures and create mip maps. Unfortunately theres no way of automating this so it has to be done one at a time.


Now all of that might seem long winded and a lot of work to get a small little model done. But so far there's over 1200 variations of these and FoG is just one of the projects I work on.
If a unit takes more than a day for the bulk of its work, then its not going to be financially viable. In order to do that I have to automate as much as possible so that the portions that absolutely have to be done by hand, get the time they need.
To create Normal maps in any sensible time frame, we have to bake high res to low and paint in any extra details as height maps. If you've ever had to paint the height map of chainmail or animal fur as we did in the good old days, you'll know why.
Creating spec and gloss maps that correspond with the specific materials requires a limited understanding of how light is reflected or absorbed depending on the material.
If we want the detailed multilayered materials that make up the costumes many people like to argue about, there has to be a well structured, ID based, repeatable pipeline.
Not so many years ago I would be given 3 weeks to make a game character because it was all hand made. We got that down to 4 days when we first started on xBox. Now it has to be a day and the relative quality higher.

We are also expected to work to a certain standard. Modders aren't, so are free to cut and paste my textures around anyway they see fit. But theres not many modders creating complete new texture sets or models. I'm sure they have the skills, but they're not doing it. While I'm using current techniques and technology for efficiency, the shader system used is probably 15 years old specifically because we expect modders to understand it and our audiences older computers to run it.

So, back to the question - to add a new unique helmet to a model thats already had its UV's laid out (being as efficient as possible so theres no empty space), thats already had its high res built and sculpted, thats already had its control textures baked out, materials defined and applied, multiple texture variants created and concatenated, thats been rigged and animated, tested and reworked .. means going back to early day 1.

Yes thats a bit crap but its a compromise we have to accept for ensuring the game gets made at all.
............................

Pat a Pixel Pusher

............................

Post Reply

Return to “Field of Glory II: Modding”