Change ListA list of changes made to this document.
IntroductionThis 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 ToolsXToMDL 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 ViewQuick 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 PracticesIn this section we examine how modelling practices have changed for FSW. Vertex Count LimitIn 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 & DistributionGiven 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:
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 ScaleFSW 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 TexturesEvery 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.
Figure 18: Example of an albedo map and corresponding emissive map. Assigning MaterialsDDS Handling in Photoshop®
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:
Propeller ShadowingSpinning 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 FormattingHere, 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 FilesIt 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 FilesEach 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:
Model FormattingAs with the last section, this section covers the conventions used for making game-ready content. This time: the actual models. Source Files3ds 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 FilesIn 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:
See Command-line Tools for more information on XToMDL.
|
Aircraft >
