OpenFlight 3D File Importer

This geometry import converter reads in Presagis OpenFlight '.flt' binary format files. The converter extracts and converts the OpenFlight data to equivalent NuGraf or PolyTrans internal data representations. This is one of the most extensively developed OpenFlight converters, being used, refined and developed for well over 2 decades. It is one of Okino's premier 3D importers and does quite a bit more than meets the eye. It is heavily used throughout the military and visual simulation markets, and hence has seen a lot of "combat duty" in terms of dealing with large and complex OpenFlight datasets. It is quite robust and will deal with the largest or messiest FLT files.

Please also refer to the corresponding OpenFlight export converter.

Please note that this converter is part of the DCC/Pack module. Please click here for sales information.

What is OpenFlight?

OpenFlight is an industry standard realtime 3D scene description format developed, owned and maintained by Presagis, Inc. It was originally developed by Presagis (MultiGen-Paradigm) in response to a need for database transportability within the visual simulation community.

OpenFlight is the most widely used file format for visual simulation databases and is supported by dozens of vendors of realtime 3D tools. Military visual simulation includes battle simulation, fighter jet flight simulation, tank simulation. Visual simulation also includes geospecific terrain for accurate realtime fly through of regions of the planet.

In visual simulation, OpenFlight is the defacto standard format. OpenFlight is also prevalent in the PC animation and modeling communities for optimizing and tagging 3d data for realtime playback. As application examples, in the visual simulation industry OpenFlight is the format for entire worlds. In the entertainment industry it is widely used for level building in realtime games and in the AES or urban simulation industries it is used to organize and optimize scenes for realtime walkthroughs.

If the content is targeted for realtime playback, then OpenFlight, and the tools that edit OpenFlight format, provide the highest degree of control over the database organization and the ability to attach data attributes to elements of the model. Most other 3D file formats are good at storing state or cinematic information whereas OpenFlight focuses on reducing the source to screen latency to improve the overall realtime 3D experience. This is achieved by structuring the database as a 'scene graph' of hierarchical 'beads'. Objects can be tagged with such various attributes as 'Level of Detail' which allow the scene graph to be culled according to distance and other aspects of the playback environment.

Benefits of the OpenFlight Converters in PolyTrans

In the 80's and early 90's there was little concern or need for data inter-operability or data inter-connectivity amongst competing programs, or to that matter, between differing industries. This has all changed in the late 90's and the 2000's decade where software users have come to expect clean and seamless data translation between all of their application programs. In the world of 3D computer graphics there abounds many different and non-compatible file formats, with no single standardized file format for data interchange.

Through the use of Okino's PolyTrans users of many different 3D software packages, or of completely non-related industries, can transform one form of 3D data to another without significant loss of content or detail. With the new OpenFlight converters for PolyTrans, a multi-point connection now exists between the Visual Simulation, Gaming, MultiMedia, CAD/CAM, AES, Entertainment and Animation markets where inconnectivity was previously limited or non-existent.

IMPORTANT::

You must add a directory path to the location on your hard disk where the Presagis texture map images are stored. This directory path can be specified by the 'Preferences/Configure File Search Paths' menu option located within the main NuGraf or PolyTrans program. Add the new directory path within the 'Texture Bitmaps Search Path'. If you do not set up this path properly then the NuGraf renderer will not be able to find the texture images referenced by the .flt files. Also, export filters that must reference these bitmap files will not be able to locate them either.

Texture Mapping Differences

It is important to note that because of differences between the method of texture mapping used in Presagis products and that used in the internal NuGraf/PolyTrans representation that there might be slight differences in the coloration of texture mapped objects:

• Firstly, only the 'modulation' type texture maps from the OpenFlight database are compatible with the internal representation. Texture maps using the 'blend' type in OpenFlight are completely unsupported. 'Decal' textures will appear similar, with the exception that shading will be done on the object (decalled objects in OpenFlight scenes are not shaded).
  
  
• The best match occurs for OpenFlight databases where textures are either applied to objects with a white material applied (or no material at all), or the texture map is an intensity map used to modulate the intensity of the base material color.
  
  
• Textures that are intensity bitmaps will be imported and set to modulate ambient and diffuse colour intensity within the NuGraf/PolyTrans internal representation. All other textures will be defined to modulate the ambient and diffuse color of the textured object.
  
  
• Any texture imported that contains an alpha channel will be defined to modulate surface opacity using the alpha channel.

DOF, Switch & Animation Data Not Imported

Degree of freedom, switch (some switch information can be written to a text file on import: see "Output Parsing Information to File 'debugflt.txt' below"), and animation information will not be imported. All geometry will still be imported treating these unsupported nodes as simple group nodes. Animation is not supported because OpenFlight animation is not true key-frame animation but rather a simplistic sequencing between different objects. Since all node names are preserved, you will still be able to easily identify all parts of the hierarchy.

Instancing and External References - Supported

All instance information is preserved as it is in the OpenFlight database and external references to other FLT files are handled properly (the external references are read into the current scene).

Multiple Sets of uv Texture Coordinates

The OpenFlight importer is fully compliant with the updated FLT format v15.7 or newer for multiple sets of uv texture coordinates. Up to 8 sets of uv texture coordinates will be read in for the "Vertex" record of parent "Polygon" records, and for the new "Mesh" primitive introduced in v15.7. If all the (u,v) values are (0.0, 0.0) then that corresponding uvset will not be imported.

Polygon Sub-Face Limitations

A limitation to keep in mind is that of subfacing. The internal NuGraf/PolyTrans representation does not support subfacing. Any polygons in the OpenFlight database that are subfaces will be imported simply as coincident polygons. This may present a problem if the model is being imported so that it can eventually be rendered. Many renderers do not handle coincident surfaces very elegantly, producing very spotty areas where the renderer has trouble determining which polygon is visible.

Unsupported OpenFlight Beads

Other information possibly contained in an OpenFlight file that is not supported is any information contained in Continuously Adaptive Terrain (CAT) beads, Light Point beads, Morph Vertices, Binary Separating Planes, Sound beads, Road Segment/Path/Zone beads, Clip Regions, and Text beads.

Textures With 'Clamping' Enabled

Textures that make use of clamping within OpenFlight are not supported. The texture will still be imported, but will appear as a repeating texture. This is a result of how the internal format used by NuGraf/PolyTrans and that of OpenFlight each treat texture coordinates outside of the [0,1] range. If a texture in an OpenFlight file is clamped, then all texture coordinate outside this range cause a smearing of the edges of the texture across the surface. Texture coordinates outside the [0,1] range within the internal format cause a repeating of the texture. For example, consider a model of the lower leg of a humanoid model with a texture applied to give the appearance of the top of a boot. The lower half of the texture bitmap is a red boot, and the upper half is blue for pants. If the texture is clamped in the OpenFlight model, then the red of the boot will be smeared down the leg below the edge of the boot while the blue of the pants will be smeared upwards along the legs. The same texture imported into the internal NuGraf format will have a repetition of the top of the boot along the leg instead of appearing only once with the boot and pant colors smeared along the leg.

Dialog Box Options

Use Custom Hierarchy Tree Walker

** Enable this option if you are loading in a "master" FLT file which you know references a number of external child FLT files, and each child FLT file has its own set of texture palettes and texture maps. **

The Okino FLT importer uses the Presagis importer DLLs and API to parse through FLT files. However, the Presagis DLLs have one small problem in the case where they are loading a master FLT file, that itself reads in child FLT files via EXTERNal references. The basic problem is that the parent master FLT file MUST have a common texture palette to all of the child FLT files. As an aside, the meshes inside a FLT file reference texture maps via an "index" into a local "texture palette" associated with its respective FLT file. However, if the file is loaded in via the master FLT file as an external FLT file reference, then the texture indices in the child FLT file will end up referring to the texture palette from the master FLT file and not the child FLT file.

So, texture mapping will look wrong in some cases (or no textures will appear) if you load up a master FLT file. Yet, if you load up each child FLT file then the textures will look ok.

One solution is to use the "Attribute Resolver" command of the "Attributes" menu inside Presagis "Creator". This ensures that the master FLT file and all the child FLT files end up sharing the same texture palettes in each and every FLT file.

But a general solution has been created in the Okino FLT importer. Simply enable this option. By doing so a custom tree walker mechanism will be used to walk "into" and process external FLT files; basically the Okino importer will take over complete control of opening and closing external FLT files from the main master file. By doing so, internal state control is achieved for resolving all of the texture map palette indices.

Optimize Hierarchy (Remove Redundant Nodes)

OpenFlight is much unlike other file formats. It consists of many unique types of "nodes" that are ideally suited for real time simulations and playback. Some of these include LOD, SWITCH, EXTERN, CAT, etc. beads. Nodes types which have no correlation in the core Okino 3D database are converted to normal "grouping" (yellow folder) nodes. This often leads to an imported scene which can have hundreds of empty folder nodes and little or no geometry, which creates a cluttered hierarchy.

If you enable this option then all extraneous grouping nodes will be deleted from the imported hierarchy. It will not affect the placement of objects in the scene or the behavior of the scene hierarchy.

Always Tag Names with Unique Node IDs

If this option is enabled then every object and grouping name imported will be tagged with the internal node ID of the object from the OpenFlight file. This will ensure that each and every name will be completely unique relative to the structure of the OpenFlight file.

In most cases you will just want to enable the "Tag Names With Unique Node Ids if "Externs" Detected" option which will only add the unique node Ids to each name if external references are detected while importing the master flight file; in general name collisions can only occur when multiple externally referenced FLT files are imported and each file shares common names with those of the other files.

Tag Names With Unique Node IDs if "Externs" Detected

If this option is enabled, and the importer detects external references being used in the master OpenFlight file, then every object and grouping name imported will be tagged with the internal node ID of the object from the OpenFlight file. This is enabled by default because there are cases where the external referenced .flt files all use the same names ("g90", "extern", etc.) inside each file, yet those objects do not share the same geometry (ie: multiple common names are used across the different externally referenced files). For such files to be imported properly the object and group names need to be tagged with the unique OpenFlight node ID.

Strip Off Filepaths From Bitmap References

If this checkbox is check-marked then any bitmap references in the OpenFlight file will have their filepath removed leaving just the filename.

Import Textured Objects as 100% Diffuse

If this checkbox is enabled then any object which is texture mapped will have its diffuse shading coefficient set to 100%. This is useful so that all texture mapped objects appear bright. If this option is disabled then the texture mapped object may appear dark.

Report Statistics About the Geometry File

If this checkbox is check-marked then parsing statistics will be displayed in the message window after the OpenFlight file has been imported.

Output Parsing Information to File "debugflt.txt"

If this checkbox is check-marked then the contents of the OpenFlight binary file will be verbosely described and output to the file "debugflt.txt". In particular, this file will contain information regarding Level of Detail switching distances as well as Switch node flags.

Match OpenFlight File Units to Internal System Units

If this checkbox is check-marked then the geometry will be scaled in size so that the linear measurement units found in the FLT file will match the linear measurement units of the destination scene graph.

For example, if the FLT file is being read into Maya then Maya will implicitly expect that all geometry be in centimeters. If the source FLT file indicates that the geometry was measured in meters, then all the geometry will be scaled by 100 before being imported into Maya (to go from meters to centimeters).

If this checkbox is disabled then no units matching will be performed. The FLT data will be imported with no scaling performed on it.

LOD Import Control

This drop-down box provides a mechanism whereby certain LODs and their children nodes from the FLT file can be imported.

First, an explanation of Presagis OpenFlight LOD nodes. Each node has a "switch in", "switch out" and "center location" for each LOD node. When the distance from the camera to the LOD node is between the switch distances, then the LOD node and its children are displayed.

If the "Import LODs Between 2 distances" option is chosen from the drop-down combo box, then only those LOD nodes and their children which overlap the distance region specifed on the dialog box will be imported. For example, if the dialog box lists "300 to 600" as the region, and an LOD node has switch distances of 0 and 400, then this node will be imported. If the LOD node has switch distance of 601 and 900, then the node will not be imported since its switch distances do not overlap with the user specific and desired LOD range.

Normally you would first import the database with the drop down combo box set to "Import all LOD nodes" and enable the "Tag names of special nodes". Using the import database, you can determine from the LOD group node names the range of LODs you wish to actually import. After resetting the scene and starting the import process again, the second import would specify a specific range of LODs to import.

Tag Names of Special Nodes (LOD, DOF, Etc).

If this checkbox is enabled then OpenFlight Level-of-Detail (LOD), Degree-of-Freedom (DOF) and Switch nodes imported into the PolyTrans/NuGraf database will have a special "tag" appended to their names ("(LOD)", "(DOF)" or "(Switch)").

Material Creation

These options affect how the surface color from the imported OpenFlight file will be fed into the ambient, diffuse and specular shading channels of the NuGraf/PolyTrans software.

Lock Ambient Color to Diffuse Surface Color

OpenFlight has the capability to specify different colors for the ambient and diffuse material colors. If this option is left un-checked (the default), then the ambient and diffuse colors will stored in the new material definitionas their original ambient and diffuse values.

If this option is check-marked, then the ambient color will be ignored from the OpenFlight file. In this case the internal ambient color will be copied over from the diffuse surface color.

Feed Texture Maps Into Ambient Color

If the "Lock Ambient Color to Diffuse Surface Color" option is disabled then you will most likely want to enable this "Feed Texture Maps Into Ambient Color" option. If this option is enabled, and a texture map is assigned to a model in the OpenFlight file, then the texture map will be feed into the diffuse (surface) color shader channel as well as the ambient color shader channel; this will make the model render much better when rendered in Okino"s NuGraf software. If this option is not enabled then you might find that the ambient material color will wash out or completely drown out any texture map(s) assigned to the material.

Lock Specular Color to Diffuse Surface Color

The explanation is the same as the "Lock Ambient Color" option described above, except that it applies to the specular color imported from the OpenFlight file.

Enable Texture Alpha Channel ("Transparency") Handling Method

These options provide ultimate control over how a "transparency map" (or "decal map" or alpha channel blending) is to be manipulated so that it transforms properly to the destination program (most notably 3ds Max, Maya or Okino's NuGraf/PolyTrans). The full explanation can be read in the OpenFlight importer help file.

"Disable if 32-bit RGBA Texture Map Cannot be Found" Checkbox

Synopsis: Enable (checkmark) this option if you only want the alpha channel handling system put into affect once the corresponding texture maps on disk have been verified as being 32-bit RGBA (ie. texture maps with valid alpha channels in them). Check-marking this checkbox makes a lot of sense since you really don't want to put the alpha channel handling system into effect if the corresponding texture maps don't have an alpha channel. This checkbox is disabled by default, however, because there may be the case where the texture map cannot be located on disk for any number of reasons (including the file extension being incorrect, or simply that the texture does not exist on the local disk yet). If the texture maps cannot be located then naturally the alpha channel handling system is turned off and you might get confused why the shaders are not being set up properly for transparency mapping (in particular for 3ds Max and Maya). Thus, if you know the texture maps exist on disk and that the file extensions are ok, then checkmark this checkbox. If warnings are shown that the texture map(s) cannot be located on disk, then go into PolyTrans, NuGraf, PolyTrans-for-MAX or PolyTrans-for-Maya and add a path to the directory where the source texture maps are located, via the Okino Texture-Search-Paths dialog box.

The "Mode" Combo Box

This combo box determines how the alpha channel of a 32-bit RGBA texture map is to be utilized in the down stream destination file format or animation program.

Selective Loading

The following checkboxes allow all or only some parts of the OpenFlight file to be loaded:

Polygon Meshes

If checkmarked, then load in the polygonal mesh.

Lights

If checkmarked, then load in the light definitions.

Materials

If checkmarked, then load in all of the material definitions.

2D Material Textures

If checkmarked, then all references to bitmaps for use as textures will be loaded.

3D Curves

If checkmarked, then all 3D curves will be loaded in from the OpenFlight file. The three curve types supported by OpenFlight are: Bezier, B-Spline and Cardinal. Even though the core PolyTrans/NuGraf software supports a full spline conversion and display engine, only a specific set of export modules accept 3D curves for output; one of these is PolyTrans-for-3dsMax, which will allow 3D curves from OpenFlight to be imported into 3ds Max.

External Files

If checkmarked, then all "external file references" in the master .flt file will be loaded. If disabled, then no external file references will be loaded.

Edit External File Search Paths…

OpenFlight files are allowed to make reference to additional external files on disk. Normally those external files are located in the same directory as the master file. However, there are cases where the external files may be located elsewhere on your hard disk yet there is no absolute path to those files in the master FLT file. To allow the OpenFlight importer to find those files, press this button and "Add" a new path which points to the directory containing the external reference files.