Introduction
It is assumed that the 3D modelling package used is Autodesk® 3ds Max® and the package used for authoring textures is Adobe® Photoshop.
The modelling package Autodesk® 3ds Max® was used to create Train Simulator, so this product appears in the examples provided. You can, of course, use other packages such as Blender™ or amabilis 3D Crafter. The package used here for authoring textures is Adobe® Photoshop. Again, you may use one of the many other packages available.
Regardless of the packages you use, the documents below should be used as a general guide to the processes to follow to build assets for Train Simulator.
| Important Note: For your chosen package, you may need additional plug-ins to export the assets into Train Simulator. Please check the availability of a suitable plug-in before you begin creating assets. |
Environment
Seasons
Four different seasonal texture sets are supported: spring, summer (default), autumn and winter.
- The spring, summer (default) and autumn texture set will be free of snow
- In the winter texture set, there will be snow on the ground and roofs, etc.
This enables us to avoid the problem of having snow settling on the ground over time. In spring and autumn, the foliage textures will be different to simulate the seasonal change in appearance.
There will be no change in texture sets during a single free roam session or scenario.
Seasonal Textures
An asset should always be textured in Max with its default textures. Upon export, the default textures will be compiled ready for use in-game, and the process will also check for any textures which have the correct seasonal texture suffix.
A typical example showing a house with its default texture and its winter texture:
For example, a building has a single default texture called:
When this asset is exported, the process will also check for textures called:
- building_terrace_01_sp.ace
- building_terrace_01_su.ace
- building_terrace_01_au.ace
- building_terrace_01_wi.ace
If they exist in the same folder as the source default texture, they will also be compiled to be ready for use in-game.
This is a flexible system which allows the user to only author the seasonal textures that are required on a per-texture basis. Typical examples of texture sets:
| | Spring | Default (Summer) | Autumn | Winter |
| Foliage | 'Young' foliage texture | Lush foliage texture | Brown leaves on foliage | Snow covered branches |
| Building | None | Normal building texture | None | Snow covered roofs |
| Car | None | Normal car texture | None | None |
| Terrain | None | Normal terrain | None | Snow covered |
Time of Day
Settings for in-game lighting colours (throughout the day/night cycle), fog colours, ambient and sky colour etc. can all be specified in the ‘Time of Day’ blueprint.
Weather
Settings for weather type, precipitation type, cloud types and sequences of weather events can be specified in the 'weather' blueprint.
Skies
The game sky is a single asset, comprising of a background ‘dome’ with a number of inner concentric spheres.
- The background ‘dome’ is dynamically vertex lit to portray different sky colours and gradients
- The inner concentric spheres have cloud textures mapped onto them, and depending on how they are blended (either faded in or out or blended together) and rotated, they will form a dynamic cloud system in the sky.
Via ‘Time of Day’ and ‘Weather’ Blueprints, the user can create a fully dynamic time of day and weather system.
Geometry
The nodes in the sky asset must conform to the following naming convention.
- 1_0000_sky (skydome background)
- 1_0000_cloud_storm (alpha-blended cloud layer)
- 1_0000_cloud_thick (alpha-blended cloud layer)
- 1_0000_cloud_wispy (alpha-blended cloud layer)
Sky Shaders
There are two specific shaders to use on the skies.
- TrainSkyDome.fx – Used for the background skydome. This will become vertex lit depending on the lighting values in the Time of Day blueprint, hence the reason why the skydome has a fairly dense (and even) vertex distribution.
- BlendATexDiff – Used on the cloud layers. This shader would normally be avoided due to the alpha-sorting issues; however, in this case, the shader WILL BLEND PROPERLY as these cloud layers are a special case and the game engine will render these in a known order.
Sky Textures
There should be NO MIPS saved out on any sky cloud textures, as the textures are never viewed at distance.
Skydome texture
This shader requires a ‘dummy’ texture (which will be overwritten by the vertex colours in-game). Therefore it’s advisable to use a very small 32x32 dummy texture. The user can choose the name of this texture as it is specified in the Time of Day blueprint.
Cloud textures
The textures used for clouds can be true 32-bit with a full grey-scale alpha channel. Use the _nm suffix on the cloud textures if undesirable compression (or banding) is evident.
Examples:
Texture sets are simply a group of textures defined through a “Named Texture Set Blueprint”.
Places in the game which require a dynamic font system (e.g. mileposts, speed-signs, digital clocks) will need a texture group setting up to identify which textures represent which digits.
The actual assets which use the texture sets have to be mapped in 3ds Max with an agreed group of placeholder textures which conform to a naming convention.
See individual assets for naming conventions.
Consider the example of a “Named Texture Set Blueprint” seen below. This blueprint defines which textures should be substituted for the characters 0-9.
In our example below, when the code needs to display the digit ‘1’, it will use the texture B_BK_Number_1.ace.
Rail Network
Turntable
The turntables exist as a ‘Fixed Network blueprint’. The turntable consists of two basic nodes; the base node and the rails node. The rails node has simple rotating animation associated with it, which the code will rotate when required to match one of the defined exit points. An example turntable is pictured below:
The turntable must be sunk under the terrain so that the height of the rails on the turntable matches the height of the rails on the terrain. Therefore an area of the terrain must be pushed downwards in order that the bottom surface of the turntable ‘pit’ can be seen.
Once the terrain has been pushed downwards, the turntable must include extra polygons to ‘fill’ the gap. See the side profile below.
Animation
The rails node is rotated (over 16 keys) a full 360 degrees. This animation must be associated with the turntable via the ‘Fixed Network Blueprint’. Export the animation as an ‘IA file’ and link it through the blueprint.
Length of Track
The length of track is defined through the blueprint.
Number of exits
The number of exits is defined through the blueprint.
Traverser
The Traverser exists as a ‘Fixed Network blueprint’. The Traverser consists of two basic nodes: the base node and the rails node. The rails node has a simple translation animation associated with it, which the code will use to position the rails with one of the defined exit points. An example Traverser is pictured below:
Remember to include a larger runoff are (as in the turntable) to cover the dip in the terrain.
Animation
The rails node is animated (over 6 keys) moving from the full left position to the full right position. This animation must be associated with the Traverser via the ‘Fixed Network Blueprint’. Export the animation as an ‘IA file’ and link it through the blueprint. See below.
Number of Tracks
The number of tracks is defined through the blueprint.
Track Length & Width
The length and width of track is defined through the blueprint. The length is the distance measured along a single rail. The width is the distance that the rail node traverses from the leftmost position to the rightmost.
Mileposts
Mileposts consist of a base post and numerous groups of digits.
The number of groups will depend on how many digits are required. The example below requires 3 groups as the speed could be represented by a single digit, two digits or three digits.
The groups of digits are quads with placeholder digits mapped on (using the same technique as in the digital clocks).
The placeholder textures follow the same naming convention as in the digital clocks section.
Remember that these are only placeholder textures and the in-game textures are set up via a “Named Texture Set Blueprint”.
The basic milepost hierarchy is as follows:
- 1_0400_milepost
- 1_0300_primarydigits_1
- 1_0300_primarydigits_2
- 1_0300_primarydigits_3
Speed Signs
Speed signs consist of a base post and numerous groups of digits.
The number of groups will depend on how many digits are required. This time, the example above requires 6 groups as there are primary and secondary speeds indicated on the sign, and each speed could consist of a single digit, a double-digit and a triple-digit value (thus making 6 groups).
The groups of digits are quads with placeholder digits mapped on (using the same technique as in the digital clocks). The placeholder textures follow the same naming convention as in the digital clocks section.
The basic speed sign hierarchy is as follows:
- 1_0100_speedpost
- 1_0300_primarydigits_1
- 1_0300_primarydigits_2
- 1_0300_primarydigits_3
- 1_0300_secondarydigits_1
- 1_0300_secondarydigits_2
- 1_0300_secondarydigits_3
German Speed Signs
These signs are considered ‘special case’, where the digits on the sign represent the speed (but divided by ten).
For example, if the speed limit of a section of track is 70.
- The UK speed sign should display the digits for ‘70’
- The German speed sign should display the digits for ‘7’
The German speed signs should follow the same naming convention as the normal UK signs, with just the three primary nodes named as follows. Note that the zero digit quads have been scaled down (scale these small enough so they are no longer visible and consider even hiding these quads inside the sign geometry itself). The result is a sign which displays the speed but divided by ten.
Buildings
Buildings are one of the most common assets to appear in a route. These can be anything from domestic houses, industrial units or even commercial supermarkets. Station buildings also follow these same general rules.
Windows
Some buildings require a night-time effect, to simulate the lights being switched on at dusk. This is done through node names where the node names themselves will dictate whether they are visible in the day or at night.
- Node names ending with “fx_night” will only be drawn at night.
- Node names ending with “fx_day” will only be rendered in the day.
Therefore the windows can have up to two nodes, i.e. the windows in the daytime and the windows in the night-time.
| Note: Remember that every node has an associated cost, and try to keep the number of nodes in an asset to the absolute minimum. |
Foreground Buildings
If a building or buildings are viewable close to the track then it might be desirable to have shiny windows. This would be easiest done through 3 nodes (ignoring LODs for argument's sake). Remember the day and night node would never be visible at the same time.
The node in the example ‘1_0300_fx_day’ uses the TrainEnv shader. The simple daytime window quads use a dual pass material which requires two textures to be referenced in the shader. At run-time, the second texture slot will be replaced by a faked reflection map showing a faked horizon. For simplicity, reference the same daytime window texture in both slots in Max and let the game engine replace the second texture.
The node in the example ‘1_0300_fx_night’ consists of two shaders:
- The windows are simple quads, mapped with a texture which uses the Tex shader. This shader does not have a reflection map. More importantly, this shader is unlit, and therefore will not be darkened by the night-time lighting, and will appear fully lit.
- The glow on the floor uses the AddATex shader. This shader again appears fully lit and creates an additive faked lighting effect on the floor.
The texture above is an example of the daytime window. It’s a basic 24-bit texture with no alpha channel. It should resemble the window frame with the open curtains visible behind.
The texture above is an example of the night-time window. It’s a basic 24-bit texture with no alpha channel. It should resemble the window frame with the closed curtains as if they are illuminated from behind by the interior lighting.
The texture above is an example of the faked floor glow effect. It’s a 24-bit texture and because it uses an additive effect, requires no alpha channel.
Mid Distance Buildings
Generally, (ignoring LODs for argument's sake) distant buildings can have just two nodes; the main base shape and the night-time node for the windows. Here the shiny window effect is dropped as it’s probably not even seen at a distance. Also, the transparent 'window holes' on the base shape are now made solid. Also, the glowing windows are placed over the top of the base shape. Remember to keep a slight distance between the walls and these overlaid window quads, so that they will not z-fight when viewed at a distance.
The node in the example ‘1_0200_fx_night’ consists of two shaders:
- The windows are simple quads, mapped with a texture which uses the Tex shader. This shader does not have a reflection map. More importantly, this shader is unlit, and therefore will not be darkened by the night-time lighting, and will appear fully lit.
- The glow on the floor uses the AddATex shader. This shader again appears fully lit and creates an additive faked lighting effect on the floor.
Example asset as seen in the daytime:
Example asset as seen in the night-time:
Grouping Buildings
Because of the rendering overhead, it’s not recommended to fill an entire route with individually placed buildings. For mid-distance and beyond, it is recommended to produce groups of buildings that will always be seen together. Good examples of these would be industrial units.
These groups can be lower-resolution as they will not be seen close-up.
This is a single object, using a single texture, and is therefore far more efficient than the same industrial estate created from the placement of many individual objects.
There are two categories of station; generic or feature.
Generic stations will be constructed in-game by placing a suite of generic objects: benches, footbridges, etc. in the correct position to resemble the actual station.
Feature Stations are constructed as bespoke assets and therefore will already have all correct objects in the correct position.
Clocks
The game supports clocks, which if authored in accordance with this document will display the correct in-game time of day. These are built as stand-alone assets which will need placing in positions such as station platforms.
Digital Clocks
The digital clocks are structured as follows:
The clocks have a simple node structure:
- 1_0200_digitalclock
- 1_0200_primarydigits_4
- 1_0200_secondarydigits_2
The clock surround (“digitalclock”) is textured using the basic shader TexDiff.
Textures
The six individual number quads seen above (3,2,1,0,s1 and s0) need to be mapped using specific material and texture names. The six materials and textures need to be named in the following way.
Station Name Boards
There will be two types of name boards used on stations:
- Freestanding name boards. These require stencil shadows.
- Wall mounted name boards. These boards WILL NOT require stencil shadows.
The lettering on the boards is created by mapping portions of a ‘letter/font’ texture onto quads and forming the names by hand. Using this method, only a single texture is used for all the boards on a route.
An example of a name board texture:
As these would always be distant objects, these are static objects with simple UV scrolling animations applied.
If the polygon band was totally flat, then the birds would be static (appear to be gliding) as they scroll around the loop. Therefore, the polygon band has the alternating ‘V’ cross-section to give a more convincing flapping motion.
As the UV coordinates scroll along the length of the polygon band (i.e. around the circular loop) the birds appear to be flapping as the polygon cross-section alternates between an upright V and an upturned V shape. If a few of these are placed to overlap one another, the motion looks less repeated and more ‘random’.
To utilize the UV scrolling feature, simply check the ‘Scroll UVs’ button and set the UV values in the Kuju Material to be of the following (or similar values).
Scenery Vehicles
If the vehicle requires a night-time effect, then the vehicle will simply consist of two nodes: the main vehicle shape and a night-time node.
The night-time node, in this case, consists of a quad to illuminate the floor, and a number of smaller quads to simulate the illumination of the headlights and taillights (all 5 quads grouped into a single node). See below.
The floor ‘glow’ quad should sit just above ground level, and the small headlight and taillight quads should be positioned to sit just outside the actual vehicle body shell. Because of their node name, they will only be rendered at night.
Only the night-time node requires a specific name: 1_0500_fx_night. Remember that the characters ‘0500’ indicate the draw distance of 500m. The figure of 0500 could be reduced if the object is considered to be drawn too far out.
Vehicle Shaders
The car body uses a simple TexDiff shader and the night-time node uses two very different shaders.
Floor glow effect
The glow on the floor needs to use an additive alpha shader so that it appears to illuminate the ground. Use the AddATex shader with the Z-buffer mode set to “Test Only”.
Headlight/Taillights
The headlight/taillight quads need to be fully illuminated so they stay bright through the night. Use the Tex shader for this effect. This shader is unlit and hence won’t be affected when the game lighting goes darker at night.
Procedural Flora
Where required, the game will generate procedural flora on the terrain. This consists of numerous procedurally generated cruciforms with scrub textures mapped on (shown highlighted below).
Texture
The scrub texture page is called grasspack.dds. The texture page (1024x1024) consists of a bank of 16 smaller 256x256 textures arranged in a grid.
Blueprint
These 16 procedural grass textures are indexed through the ‘texturing’ blueprint (from 0 to 15). The game engine will take this simple source texture and, depending on which index is specified in the blueprint, will place that section of the texture on procedurally generated polygons and place them on the terrain in pre-defined areas.
Animated Scenery
Animated scenery consists of simple looping animations called ‘auto-animations’.
Simple hierarchical nodal animation is preferred. Simply animate the asset in 3ds Max and export two files; the IGS (Intermediate Geometry Shape) and the IA (Intermediate Animation) file.
In the ‘Anim Scenery Blueprint’ it references the IGS name, and the animation information is stored under the heading ‘Anim Set’. Simply insert the first ‘Auto Animation’ and fill in the fields.
Example names:
Animation ID - “Scoop” (this is the name that is visible in the Asset Editor)
Animation name - “Scenery\Animated\Digger.IA” (the key-frames are stored here)
Terrain
Ground Surface
This will be based around a height field, allowing the user to manipulate the heights of the points. This height data will be imported into the game from one of a variety of sources (e.g. DEM).
Terrain Textures
The terrain system supports WANG tiles as well as the usual tiled texture approach. Wang tiles are sets of tiles that fit together to non-periodically tile across the terrain, creating expanses of non repeating texture.
See “Terrain Texturing - Wang Tiles” for more details.
