Aircraft‎ > ‎

FSW Aircraft Primer

Change List

A list of changes made to this document.

 Version  Date  Revision
 1.0
 08/08/2016
Initial document.
 1.1  25/04/2017 Added sections for raindrops, propeller shadowing, ambient point lights, external lighting, to-scale character implications.
 1.2
 25/05/2017
Added more detail to previous sections, and created 'Characters,' 'New Systems and Respective Practices,' and 'Future-proofing sections.
 1.2.1 25/05/2017Changed all 'DFS' references to 'FSW'
 1.3 02/06/2017 Updated 'Characters' section to be consistent with new workflow.
 1.4 08/09/2017Added section on tooltip translations.
 1.5 21/09/2017Added information for refraction, additive specularity, point lights.
 1.6 22/11/2017Moved Physically-Based Rendering into its own section, and merged Tail Numbers into this document.
 1.7 23/11/2017Removed all references to the 3ds Max plug-in as this now has its own section.
 1.8 27/11/2017Moved New Systems and Practices to its own section.
 1.9 29/11/2017 Added section regarding chamfered edges.
 2.0 30/11/2017 Added section regarding DDS handling in 3ds Max.


Introduction

This document intends to convey new features and techniques being developed for Flight Sim World to those familiar with previous titles built with this engine.

Some of the ideas laid out here are preliminary and subject to change. All important changes will be clearly indicated in the relevant sections. Feedback from external teams utilising this document is both appreciated and encouraged.


Software Development Kit

Command-line Tools

XToMDL has been significantly improved in FSW.

The previous version of the program converted mesh data into an intermediate XML format before compiling it into binary MDL format. While XToMDL still does have an intermediate step, this is now a binary format, granting a substantive increase to the program’s overall performance.

Another significant improvement, is to the index/vertex buffer size. Titles built on prior versions of this engine were limited to 16-bit index/vertex buffers whereas FSW supports both 16-bit and 32-bit index/vertex buffers. This means that aircraft greater than 65,000 vertices in size can be implemented in FSW, unlike in previous titles built with this engine.

The way in which a user interacts with XToMDL has not changed. The output text generated during and after MDL compilation has changed however. More information is now provided to assist in troubleshooting problems and identifying bugs.

Quick Model View

Quick Model View (QMV) is a useful tool used in-house to view models in FSW quickly. A good analogue is Marmoset Toolbag, a popular real-time engine. Loading-up FSW to view small changes can be time costly - QMV aims to mitigate this.

QMV is presently unavailable to the general public, but this may change in future updates.


Modelling Practices

In this section we examine how modelling practices have changed for FSW.

Vertex Count Limit

In titles built on prior versions of this engine, aircraft were limited to 65,000 vertices. This is not the case in FSW. See Command-line Tools for more information.

Edge Flow & Distribution

Given that FSW is a modern simulator, and the 65,000 vertex limit has been lifted, a FSW aircraft should be modelled in greater detail than that built with a prior version of this engine.

350,000 vertices is not unreasonable for a light aircraft, provided it is modelled efficiently. This means care should be given to use vertices effectively with the artist being mindful of the edge-loop distribution. The following ground rules should be followed in most cases:

  • Features that come close to the camera should be given far more detail than features only seen from a distance
  • On features with consistent detail, edge-loops should be distributed evenly along the entire surface
  • On features with inconsistent detail, more edge-loops should be invested into the detailed regions
    • i.e. a chair’s corners should be given more edge-loops

Smoothing Groups & Support Edges

A box with 6 faces (and smoothing groups separating each edge) is inadequate for realistic shading.

Instead, a better result is achieved by applying a chamfer/bevel to each edge such that 18 faces exist in total. While in former case, a box with 6 faces employed multiple smoothing groups; in the latter case, only 1 smoothing group is necessary. This principle is transferable to all shapes where a sharp edge is present.

See Smoothing Group Theory for more information.

Importance of Chamfered Edges

Edges with a perfect 90 degree incidence are seldom found in the real world. Applying a small chamfer to an edge, no matter how insignificant, can vastly improve the way a surface appears in-engine. In short, chamfers soften edges and add realism.

In the below images, both objects are being lit by the same light source and share the same material properties. The only difference is that the object on the left has chamfered edges. Note how the edges are more defined and how shading and specularity are better represented on the chamfered object.



Character Scale

FSW uses a character swapping system in which exposed flesh and clothing are treated as separate, interchangeable entities. This necessitates that character size is standardised, and a single biped rig is used. FSW's character rig stands at 1.75 metres tall.

It is important that aircraft are modelled to take into account FSW character size. See Characters for more information.

Gauges & Dynamic Textures

Every aspect of an aircraft should employ use of Physically-Based Rendering (PBR), including its gauges. The same PBR principals apply to texturing gauges as elsewhere.

In titles built on prior versions of this engine, gauges are unlit and use two textures that are swapped between depending upon time-of-day. This is a very unrealistic rendering approach by modern standards. FSW frees itself from this limitation by using an additive approach.

A light source adds light to a scene. Emissive maps describe the light produced by a material and can also be thought of as additive. FSW expects an entire PBR texture set for gauges, including an emissive map, which is used during night.

The emissive map should not be treated as a diffuse or albedo texture. It has a very explicit purpose; to describe a region’s light emittance (incandescence).

Figure 18: Example of an albedo map and corresponding emissive map.


Assigning Materials

DDS Handling in  Photoshop®

  
When opening DDS files in Photoshop® the 'Load Flipped Vertically' option should always be checked.
  
Upon saving, 'Save Flipped Vertically' should always be checked.

DDS Handling in 3ds Max





3ds Max will load DDS files as they are saved, in an inverted state. This will cause them to appear incorrectly in the viewport windows. To correctly display them:


  1. Open the material editor window.
  2. Double click on the particular texture requiring flipping.
  3. In the texture settings panel on the right of the editor, enter a 'U' angle of '180' and press enter.

Propeller Shadowing

Spinning propellers look best in FSW when not receiving shadows.

As the same laws of physics apply to propellers as other objects, they would receive shadows in real life. However, due to the blade's curvature, combined with the speed at which they spin, and the unlikeliness of the eye to be focused at that particular distance, the resulting shadow would be imperceptible during normal flight.

Shadows can be removed from a mesh in the material editor by ticking 'Don't receive shadow' in 'Enhanced Parameters,' seen below.

It is recommended that this option is restricted to spinning propellers only. A slow spinning or stationary 3D propeller should receive shadowing.


Texture Formatting

Here, we examine the conventions used to create engine-ready textures. The image files FSW expects are stated in the Physically-Based Rendering: Application section.

Source Files

It is recommended that one  Photoshop® (PSD) file is created per texture set — with each individual texture residing within its own folder. Colour coding (as illustrated below) will help the artist quickly identify a given folder.

Figure 19: One folder is allocated to each texture type

Engine Files

Each texture type has its own suffix used in the filename of the texture. This is not an engine requirement but lends consistency to texture organisation. The suffixes are stated in the Physically-Based Rendering: Application section.

In most cases the DXT1 and DXT5 encoding formats are best for engine textures. However, Dovetail Games has found that these encoding formats have bit-depths unsuitable for soft gradients. Although more expensive, we recommend using the 8.8.8.8 (ARGB) format for combined maps that feature aircraft interiors; this will preserve the soft gradients in ambient occlusion maps.

The following table can used as a quick reference for establishing texture formatting:

Texture Type

Encoding

Filename Suffix

Albedo Map

DXT1 or  DXT5

_A

Combined Map

DXT1 or  8.8.8.8-ARGB

_C

Normal Map

DXT5

_N

Emissive Map

DXT1

_E


Model Formatting

As with the last section, this section covers the conventions used for making game-ready content. This time: the actual models.

Source Files

3ds Max (MAX) and Marmoset Toolbag (TBSCENE) files may be considered as source files.

Textures and corresponding TBSCENE files must be stored within the same directory. Otherwise the textures will not load correctly on other artists’ machines.

Engine Files

In the process of making the final engine model files (MDL), an intermediate file is first generated. This file (X) can be produced directly in 3ds Max 2016 via the File → Export dialogue. The X file is then fed into XToMDL in order to create an engine-ready MDL file.

XToMDL does not have an interface. It is invoked via the command-line and controlled by arguments that are passed to it. The first argument passed should always be a path to the X file being converted.

The following table lists the other arguments that should be included for compiling an aircraft into MDL format:

/XANIM

Used to indicate animations are present and should be embedded in the output MDL.

/DICT: <path>

Used when animations are present; it is followed by a string to the modeldef.xml file.

See Command-line Tools for more information on XToMDL.