[Read 2nd] Custom Vehicle Creation Guidelines

Ryan Douglas

Staff member
[Thanks to our Graphics Developer Justin Ead for this write-up.]

RF-X Vehicle Model Creation Guidelines
In general, you should create your aircraft model in 3ds Max using the existing KEMax guidelines used in previous versions of RealFlight. There are some additional considerations to take into account to obtain the best possible visuals and performance in RF-X. Additionally, note the following caveats:
  • KEX files made using the old KEMax plugin for 3ds Max 2012 will still work, along with FBX files generated from 3ds Max using specific settings. We recommend using the 2014/2015 version of the FBX format.
  • The renderer in the Vehicle Editor is still using the legacy engine from RealFlight 7.5. Because of this, what you see in the Vehicle Editor will not exactly match what you’ll see in RF-X. Think of the Vehicle Editor as a one-way conversion tool between RealFlight 7.5 and RF-X.
  • ~CS_GLOW frames/mesh objects are no longer supported and will be ignored in RF-X.
  • There is a known bug where multiple smoothing groups on a triangle has a chance of crashing the Vehicle Editor on import depending on the specific configuration of adjacent smoothing groups.
  • Vehicle break apart functionality may not work properly if the visual hierarchy does not match the final physics hierarchy used.

Our helicopter creation standards have changed slightly over the years, which combined with rendering differences in RF-X, may result in helicopters using the old standard having some rendering issues, mainly with regard to hubs. To resolve these, make sure the following changes are adhered to:
  • Alongside Inner, Outer, and Rods as supported hub types, Grip was added as a separate type to support a less opaque blur when viewed from above, which better matches reality and the blur seen on the rotor blades. The upper portion of Outer hub types should be separated from the lower portions into a Grip hub type for proper rendering.
  • Children of ~CS_*_*_DISKMOUNT frames/mesh objects, such as ~CS_MainGripHub_2BLADE, should instead be set as a child of the root rotor component (~CS_MAINHUB_2BLADE in this instance). Failing to do this may result in the hub rendering in an abnormal location. This will also enable the blur geometry to rotate along with their corresponding internal components, as they share the same root parent.
See attachment #1 below for an example.

Creating Transparency
Previously, you would create transparent materials on an aircraft by using the ~CANOPY or ~ALPHA name on a material in 3ds Max. While this continues to work in the Vehicle Editor, it will not be recognized in RF-X. We hope to eventually add in some automatic conversion, but for now it’ll have to be done manually.

RF-X requires all geometry to be exclusively separated into transparent or opaque surfaces. Each mixed frame/mesh object must be split up manually to include only the transparent portions. Every vertex uv coordinate in this transparent frame/mesh object must reference a pixel in the diffuse texture with an alpha channel value that is less than 255. If opaque pixels exist anywhere in the enclosed space of the mesh object, you’ll see some rendering issues in those locations. We also advise against setting any transparency setting in a material directly.

If you’re working with an existing model, you’ll need to find every vertex that includes corresponding transparent pixels in the diffuse texture and separate those vertices out into a new frame/mesh object. The new object should be renamed to either ~CS_GLASS or the former name followed by the _T suffix, such as ~CS_RMW_T. These two naming scheme options will generate different rendering effects in RF-X. ~CS_GLASS will add some refraction, will automatically be two-sided, and is often good for materials that have been named ~CANOPY. The _T suffix naming scheme gives a very plain transparency effect instead. It will also not be two-sided unless the ~SBS or ~CANOPY material name is used. If in doubt between these two naming schemes, just use ~CS_GLASS as the default.

The new transparent frame/mesh object should be set as a child of the remaining opaque portion, assuming one still remains. The opaque parent’s name should not be changed. Note that ~CS_SPINNER frames/mesh objects are a special case. For transparency to work on such motors, you must use the _T naming scheme on the transparent child and there must be an opaque parent.

See Attachment #2 below for an example.

Transparency effects will unfortunately not work on either wheel blurs or propeller blades.

For final good measure, the materials on these transparent frames should continue to be named ~CANOPY or ~ALPHA for proper rendering in the Vehicle Editor.

Designing for Performance
  • Always set up dedicated collision meshes in your models. Quantity will affect performance more than complexity, so avoid making too many. The fuselage and cockpit should only be one total mesh for example. You should generally only need one collision mesh per movable or breakable part.
  • The number of materials affects performance. We advise using texture maps to their fullest and to avoid setting up different materials with different scale values in diffuse, specular level, and glossiness. Texture maps should contain such differences between the different parts of the aircraft instead.
  • Use normal maps. Normal maps are a great way to create high poly visuals on low poly geometry without hurting performance.

FBX Export Settings
The following settings should be set when exporting an FBX from 3ds Max:
  • Smoothing Groups
  • Units - Automatic
  • Version - 2014/2015
The following should definitely not be set:
  • TurboSmooth
  • Split per-vertex Normals
The Vehicle Editor will handle the above automatically. An increase in vertex count is expected. The axis orientation setting will not affect the final imported orientation, so that option can be safely ignored.

Turned edges in Editable Poly objects do not currently function well when imported into the Vehicle Editor with the Preserve edge orientation FBX export setting, so you’ll need to manually convert any existing such objects into Editable Mesh objects first before exporting.

FBX files generated in 3ds Max are the only ones we are currently supporting. Unexpected behavior may occur using FBX files generated through other tools.

File Naming
When importing the FBX file, make sure all associated textures (including normal and specular maps) are located in the same directory as the FBX with the proper naming suffix (_n and _s, respectively). The diffuse texture suffix (_d) is optional. All base names should be identical. Textures are required to be in TGA format.

Note that the name of the imported aircraft will match the name of the imported FBX file, so take this into account when selecting the FBX file name.

Metalness Workflow
The following guide is for advanced users and involves modifying an XML file. Use at your own risk.

Unigine supports two workflows, the diffuse/normal/specular workflow and a metalness workflow. The former is the default one we are currently supporting for user-created content in the beta. All imported aircraft, and all variants, will automatically use it. One consequence of this means that variants of stock aircraft will look a little different in RF-X than the higher quality ones we created with the metalness workflow.

In your AppData/Roaming/Knife Edge Software/RF-X/Vehicles/ directory, you will see a list of folders containing all variants and imported aircraft. In each contains a MAT file that defines all of the materials used in the aircraft. Editing this file will allow you to access the metalness workflow and the improved visuals.

WARNING: Resaving an aircraft in the Vehicle Editor will overwrite any changes made. It is recommended to save a backup copy of your changes.

To start off, open up the MAT file with a text editor. Sublime Text and Notepad++ are good options. We’ll use the Schweizer as an example.

<material name="Schweizer_SchweizerStandard~dc0~gs0" parent="KEXImportMaterial">
    <texture name="diffuse">Vehicles/Schweizer/SchweizerStandard_d.dds</texture>
    <texture name="normal">Vehicles/Schweizer/SchweizerStandard_n.dds</texture>
    <parameter name="diffuse_color">0.62 0.62 0.62 1</parameter>
    <parameter name="specular_color">0.0443975 0.0443975 0.0443975 1</parameter>
    <parameter name="gloss_scale">0.68005</parameter>
Above is a material definition. To switch this material to the metalness workflow, add the following line above the first texture tag: <state name="workflow">0</state>

This will automatically make the diffuse texture, diffuse_color, specular_color, and gloss_scale tags be ignored. These can be deleted, but let’s leave these for now.

Next, you’ll want to add in new texture maps for this workflow. These can be generated in other tools. Using the outline above, you’ll want to set up texture tags for “albedo”, “metalness”, and “ambient_occlusion”. If you wish to use ambient_occlusion, you’ll also need to create a state named “ao_map” and set its value to 1, similar to the way workflow was set up.

Texture references should use the same directory style and the naming scheme of the textures should also follow suit with regards to the suffix in the following manner:

albedo - _a
metalness - _m
ambient_occlusion - _ao

Regarding the texture file format: Either TGA’s or DDS's can be used. The metalness map will only use the data in the red and green channels.

If you take a look at the pre-existing diffuse_color parameter, you’ll notice there are 4 values separated by spaces. These refer to the red, green, blue, and alpha channels, respectively, and will scale the values in the texture appropriately. gloss_scale will scale the glossiness data in the specular map that is stored in the alpha channel. Since we’re switching to the metalness workflow, however, these will no longer work. Replace “diffuse_color” with “albedo_color” to get it to scale the albedo texture properly. Tweak the RGB values as needed and leave the alpha value at 1.

The following available parameters can also be used, but note that they use only a single floating-point number, similar to gloss_scale above:
  • roughness
  • metalness
  • ior
All values should always remain between 0 and 1. Going outside this range may cause rendering problems.

Depending on the aircraft, there may be several material definitions. Each will affect a different part of the aircraft. Repeat the above steps with other materials. However, materials for propellers, rotors, and their respective blur frames should never be switched to metalness.

Modifying anything else, such as the material name, or anything in the NODE or MESH files, will likely result in the vehicle breaking.

After making changes, you’ll need to load the aircraft in the simulator to view any changes. If the sim is already opened, you may need to reload the airport. If you happen to break everything and wish to start over, resaving the aircraft in the vehicle editor will fix it. If you are satisfied with your changes, create a copy of the MAT file and rename it for backup purposes.


Ryan Douglas

Staff member
A few additional things to note:

You must keep the editor's Vehicle Graphical Scale parameter set to 100%.

There is a limit of 65534 triangles in a single frame. Note that the final count per frame can shrink or grow a bit on import into the editor due to optimizations we make and the way smoothing groups are handled. So it's a little bit of a fuzzy limit in practice.

In older versions of RealFlight, propellers/heli blades were loaded into the sim dynamically. They existed separately from the vehicle. That is still true in the Vehicle Editor. But when you save a vehicle and it is exported to RF-X, the props/blades are combined into a single mesh with the vehicle. This doesn't really change anything, though. To be clear, the creation process is still the same for custom props/blades: create your art, import it into the editor, select it for your model in the dropdown, and save.


Well-known member
What would be the advantage to generating an ao map and setting it as a separate texture file over simply adding it as a layer in the diffuse map and setting it's mix and opacity?


Well-known member
You mention that DDS files are preferred over TGA. I have nvidia tools installed for photoshop and when creating a DDS with you will find many options. Any suggestions here?
In the screenshot you can see that the DDS type I've selected is
" ABGR 128 bpp | floating point" I assume this is correct because it shows 32bit for all channels, and all channels are represented as "ABGR"
The only other 32bit option is:
32f R 32 bpp | floating point

I would also assume that "No MIP maps" should be selected.
The screen shot also shows 2 other screens "Image Options" and "Sharpening settings"
I assume "Highest" for "Compression Quality" but I'm not sure I am using this exporter correctly.
Any help would be welcomed.


Ryan Douglas

Staff member
Original post updated for following changes:
  • Corrected helicopter hub type name: should be "grip", not "grips".
  • Added note that materials for props, blades, and their blur frames should never be changed to use metalness.

Ryan Douglas

Staff member
What would be the advantage to generating an ao map and setting it as a separate texture file over simply adding it as a layer in the diffuse map and setting it's mix and opacity?
Essentially, AO maps make the lighting more correct.

Ambient occlusion doesn't necessarily occlude direct light, only ambient or bounce light. You don't have that control with the diffuse texture alone.

Baking AO into the diffuse texture is like adding black paint to your object. It's not going to affect the lighting, just the color of the object.

Putting AO in the diffuse texture has long been the only option. Now we have a relatively new and better way available.

Ryan Douglas

Staff member
Original post updated with numerous clarifying changes. Most of them were related to transparency. Two attachments were also added as examples.

Ryan Douglas

Staff member
Boof, sorry for the delayed response. I'm not sure which options are best there since we use a different tool (provided by Unigine). I think most of what you selected makes sense, though mipmaps should probably be enabled.

Contrary to our initial recommendation, it may be best to actually just use .TGAs. They remove any of the guesswork and will definitely work. Then, if you felt like experimenting with .DDS export options, you would be starting from a known good model and could better observe the effect of any changes.