The OpenFlight® format is commonly used in visual-simulation systems. You can import and export OpenFlight files. With the Flight Studio® utility, you can also create and edit objects and attributes in OpenFlight files.
An OpenFlight scene
This topic introduces some of the details that are necessary to understand how OpenFlight files are converted to 3ds Max structures, and then on export converted back into an OpenFlight file.
For more information on the OpenFlight format, see http://www.multigen.com/products/standards/openflight/index.shtml.
The following sections describe some of the exact data translation that happens when you import or export OpenFlight files.
Taking an OpenFlight file and importing its structures into 3ds Max is not an exact fit. There are many aspects of OpenFlight that are appropriate for military visual simulations but in one way or another do not match 3ds Max methodology. There can be a mapping from OpenFlight to 3ds Max and then back to OpenFlight, but it takes some care to understand how each part of the scene graph is treated. Once you understand this translation, using Flight Studio will become much more efficient and productive.
Unless otherwise noted, any description in the following Import sections is also valid for the Export section. This means that any particular setting or parameter that is used on import is also used on export.
Attribute editing in Flight Studio is meant to be a combination of value editing and making use of various 3ds Max features. The attribute list for any node might not exactly reflect those attributes found in the OpenFlight specification. Great care has been taken to expose only those attributes for editing that are not found in any 3ds Max feature. This means that on export, some of the attributes will be set automatically, even though you have no direct means of changing those values.
All OpenFlight objects are represented as 3ds Max groups, except for geometry. On import, all 3ds Max group objects are opened for editing and are also hidden in the 3ds Max viewports. This allows the easy editing of any geometry and provides a clean viewport display.
The import procedure also preserves materials and textures. The separate meshes that are created respect the following criteria: similar vertices, similar meshes and maps. The resulting 3ds Max mesh object is named according to the first face in that mesh.
There is an additional attribute in the face node upon import. Use Max Normals is set to Yes if normals were found in the file. It is set to No if no normals were found.
On export, the 3ds Max mesh geometry structure is written as OpenFlight faces. Each resulting face is given a derivative of the mesh name. The Comment field in the face node will be copied to each of the resulting faces in the OpenFlight file.
Faces that are colored using the 3ds Max VertexPaint modifier are exported as standard OpenFlight vertex colors.
On export, if Use Max Normals is set to No, then no normals will be sent to the file.
If the face has a material, its exported color is set to the diffuse component of that material. If not, the exported color is set to the wireframe color. If the face has a material and the Has FLT Material option is set to Yes, the 3ds Max material is exported to the OpenFlight file.
The basic OpenFlight texture and maps are imported into the 3ds Max Material Editor.
Materials (via the vertex attribute settings) that have maps that are found to have an opacity channel are treated slightly differently. The map is copied to the material's opacity map channel. This will cause the 3ds Max viewport to display correctly. This opacity channel setting in the material is done only so the display of the model will appear as you expect. Transparent materials will appear as such.
Multi-textures are stored as a Standard material with a Composite map applied to its Diffuse map channel. At most, the Composite map will have eight sub-maps corresponding to the layers in the OpenFlight file. A map channel to store the UVs is created for each of the sub-maps; channels are given corresponding numerical assignments. For example, the first texture is associated with map channel 1. Unused composite maps are set but turned off. Also, any texture map that contains a "bump" or "custom" setting (via the vertex) will also be turned off. This is done to allow the proper viewing in the 3ds Max viewports.
Texture maps are imported based on their path. First, the true path (the path that is stored in the OpenFlight file) is used to find the texture. If that fails, then Flight Studio looks in the same directory as the imported OpenFlight file. If the map is not found, then Flight Studio displays an error dialog. If the texture map is not found, its original path is maintained on export.
Only maps that appear in the material's Diffuse channel will be exported. The previously discussed maps in the opacity map channel are not exported. Composite maps will be exported as OpenFlight multiple material textures.
If a material has a Composite map in its Diffuse channel, a multi-texture is created. All composite sub-maps and their corresponding UV maps are exported, no matter which map channel they are associated with. Keeping the map channels within the range of 1 to 8 will help keep the same indexing scheme over successive imports and exports.
The Shell Material is also supported on export. This material is created during a Render-to-Texture operation. Materials that correspond to the newly created baked texture maps are exported.
Light Sources in an OpenFlight file are imported as Omni, Spot, and Directional lights. Light Points (light strings) have a special mapping. The light point node is imported and its parameters are available for editing. For each particular light point (the individual points) a diamond-shaped mesh is generated and placed as a child of the light point node. That geometry represents the specific light point. Light strings that contain the OpenFlight replicate bead will be converted to individual light points.
Light Points (light strings) will be exported as independent light points. As mentioned above, each light point is represented by geometry. On export, the position of any light point will be located at the center of the axis-aligned bounding box that encompasses the mesh. Any geometry can be used to represent the light point, as long as it resides as a child of the Light Point node in the hierarchy view.
If a Light Point node has no children (it is empty), then the node won’t be exported to the file.
All external reference nodes are optionally read on import. Once imported, you are free to make edits to any geometry structure. Editing the file location in the External Reference does not cause the importer to read another file. Units are preserved across multiple external reference nodes. Any successive externally referenced file will be scaled to the units of the file imported first. Transformations associated with the External Reference node are maintained on import and export.
On import, any transformations associated with the External Reference node are maintained.
Only the original (top) file that was imported will be exported. In other words, the standard export will start at the Scene Root node and recursively trace through the entire scene graph. Any nodes below the External Reference will not be exported. If you wish to export any nodes located below an External Reference node, use File Export Selected.
If the imported External Reference node contained transformations, these will be combined and a ‘general matrix’ will be set on export.
When the Freeze attribute is set to Yes on an LOD (level-of-detail) node, the Center XYZ values located in the attribute panel are written to file on export. Otherwise, these attributes are derived from the 3ds Max pivot point of the node.
When importing a DOF (degree-of-freedom) node, the Origin, Position On X-Axis, and Position On XY Plane attributes are used to set the 3ds Max pivot point for an object. The pivot point is then used to derive these values on export.
All objects in 3ds Max will appear in the hierarchy view. Many 3ds Max objects do not have a corresponding representation in OpenFlight, but will appear in the hierarchy view. These non-OpenFlight objects will not be exported.