Exporting FBX Files and History of the Kaydara, Alias and Autodesk versions of the FBX 3D File Format

Overview:

Okino's FBX export conversion system intelligently and robustly converts from the world’s most popular and complex 3D programs (MCAD, DCC and Animation) into highly accurate and efficient FBX files. It support export of meshes, NURBS surfaces, spline shapes (converted to meshes or NURBS surfaces), lights, cameras, materials, automatic bitmap conversion, skeleton (bones) and mesh deformation skinning, object animation, camera animation, light animation, material animation and more.

Statistically, the Okino FBX exporter has been primarily used for moving data into Unity, the Unreal Engine and MODO. If you are exporting data into 3ds Max or Maya then please use Okino's PolyTrans-for-3dsMax or PolyTrans-for-Maya software.

Please refer to the corresponding Okino FBX importer for extensive information about how the FBX file format works with Okino software.

Quick History of the Okino FBX Converter Implementations:

Long before many 3D users had even heard of the FBX file format, Okino Computer Graphics developed the first, professional FBX conversion system starting in November 2002 and continues to do so until this very day.

As such, Okino is the longest standing and experienced conversion company when it comes to all aspect of the FBX file format, its disparate and non-compatible SDKs and all of its many quirks. We produce the first and only long-standing implementations of FBX import/export converters that support v5 (Kaydara), v6 (Alias|Wavefront) and v7 (Autodesk).

Documentation for each FBX Exporter Option Panels

Click on any one of the small screen snapshots to jump to the corresponding section of this WEB page:

Main	Selective-1	Selective-2	Mesh Manip

Curves	Materials	Bitmap Manip	File Paths

Animation

Main Options Panel

This panel contains the FBX export options which are most often used or should be considered during an export process.

FBX File Format

These two combo boxes allow you to choose a specific version of the FBX file format and whether it the file is written in ASCII text or binary. The most recent version supported by this exporter is chosen as the default.

Global Scene Modifications

Flip "Y-Up" to "Z-Up" coordinate system

This option allows the default coordinate system to be set for the FBX file. It defines what will be considered the "Up" axis in the exported FBX file.

Enabling this option will flip the source Y-up data of the internal Okino scene graph to the Z-up coordinate system of the exported FBX file.

Apply global transformation

If this checkbox is enabled then a general purpose global transformation will be applied to each exported FBX scene. This new transformation matrix will be applied to the root node in the exported FBX file.

This option will allow you to, for example,

• Re-center all of the geometry so that it is centered at the origin (0,0,0) in the FBX file.
• Move all of the geometry so that it is sitting on the Y=0 (XZ) horizontal plane.
• Auto-scale the geometry so that it is no larger than a specific bounding box size.
• Scale the scene by a (X, Y, Z) value.
• Shear the scene by a (X, Y, Z) value.
• Rotate the scene by a (X, Y, Z) value.
• Translate the scene by a (X, Y, Z) value.

The transformation can be edited by pressing the "Edit Transform" button which will cause the following global transformation dialog box to appear:

The transformation matrix will be computed in two phase: (1) the transformations specified in the top "Automatic Scene Resizing" section, then (2) the single transformation specified in the "General Transformation Matrix" section.

The values on the dialog box are described as follows:

Automatic Scene Resizing

Center all geometry at the origin

If this checkbox is enabled (checkmarked) then all the geometry data will be positioned so that it is centered about the origin. If disabled then the geometry will not be repositioned.

Make all geometry sit on the Y=0 horizontal plane

If this checkbox is enabled (checkmarked) then the geometry will be repositioned so that it is sitting flush with the top of the Y plane (the horizontal plane).

Scale geometry to be no larger than:

This option allows the geometry data to be automatically rescaled if it is too large. If set to 'Do not scale the geometry' then no scaling will be done. If set to '1x1x1 units' then all the objects will be scaled smaller should they exceed 1x1x1 units in total size. Likewise for the '2x2x2 units' option. If set to 'User defined maximum size' then the maximum size of all the objects can be set using the type-in numeric box. The default is '2x2x2 units'.

Although not quite the same, if the option is set to ‘Use Absolute Scaling Factor’ then all objects exported to the FBX file will be scaled absolutely by the user specified value. Thus, if you set the type-in value to 0.25 then all objects will be made 4 times smaller and if the value if set to 4 then all objects will be scaled 4 times larger. This is useful is you are converting a variety of different models to FBX format and you want them all uniformly scaled with the same scaling factor.

Transformation Matrix Values

Translate X, Y, Z

This applies a 3D translation by the specified amounts in the X, Y and Z dimensions.

Scale X, Y, Z

This applies 3D scaling in the X, Y and Z dimensions. All 3 scale factors must be non-zero. Values above 1.0 will make the scene larger (2.0 will double the size of the scene) while values less than 0 will make the scene smaller (0.5 will half the size of the scene).

Shear XY, XZ, YZ

This applies a linear shear in one of 3 directions:

XY will shift all points in the X direction by the specified amount in proportion to the distance the points are located along the positive or negative Y axis. For example, using a value of 2.5 will shear all points by 68 degrees in the positive X direction; in other words, for every unit increase in the Y direction the X points will be shifted by 2.5 units.

XZ will shift all points in the X direction by the specified amount in proportion to the distance the points are located along the positive or negative Z axis.

YZ will shift all points in the Y direction by the specified amount in proportion to the distance the points are located along the positive or negative Z axis.

Rotate Around X Axis
Rotate Around Y Axis
Rotate Around Z Axis

This applies a rotation about the X, Y and/or Z axes. The rotation angle is restricted to the range -360 to 360 degrees. The angle of rotation is counter-clockwise when viewed from the positive to negative axis of rotation.

Apply global scaling factor = #

This value allows a custom scaling to be applied to the overall exported scene. For example, if set to 10.0 then the entire exported scene (geometry, lights and cameras) will be scaled 10 times larger.

Report statistics about exported data

If this checkbox is checkmarked then statistics will be output after the FBX file has been exported, which looks like this:

FBX Export statistics: Number of meshes = 3 Number of polygons = 16005 Number of mesh vertices = 8112 Number of vertex normals = 8120 Number of uv texture coordinates = 33686 Number of skinned meshes = 1 Number of vertex weights = 132040 Number of root-level skeletons = 1 Number of joint nodes = 64 Number of lights = 3 Number of ambient lights = 1 Number of directional lights = 2 Number of perspective cameras = 1 Number of materials = 10 Number of texture maps = 8 Number of group nodes = 65 Number of animation curves = 576 (1883 total keys)

Selective Output Options Panel # 1

Output Mesh Geometry

This checkbox should not, in general, need to be disabled. It controls whether polygonal mesh data will be output to the FBX file. This is the main and primary geometry type used by the FBX software.

Output vertex normals

If this checkbox is checkmarked then vertex normals will be exported along with the mesh geometry. Vertex normals are required to provide the "smoothing" information for a mesh model.

Disabling this option may make for smaller .fbx files but at the expense of making the models appear faceted.

Output skinning weights

"Mesh skinning" is the process of deforming a single skin mesh with a skeleton of bones or any hierarchical set of transform nodes. The contribution of each bone of the skeleton to the deformation of a vertex in the mesh is controlled by vertex weights. More information can be found online at this Okino WEB page.

If this option is enabled then a single polygonal mesh will be bound to one or more secondary objects (“deformers”, such as bones) via transformation matrices and weight values in the FBX file.

Only skinned meshes are supported for export, not skinned NURBS surfaces or skinned curves.

Typical sources of skinned mesh data (and which are supported by Okino software) are 3ds Max, Maya, LightWave, Cinema-4D, Softimage (XSI), FBX, COLLADA, glTF/glB, DirectX, U3D and USD.

Output vertex UV texture map coordinates

If this checkbox is checkmarked then (u,v) vertex texture coordinates will be exported along with the mesh geometry. These are needed to define the mapping of 2D texture images onto the 3D mesh geometry. Disabling this option may result in smaller FBX files, but at the expense of not being able to map 2D texture images onto the mesh geometry.

Output vertex colours

If this option is enabled (checkmarked) then any vertex colors that are assigned to polygon vertices will be exported. The concept of “vertex colors” is something from the 1980s and 1990s and is rarely found in most 3D file formats or graphics packages. However, Okino software has full and complete support for vertex colors if and when such data is available during a conversion process, such as from OpenFlight, 3ds Max or Maya into exported FBX files.

Output Lights

If this checkbox is checkmarked then all light sources of the current 3D scene will be exported to the FBX file, including those parameters for ambient, point, spot and directional light sources.

Output Light Attenuation Coefficients

If this checkbox is checkmarked then the Okino light decay and distance-based attenuation factors will be appropriately mapped over to similar FBX lighting factors.

The Okino light “decay” value will be mapped as follows:

• 0 = FBX “None” attenuation
  
  
• 1 = FBX “Linear” attenuation
  
  
• 2 = FBX “Quadratic” attenuation
  
  
• 3 or more = FBX “Cubic” attenuation

Also, the Okino “inner” and “outer” linear attenuation factors will be mapped over directly, 1:1 to the FBX “near” and “far” linear attenuation factors.

Add New Lights

If this checkbox is checkmarked then new lights will be added to the FBX file. The pre-defined light locations, color and light types are chosen from the following drop-down combo box.

• The first two icons represent the light type (Sun = directional light, Light bulb = point light, Spot light = spot).
• The second two squares represent the color of each of these two light sources.
• The text describes the location of the new light sources (see image below for visual locations).

The new light sources will be placed according to the following image, along the XY plane. If you are looking down the Z axis (towards the negative Z axis) then upper-left will be (1), upper-right will be (3), lower-left will be (7) and lower-right will be (9).

Add New Lights Method

This combo box determines how the new lights are to be added to the exported FBX file.

Merge with existing lights in the scene

This option will cause the newly chosen lights (from the drop-down combo box mentioned above) to be added to the already existing lights of the current 3D scene. In other words, all the lights of the current 3D scene will be output first, followed by the 1 or 2 new lights you have chosen from the drop-down visual list.

Replace existing lights in the scene

This option will cause the newly chosen lights (from the drop-down combo box mentioned above) to be output to the FBX file, but no other light sources. None of the light sources in the original 3D scene will be output to the FBX file.

Add new lights only if there are no existing lights in the scene

This option will cause the newly chosen lights (from the drop-down combo box mentioned above) to be output to the FBX file, but only if there are no existing lights in the original 3D scene. This is the default option. It will ensure that there are at least 1 or 2 new light sources added to the FBX scene if no lights exist in the original 3D scene.

Preserve Geometry Instancing

If this checkbox is checkmarked then the mechanism of "instancing" will be used to try and keep the size of the FBX file as small as possible. For example, if the source scene has 1000 bolts all derived from the same mesh primitive data, and the 1000 items have been placed in the Okino scene graph via "instancing" then during export to FBX only a single copy of the geometry mesh data will be exported to FBX, but with 1000 virtual copies made of it. These virtual copy instances merely act as indexes to the original mesh primitive data instead of being full copies, which can significantly reduce the size of the final output.

If this checkbox is disabled then unique and explicit copies of mesh data will be output to the FBX file regardless of whether each copy is exactly the same as previous copies already exported.

Note: one of the most complex aspects of the Okino FBX 'geometry instancing' functionality deals with cases where multiple instances of a base geometry item inherit different materials (for example, a red ball, green ball and blue ball, all using the same base mesh geometry), as well as where some of the base mesh's polygons are assigned specific polygon-level materials such as yellow and orange. Okino's internal 3D database allows for such complex inheritance rules. Fortunately the FBX SDK and file format also allows for such cases so this exporter does a technically proper job to map the Okino form of instancing + material inheritance over to the FBX file format. However, FBX does not allow the same material to be assigned both at the inherited instance level as well as to one or more individual polygons (because the material 'index array' in the parent FbxNode must only contain unique entries) - when such a rare case is encountered, the Okino FBX exporter will have to duplicate the material so that two different indices are stored in the FbxNode's material reference table.

Avoid Instance-Level Material Overrides (Recommended for exporting to Maya)

If this checkbox is checkmarked then any base geometry item which is instanced multiple times, and uses different inherited materials (red, green, blue, etc.) will have instancing disabled for those items with different materials assigned to them. This is a helpful override for exporting such instanced geometry to Maya which has trouble importing instanced geometry with instance-level material overrides.

Output Indexed Poly-lines (convert and output as NURBS curves)

If this checkbox is checkmarked then 3D polylines will be output to the FBX file as linear NURBS curves.

Output ‘Meta-data’ Information

Most CAD file formats, and programs like 3ds Max and Maya, allow “meta data” to be associated with each node of a 3D scene. Enabling this option will output such meta data information to the FBX file.

The FBX SDK allows 3 different ways to output the meta data information:

As KFbxObjectMetaData properties

This is what the FBX SDK itself recommends as being the default. This method attaches a “KfbxObjectMetaData” object to the main node and then fills it with the meta data items.

As KFbxNode properties (for Maya)

This method exports the meta data items as “user defined properties” on the main node itself, in the style of how current or past versions of Maya writes FBX files. All items will be output as strings.

As UDP3DSMAX properties (for 3ds Max)

This method exports the meta data items as a single “UDP3DSMAX” property on the main node itself, in the style of how current or past versions of 3ds Max writes FBX files. All items will be output as strings.

Selective Output Options Panel # 2

This panel controls the output of entities to the FBX file.

Output Hierarchy

If this option is enabled (checkmarked) then the hierarchical relationship of objects in the scene will be exported using nested FBX nodes. If this option is disabled then no hierarchy will be output and all mesh objects will be exported in flattened world-space coordinates.

Pivot Points

Pivot points are a fundamental component of an animation system. In the realm of the Okino animation system ‘pivot points’ define a local 3D coordinate system in the space of an object about which the scale, rotation and translation animation function curves will be applied. The pivot point in Okino’s scene graph is defined by a 3D point in space and a local coordinate system defined by 3 orthogonal XYZ axes; the pivot point is itself defined relative to the local coordinate system of the underlying mesh or geometry data.

For example, the virtual pivot point and its orientation axes allow a robot arm to properly rotate around its “elbow” joint instead of some other awkward point of the object. Any such animation placed on the robot arm will then naturally occur relative to this “elbow joint”.

A basic problem is that not all destination animation programs have the same concept of “pivot points” as with a source animation program. Some programs are more complex, some much simpler. The following options control how Okino software performs this “mapping”.

First, some rules need to be defined for the following explanations. “Pivot point processing” only needs to be done under these circumstances for the two “Minimal” modes:

1) The pivot point 4x4 matrix has a non-zero origin or non-aligned orientation axis. In other words, it has something “interesting” in it, or

2) The instance has animated channels associated with it, or

3) The (static) transformation matrix associated with an instance has “off-axis” scaling within it. Off-axis scaling is where rotation comes before scaling, which is basically an illegal or poorly supported situation for most 3D programs.

For a “grouping folder” (an Okino “empty instance”), which is deemed to have a valid pivot point matrix, a new child ‘anti-pivot’ node is added to the exported hierarchy tree - the child node is assigned the inverse pivot matrix and the original parent transform node gets the animation data. This properly applies the anti-pivot effect to the subsequent children in the tree.

The following options specify how the Okino pivot point information is exported for instance-geometry nodes:

Embed minimal pivots in geometry data

Logic – same as the next option below except that the processing mode will only be invoked when one of the “3 rules” explained above are valid. This leads to a cleaner conversion.

Embed pivots in *all* geometry data

Logic – regardless of the ‘3 rules’ explained above, this processing mode will be invoked on ALL instance-geometry nodes if any of them have a non-identity pivot matrix.

The inverse pivot matrix is multiplied into the raw mesh geometry vertices. In other words, the messy “pivot point” problem is made to disappear by having its 4x4 matrix physically multiplied into the mesh geometry vertices.

Add minimal anti-pivot transform nodes

Logic – same as above except that the processing mode will only be invoked when one of the “3 rules” explained above are valid.

This is the default option since (1) it results in the fewest changes to the output hierarchy tree and (2) it does not physically affect the mesh geometry coordinate data.

Output all anti-pivot transform nodes

Logic – regardless of the ‘3 rules’ explained above, this processing mode will be invoked on ALL instance-geometry nodes if any of them have a non-identity pivot matrix.

A new "anti-pivot" dummy node is introduced into the exported hierarchy tree, between the mesh geometry object and the parent transform node (which has the animation on it). The inverse of the Okino pivot point matrix is assigned to the transformation matrix of this new anti-pivot dummy node. This new anti-pivot node acts to ‘pivot-in’ the geometry vertices prior to the animation data being applied to the geometry.

Thus, this mode “splices in” the pivot point matrix into the destination hierarchy tree as a new transformation node rather than to multiply the pivot point matrix into the raw mesh geometry, as with the other modes.

Ignore all pivot point data (can cause problems)

This option prevents pivot point information from being output to the FBX file. Normally you would never want to enable this option.

Remove empty/unused leaf transforms (empty grouping nodes)

If an exported NULL/grouping node has no children, is not a joint of a bone hierarchy and has no animation on it, then such useless grouping/NULL nodes are deleted during the export process if this checkbox is enabled..

If this option is disabled then such useless grouping/NULL nodes are retained during the export process into FBX and not deleted. You will want to disable this checkbox if you are exporting a file of NULL nodes and you wish all of them to be exported without pruning.

Allow geometry nodes to have children

This option allows a form of “hierarchy compression of scene nodes” or “visual cleanup of a hierarchy”. It is disabled by default.

In simple terms, if an Okino “Yellow grouping folder” contains a single mesh geometry object then these two nodes will be compressed together and output to the FBX file as a single node. Otherwise, the two nodes will be output separately.

For this to occur, some conditions need to apply:

• The parent node needs to be a “grouping folder’ (empty instance in Okino lingo).
• The parent node cannot be a skeleton joint.
• The parent and child nodes cannot have different materials assigned to them.
• The bind pose matrix for skinning needs to be the same on both nodes.
• The names of the parent and child geometry nodes must be “similar”, as explained further below.
• The child geometry node cannot have mesh skinning weights.

Also, the parent node needs to be named in a specific manner to that of the child geometry node. If we were to assume that the child geometry node was named “example” then the parent grouping node needs to be named in one of the following ways:

null - example example - mesh example - splineshape exampleShape

The logic behind some of these rules follow from how 3ds Max and Maya name their parent transform & child geometry nodes. That carries over to this hierarchy optimizer in the FBX exporter.

Output geometry instancing (use instancing to reduce file size)

If this checkbox is checkmarked then the mechanism of "instancing" will be used to try and keep the size of the FBX file as small as possible. For example, if the source scene has 1000 bolts all derived from the same mesh primitive data, and the 1000 items have been placed in the Okino scene graph via "instancing" then during export to FBX only a single copy of the geometry mesh data will be exported to FBX, but with 1000 virtual copies made of it. These virtual copy instances merely act as indexes to the original mesh primitive data instead of being full copies, which can significantly reduce the size of the final output.

Note: FBX does have one key setback with its concept of instancing. Any instance which uses a different material from another instance will require that the base geometry be duplicated. Thus, 500 red colored bolts and 500 blue colored bolts will require 2 materials (red and blue), 2 duplicated copies of the base geometry (assigned to the red and blue materials), and 1000 instance nodes.

If this checkbox is disabled then unique and explicit copies of mesh data will be output to the FBX file regardless of whether each copy is exactly the same as previous copies already exported.

Note 2: instancing is disabled on both the Okino FBX importer & exporter by default. So, if you are testing the round-tripping of a file with instancing then please make sure to enable the Okino FBX “instancing” checkbox on both the importer and exporter options dialog boxes.

Output Cameras

If this checkbox is checkmarked then all perspective and orthographic cameras will be output to the FBX file as either targeted (look-from, look-at) or “free” cameras. Near and far clipping plane values will also be output.

Simple info note: FBX uses FOV (field-of-view) to define the width of the perspective projection plane whereas it uses ZOOM to define the width of an orthographic projection plane.

Output As:

Target-based (“look-at”) cameras

Choosing this radio button will cause all cameras to be created as FBX "Targeted cameras". Targeted cameras use 2 nodes, one for the "Look-From" location and one for the "Look-At" location. FBX will always orient the targeted camera so that the "Up" vector points straight up (as compared to Okino software, and other 3D programs, which allow a third, explicit "Up vector" to be orientated in any direction).

Two nodes will be output to the FBX hierarchy, one with the same name as the Okino camera definition and the other named with a “.Target” appended to it.

Rotation-based (“free”) cameras

Choosing this radio button will cause all cameras to be created as FBX "free cameras". Free cameras use a single node which defines the Look-From location and an arbitrary rotation matrix to orient the camera. The Okino camera “roll” value will be output as the FBX “bank” angle in radians.

Free cameras do not exhibit “Euler gimbal lock” when the camera “goes over the poles”, that can otherwise happen with targeted cameras.

Simple info note: FBX’s free-cameras point down the positive-Z axis when they have zero-rotation. However, FBX’s positive-Z axis is equivalent to Okino’s negative-Z axis.

Output NURBS Surfaces (as polygonalized mesh geometry)

This combo box determines whether trimmed NURBS geometry within the Okino database will be exported to FBX as tessellated mesh data, untrimmed NURBS surfaces or Trimmed NURBS surfaces. The latter is default.

Allow Multiple Trim Regions Per Patch

If this checkbox is checkmarked then a single FBX NURBS geometry node will be exported which has multiple “FBX Trim Regions”.

If this checkbox is not checkmarked then multiple copies of the FBX NURBS geometry node will be exported, each one with its own, unique “FBX Trim Region”.

Improve Compatibility by Restricting Handle Names (Recommended)

Older versions of the FBX file format have rather restrictive rules for the naming of node names (such as for instances, lights, cameras, etc). If this checkbox is enabled (check-marked) then all characters will be removed from a node name and replaced with the underscore for characters which are not A-Z, a-z, 0 to 9 or the “dash”.

Mesh Processing Options Panel

This panel controls options which process the 3D geometry prior to be exported to the FBX file.

Reverse (flip) vertex normals and polygon orientations

If this option is enabled (checkmarked) then the orientation of all polygons will be reversed, indirectly causing the vertex normals to also face in the opposite direction. For example, if the vertex normals of the object currently all face inward then this function will cause all of the vertex normals to face outward, and cause the orientation of each polygon to flip between clockwise and counter-clockwise.

Sort polygons by materials

Checkmark this checkbox to cause the order of the polygons in the processed mesh data to be sorted according to the names of the material (surface definitions) assigned to them. Normally the polygons are output in the same order in which they exist internally in the database. However, some scenes may benefit from fewer material state changes from one polygon to the next, so enabling this option will cause the polygon order to be changed so that each run of polygons will only use the same material assignment.

Explode by material assignment

Checkmark this checkbox to cause each mesh object to be exploded by the assigned material definitions. One or more meshes will be output to the FBX file in succession, each using a different material assignment.

Optimize texture coordinate list

Checkmark this checkbox to have the any duplicated uv texture coordinates removed.

Perform "Polygon Reduction" on mesh data

If this checkbox is enabled (check-marked) then the FBX exporter will apply the global polygon reduction algorithm to each mesh object just prior to them being embedded in the FBX file.

The algorithm allows the number of polygons in the scene to be greatly reduced. The parameters used to reduce the polygons can be modified by pressing the "Edit Polygon Reduction Global Options" button. Press the "Help" button on its corresponding dialog box to learn more about the polygon reduction system.

Allowed Polygon Types

These options determine how polygonal mesh geometry will be modified prior to export to the FBX file.

Want triangles only

Checkmark this checkbox to cause all polygons to be triangulated prior to output.

Want quadrilaterals only

Checkmark this checkbox to cause 5 or more sided polygons to become triangulated.

Want convex polygons only

Checkmark this checkbox to cause non-convex polygons to become triangulated

Want planar polygons only. Tolerance = #

Checkmark this checkbox to cause non-planar polygons to become triangulated. Normally vertices of each polygon lie in a single plane, but occasionally a polygon could be created for which one or more of its vertices lie above/below its averaged plane. The tolerance value specifies how far a vertex (in object space coordinates) must be away from the polygon's averaged plane for the polygon to be considered non-planar.

Curves Options Panel

This panel controls the output of 3D NURBS curves and 3D spline shapes to the FBX file. Such curves will be output as NURBS curves to the FBX file or in some cases they can be converted into renderable polygon meshes or trimmed NURBS surfaces.

Output independent 3D NURBS curves

The Okino core software has a very extensive NURBS curve sub-system. Each NURBS curve object can have 1 or more NURBS curves associated with it. Multiple curves inside a single object can either be considered to form a single continuous "composite" curve, or each curve can be considered unique, closed, planar (in world space) and oriented such that the curves of the object can be directly converted into a trimmed NURBS surface (in other words, the first curve forms the boundary of the surface and subsequent closed curves form the holes).

The following options control how the various NURBS curve configurations can be converted during the export phase.

If 'renderable flag' is enabled in the NURBS curve primitive:

If the Okino 'renderable' flag of a NURBS curve primitive is internally enabled, and the curve(s) form closed loops, then it is possible to convert the NURBS Curve primitive into a renderable, closed 3D polygon or a trimmed NURBS surface.

The following options define what will be done to NURBS Curves primitives during the export phase when their 'renderable' flag is enabled:

Output as if the ‘renderable flag’ was not set [ no change ]

The Okino NURBS curve primitive will be converted into a corresponding FBX NURBS curve.

Convert and output as polygon mesh

The closed NURBS curve primitive will be converted into a mesh object prior to export.

Convert and Output as Trimmed NURBS Surface

The closed NURBS curve primitive will be converted into a corresponding trimmed NURBS surface (patch). If the conversion process cannot be made then it will be output as a polygon mesh instead.

If 'renderable flag' is not enabled:

If the 'renderable' flag of a NURBS Curve primitive is not enabled then the curves will be considered just as plain curves that cannot be seen when rendered. In this case, the following options define what will be done to NURBS curves primitives during the export phase when their 'renderable' flag is disabled:

Output as NURBS Curve (allow composite curves) [ No Change ]

The NURBS Curve primitive will be converted into a corresponding FBX NURBS curve. If the source curve has multiple segments then it will be exported as a FBX "composite curve”.

Output as NURBS Curve (single curve only)

The NURBS Curve primitive will be converted into a corresponding FBX NURBS curve. If the source curve has multiple segments then it will be exported as a single unified FBX NURBS curve.

Output independent 3D spline shapes

The Okino core software has an extensive spline primitive sub-system. This primitive accommodates one or more spline curves per primitive. If the multiple spline curves are each closed then the overall Spline Shape is termed "renderable" and can be thus converted into a polygon mesh or a trimmed NURBS surface. For example, the letter "B" can be defined by 3 Bezier curves, the first forming the outer boundary and the latter two forming holes.

Note, that unlike the NURBS Curve primitive, each spline curve of the Spline Shape is composed of only a single curve segment (no composite spline curves are allowed).

The following options control how the various Spline Shape configurations can be converted during the export phase. The Spline Shape primitive also handles almost every major spline type (Bezier Spline, B-Spline, Cardinal Spline, Linear Spline, Tensioned Spline, TCB Spline), and their internal cross conversion (between spline types) or between the various spline types and a NURBS curve.

If 'renderable flag' is enabled in the spline shape primitive:

Output as if the ‘renderable flag’ was not set [ No Change ]

The Spline Shape primitive will be exported as a resampled FBX NURBS curve.

Convert and output as polygon mesh

The Spline Shape primitive will be converted into a polygon mesh object prior to export.

Convert and Output as Trimmed NURBS Surface

The Spline Shape primitive will be converted into a corresponding trimmed NURBS surface (patch). If the conversion process cannot be made then it will be output as a polygon mesh instead.

If 'renderable flag' is not enabled:

Convert and Output as NURBS Curve (allow composite curves) [ No Change ]

The Spline Shape primitive will be resampled into a corresponding FBX NURBS curve. If the source curve has multiple segments then it will be exported as a FBX "composite curve”.

Convert and Output as NURBS Curve (single curve only)

The Spline Shape primitive will be converted into a corresponding FBX NURBS curve. If the source curve has multiple segments then it will be exported as a single unified FBX NURBS curve.

Materials Panel

Materials and texture maps are assigned to mesh objects in FBX files via material definitions. This panel controls the output of the material definitions, their associated texture maps, and provide fine grained control over the tweaking and modification of each FBX material property.

!! NOTE !! if an exported scene has its texture maps looking too bright or washed out then try one of these two suggestions:

1) Enable the "Merge and mix ambient color into diffuse color" checkmark option. Then manually disable or delete the default ambient light inside of FBX.

2) Or, enable the “Set diffuse color of textured materials to white” checkmark option. This will set up better shading parameters for FBX.

Output Materials

If this checkbox is checkmarked then materials will be exported to the FBX file.

Remove unreferenced materials

If this checkbox is checkmarked then materials which are not associated with any geometry objects will not be written out to the FBX file.

If this checkbox is uncheckmarked then every material of the source scene will be written out to the FBX file, regardless of whether they are used or not by any geometry objects.

Enable texture mapping

If this checkbox is checkmarked then 2D texture maps that have been assigned to the material definition(s) will be exported to the FBX file.

Embed texture files in FBX file

If this checkbox is checkmarked then any bitmap images which are referenced by the 3D scene will be embedded directly inside the FBX file. This can make for rather large files.

Please note that this FBX exporter needs to know where the source bitmap images are located or else warnings will be reported during the export process. This can be done by pressing the “Modify Source Bitmap Image Search Paths” button located on the Bitmap Conversion Panel panel and specifying the source of the bitmap image files.

UV Scales & Offsets

Each texture map reference used in an Okino material allows for the texture map to be scaled and offset in "UV space". This combo box determines how this scale and offset information is output to the FBX file.

Do not output (ignore)

The information is not output. You would normally not want to use this option since the applied textures will look wrong if any of them have scaling or offsetting.

Output in material definition (default)

The texture's UV scale and offset values will be output inside a FBX “Texture Tag” which itself will make reference to the base FBX “Material” definition.

Shading Coefficient and Colors Overrides

These combo boxes provide hands-on control over how exported material shading parameters should be modified so that the exported model can be rendered nicely as it would have looked in the source 3D program. The two combo boxes and the single numeric text box provide you good control over the ambient, diffuse, specular, opacity and shininess shading coefficients exported to FBX.

The first drop-down combo box selects which of these shading parameters is to be modified. Each shading coefficient has its own operation that can be selected (via the second combo box) and an optional numeric text value (via the third data entry text input box). The following describes the various shading parameters that can be controlled:

Ambient Coefficient: This controls the amount of color reflected from an object based on the ambient light in a scene. A good default value is 0.1 through to 0.3 and ideally ranges from 0.0 to 1.0.

Diffuse Coefficient: This controls the amount of color reflected from an object based on the direct light shining on it. A good default value is 0.4 and ideally ranges from 0.0 to 1.0.

Specular Coefficient: This controls the intensity of the highlight color on an object. A good default value is 0.7 and ideally ranges from 0.0 to 5.0.

Opacity: This is the inverse of transparency. 0.0 will make the object fully transparent, while at 1.0 the object will be fully opaque.

Phong Shininess: This controls the width of the specular highlight seen on an object. An ideal range is 6 (very wide) to 300 (very narrow). The default is 32.

For each material shading parameter, several actions can be performed on each material shading parameter during the import process:

Do Not Export: When this option is selected, the shading parameter is set to 0, effectively making the shading channel appear black (for color channels).

Export Unchanged: When this option is selected, the shading parameter is exported as is, with no change.

Set and Use Default: When this option is selected, the shading parameter is set to some "good" default value (as determined by the export converter). This default value will be displayed in the input text box.

Set to Specific Value: When this option is selected, the exported shading parameter will be overridden with the user specified value of the numeric input text box.

Export and Crop by: When this option is selected, the shading parameter is exported and will remain unchanged if it is less than the numeric text input value shown on the dialog box. If it is greater, then the exported value will be clamped to be no greater than the numeric type-in value. This is a good operation, for example, if you do not wish for the ambient shading coefficient to be greater than 0.3.

Export and Scale by: When this option is selected, the shading parameter is exported and multiplied by the numeric input text value shown on the dialog box

Multiply colors by material shading coefficients

Inside Okino's internal scene graph each material has a "color" and a corresponding "shading coefficient" for each ambient, diffuse and specular color definition. The "shading coefficient" can be considered a variable intensity control that brightens or darkens its corresponding color, without having to modify the color itself.

If this checkbox is checkmarked then each shading coefficient is multiplied into its corresponding color value before being exported to the FBX file material. Normally you would want this option enabled as it creates a FBX material definition which is very close in appearance to an Okino material definition.

If this checkbox is not checkmarked then only the raw colors will be output to the FBX file and their corresponding shading coefficient values will be ignored. This will typically result in brighter, bolder and punchier materials, what we ourselves term "OpenGL" shading which tends to be more saturated than colors seen in photo-realistic rendering programs.

Set diffuse color of textured materials to white

This is one of those options that may come in handy for someone with particular requirements for their textured objects in the FBX file. It is patterned after a similar option from our OpenFlight export converter.

If this checkbox is checkmarked then any material which has a diffuse texture map assigned to it will be output in such a way that its diffuse surface color will be set to white. Also, the texture’s color “mixing” mode will be set to “Multiply”

This is useful because certain real-time renderers use an "OpenGL" shading model in which the diffuse color is multiplied into the assigned texture map colors - if the diffuse material color is dark or black then the texture map will not be visible (often a problem when exporting from Maya for which the diffuse surface color is always set to black for textured materials). Enabling this option will cause the diffuse surface color to become white, and thus it will not affect the brightness of the assigned texture map.

If this checkbox is not checkmarked then the diffuse surface color will be exported unchanged.

As noted at the start of this section of help file, this option can be enabled in case texture maps look too bright or washed out within FBX (as one of two possible suggested methods).

Set specular color to white

If this checkbox is enabled then the specular material color will always be set to white (although, the white can be dimmed by changing the 'Specular Coefficient' material parameter override, as described above). If disabled, then the real material's specular color will be output.

Merge and mix ambient color into diffuse color

Enabling this checkbox will cause the material’s ambient color to be mixed into the diffuse material color before the final diffuse color is exported. Disabling this checkbox will not output any ambient material color.

Bitmap Conversion Panel

This dialog box controls how referenced bitmap texture files will be handled during the FBX export process. These two options are basically:

1. Output a filename reference to a file on the local disk. Do not modify the bitmap filename reference and do not perform any bitmap conversion. This is useful if your bitmaps are already in a format recognized by the destination 3D program.

2. Same as #1 except that bitmap file format conversion is done under user control. A file reference will be added to the FBX file, and a new bitmap image of the desired file format, and with the desired bit depth and resolution will be created.

Note that bitmap texture map images can also be embedded directly within the FBX file by enabling the “Embed texture files in FBX file” option on the Materials Panel.

Texture Bitmap Handling Method (Combo Box)

This combo box determines the preferred method to output texture bitmap disk references:

1] No Bitmap Conversion, No Bitmap Filename Changes

If this combo box option is selected then:

• The texture image will be placed in the FBX file as a texture reference.

• The filename and file path to the texture image on disk will not be changed.

• The filename extension on the bitmap reference will not be changed.

• The path to the bitmap will not be changed.

• No automatic bitmap conversion will be performed.

2] Replace File Extension For All Bitmap References

This is similar to option # 1 above, except that:

• The file reference placed in the FBX file will be changed such that its file extension is changed to that specified on the dialog box.

For example, if the option is set to 'TIFF' then all bitmap filename references will be changed so that their file extensions end in '.tif'.

This is a useful option when all of the referenced texture maps have already been converted to this desired file format on disk.

3] Auto-Convert Bitmap Files to Another Format

If this combo box option is chosen then all 2D bitmap images that are used by the current scene will be automatically tagged and converted into a new user-specified 2D bitmap file format on the local disk. The bitmap image will be written to the FBX file as a file reference and not as an embedded texture image.

For example, if the scene makes references to PNG bitmap files then this option can be selected so that the PNG images are automatically converted to the TIFF format.

If the bitmap texture(s) cannot be found in the location specified by the pathname pre-pended to the texture filename then the FBX exporter will search for the texture(s) in all directories specified in the file search paths (these can be modified by pressing the "Modify Source Bitmap Image Search Paths" button).

Converted Bitmap Format

Bitmap File Format (Combo Box)

This combo box lists the desired destination bitmap file format that all texture bitmap images should be converted into.

Bitmap Bits/Pixel: 2, 4, 8, 24 (Combo Box)

This combo lists determine the number of bits/pixel to write out to the new 2d bitmap file. The default is 24 bits. A color quantization algorithm will be used for the 2, 4 and 8 bits/pixel output formats. Not all bitmap file formats can accept 2-8 bits/pixel (e.g. in particular JPEG).

Dimensions: X = #, Y = #

These two drop-down list boxes determine the X and Y resolution for the converted bitmap file(s):

No Change	= Do not change the X or Y size
Closest	= Use the next highest power-of-2 size
2, 4, 8, ... 256, 512	= Choose a specific size for the X or Y dimension

Bitmap Output Directory

This combo box determines where the new bitmap file will be written to. Note that enabling the "Replace file paths in all bitmap file references" option or the "Strip file paths from all bitmap references" option from the 'Bitmap Image File Paths Panel' will change the path prefix for the converted bitmap even though it was saved to disk in the location specified by one of these options.

Output Converted Bitmaps To Geometry-Export Directory

The new bitmaps will be written to the directory where the exported files are being written to.

Output Converted Bitmaps To The Specified Directory

The new bitmaps will be written to the directory specified by the input text edit box (labeled as 'Output Directory'). This directory can be changed by pressing the 'Browse' button.

Confirm File Overwrites

If this checkbox is enabled (checkmarked) then the bitmap converter will confirm any potential overwrites of existing bitmap files on disk that have the same filename and extension as the one being written. If this option is disabled then no confirmation will be made.

Modify Source Bitmap Image Search Paths

In specific circumstances it may be necessary to inform the FBX exporter where your source bitmap images are located so that automatic bitmap file conversion process or the image embedding process can locate and load the images.

If the FBX exporter reports warnings that specific images could not be located during automatic bitmap conversion or embedding, then press this button so that the Search-Paths dialog box appears. Using this dialog box you can inform the FBX exporter where the source bitmaps are located.

Bitmap Image File Paths Panel

If a texture bitmap file reference is to be added to a FBX file then this panel controls what will be done to the file path of that image filename.

Path Format Combo Box

This combo box determines what kind of file path format will be used.

Use back slash (Windows-style paths)

If this option is chosen then all bitmap file paths written to the file will be converted to a Windows/DOS compatible format. In particular, directory separators will be converted to backward slashes ‘\’.

Use forward slash (Unix-style paths)

If this option is chosen then all bitmap file paths written to the file will be converted to a UNIX compatible format. In particular, all Windows and DOS specific backward slashes ‘\’ will be converted to UNIX forward slash ‘/’ directory separators.

Also, any DOS-like drive specifiers, such as “c:\” will be removed from the file path and a warning message will be reported indicating of the removal of this drive specifier (it should be ensured that all DOS-like drive specifiers are replaced by UNC specifiers, such as \\machine1\).

Use the RFC 1738 Standard (URL paths)

If this option is chosen then all bitmap file paths written to the FBX file will be converted into the "RFC 1738" URL format specification. This option is rarely needed and is provided in this exporter for convenience.

As examples:

C:\polytrans\bitmaps\texture.tif --> file:///C|/polytrans/bitmaps/texture.tif

\\machine\polytrans\bitmaps\texture.tif --> file:////machine/polytrans/bitmaps/texture.tif

Path Alteration

In most 3D graphics programs and file formats a texture map reference is defined as a relative or absolute disk-based directory path which is appended with the name of the bitmap texture map + its file extension, such as c:\files\textures\bitmap.tif. This combo box and its options allow the directory path to be stripped or replaced with something new.

No replacement (no change)

If this option is chosen then the file path and texture bitmap image reference will not be changed.

Strip file paths from all bitmap references

If this option is chosen then any file path on a bitmap image reference will be stripped off. For example, "C:\polytrans\bitmaps\texture.tif" will be output as "texture.tif".

Replace file paths in all bitmap file references

This option allows all exported bitmap references to be prefixed with a new file path. This might be useful, for example, if all of the bitmap files are located in one specific directory or if you wish to change the prefix on the exported bitmap references.

To choose the new file path press the “Browse” button.

If the “Use the RFC 1738 Standard (URL paths)” option has been chosen from the “Path Format” combo box, then the type-in edit box will instead contain the new RFC 1738 compliant “URL” and not a directory path. This user-entered URL will be used to prefix the bitmap image reference.

For example, if an original texture map references the filename:

c:\files\textures\bitmap.tif

and the new URL is specified on this dialog box as:

http://www.okino.com/images/

then the bitmap filename will be stored in the file as:

http://www.okino.com/images/bitmap.tif

Animation Options Panel

This panel controls the export "animation conversion engine". This engine allows object, camera and light animation data to be exported cleanly and properly to FBX. Okino pioneered the concept of animation cross conversion and hence has a very complex & refined “conversion engine” which is used all throughout the 3D production market.

Object Animation

If this option is enabled (checkmarked) then object animation data which is currently contained within the internal database will be exported.

Camera Animation

If this option is enabled (checkmarked) then camera animation data which is currently contained within the internal database will be exported.

Light Animation

If this option is enabled (checkmarked) then light animation data which is currently contained within the internal database will be exported.

Animation Resampling Related Options

The FBX exporter contains highly advanced animation conversion capabilities. Indeed, the animation conversion capabilities arise from some of Okino's most complex and well-designed code. Years of development effort, and feedback from users like you, have allowed us to refine our animation code into one of the most important aspects of this converter.

In particular, "animation resampling" is the hidden 'insurance guarantee' that allows all sources and types of imported animation data to be properly and ideally matched to an equivalent FBX form of animation, such that the source and destination animation data playback identically. In the ideal world the imported data from the source animation program would be fed directly to FBX, but this is not always possible, depending on the animation controllers and interpolation methods desired. "Resampling" is the process of mathematically converting the source animation data format (such as quaternion rotations + linear interpolation) into the desired destination format in FBX (such as Euler rotations + Bezier interpolation).

This animation importer will attempt to import the animation data in raw format, without any resampling, wherever possible (and thus no changes in animation data will be made). Otherwise, resampling will be used.

To minimize the amount of resampling done, and maximize your chances of getting "raw" keyframes imported, the following options should be used on this animation panel:

• "Keep Original Interpolation When Possible" checkbox enabled.
• "Keep Original Rotation Controller Type When Possible" checkbox enabled.
• "Fix up -180/180 Degree Euler Flips (Maintain Continuity)" checkbox disabled.
• All the "Force Keyframe Resampling Enables" checkboxes should be disabled on the "Animation Resampling & Reduction Options" dialog box (press the "Animation Resampling & Reduction Options" button found on this panel.

Preferred Interpolation Method (Linear, TCB, Bezier)

If and when animation resampling must be performed during the import process, it must select a target animation interpolation method. Since source animation data can possibly have controller types (such as 'constant') which cannot be readily replicated into FBX format, it is sometimes necessary to pick an arbitrary interpolation type as output for the resampling process. This arbitrary choice is left to you to choose and is selected via this drop-down box.

When the original interpolation method can be replicated into FBX format, you have a choice between keeping the original interpolation method or always using one specific interpolation method. That choice is controlled by the "Keep Original Interpolation Method When Possible" checkbox below. If you disable that checkbox, then all animation exported to FBX will be forced to use the interpolation type selected in the "Preferred Interpolation Method" drop-down box.

Keep Original Interpolation Method When Possible

If this checkbox is enabled then the animation resampling process will attempt to preserve the interpolation method used in the original source animation data. This can often be accomplished, but not in all cases. When it can be accomplished, then the animation data sent to the FBX file will preserve the same interpolation type as the original source animation data. Otherwise, the animation output to FBX will use the "Preferred Interpolation Method" you have specified above. You will typically want to keep this checkbox enabled.

NOTE: When this checkbox is enabled, keyframe resampling might still occur. However, the interpolation type of the resampled keyframes will have the same interpolation method as the original source animation data, when possible (or the "Preferred Interpolation Method" when the original source animation data's interpolation method cannot be used.)

If this checkbox is disabled then the resampling process will use the "Preferred Interpolation Method" you have specified above. If the original animation source data has a different interpolation type, then resampling must occur. If the original source data has the same interpolation type as the "Preferred Interpolation Method" you have specified above, then resampling will only occur if otherwise mandated.

Preferred Rotation Type (Quaternion, XYZ, XZY, YXZ, YZX, ZXY, ZYX)

(This option is disabled on the user interface because the current FBX file format requires Euler rotations in the XYZ order).

When we refer to the "rotation controller type" (or just rotation type), we are indicating whether a rotation animation is expressed in terms of Quaternions or in terms of Euler Angles. When rotation data is expressed in terms of Euler Angles, it is expressed in terms of some specific rotation axis order (such as XYZ or YZX). The rotation controller type of the original source animation data will have been chosen by the format-specific plugin which brought the source data into FBX. Generally, the rotation controller type of the original source animation data could vary from object to object, from camera to camera, and from light to light.

If and when animation resampling occurs on a rotation channel, the resampling process must select a target rotation type. Since repetitive-order Euler rotations (XYX, ZXZ, etc) of the source animation data are not entirely compatible with FBX's repetitive-order Euler rotations, it is sometimes necessary to pick an arbitrary rotation type as output for the resampling process. This arbitrary choice is left in your hands and is selected via this drop-down box.

Whenever the original rotation type can be replicated into FBX format, you have a choice between keeping the original rotation type or always using one specific rotation type. That choice is controlled by the "Keep Original Rotation Controller Type When Possible" option below. If you disable that checkbox, then all rotation animation exported to FBX format will be forced to use the rotation type selected in the "Preferred Rotation Type" list box.

Keep Original Rotation Controller Type When Possible

If this checkbox is enabled then the resampling process will attempt to preserve the rotation controller type used in the original source animation data. This can often be accomplished, but not in all cases. When it can be accomplished, then the rotation animation exported to FBX format will use the same rotation controller type as the original source animation data. Otherwise, the rotation animation exported to FBX will use the "Preferred Rotation Type" as specified above. You will typically want to keep this checkbox enabled.

NOTE: When this checkbox is enabled, rotation keyframe resampling might still occur. However, the resampled rotation keyframes will have the same rotation type as the original source animation data, when possible (or the "Preferred Rotation Type" when the original source animation data's rotation type is not compatible with FBX).

NOTE: The rotation type is not to be confused with the interpolation type. The selection of rotation type determines which rotation data channels are created inside the FBX file (either a single Quaternion channel or 3 independent Euler Angle channels), as well as which Euler Angle order to use (when the rotation type is not Quaternion). Each rotation channel created in the FBX file must then be assigned an interpolation type, which is determined according to the relevant options above ("Preferred Interpolation Type" and "Keep Original Interpolation Type When Possible").

If this checkbox is disabled then the resampling process will use the "Preferred Rotation Method" you have specified above. If the original animation source data has a different rotation type, then resampling must occur. If the original source data has the same interpolation type as the "Preferred Rotation Method" you have specified above, then resampling will only occur if otherwise mandated.

Maintain Euler Continuity

This option fixes exported Euler rotation channels which flip back and forth between values close to 180 degrees and -180.0 degrees, from key to key. Normally this flipping will not pose a problem unless FBX (or MotionBuilder) "slows down" an animation for previewing in slow motion, and does sub-key interpolation (in such cases the objects may appear to randomly spin in the wrong direction at specific keys). This is often a problem inside the MotionBuilder software program.

This option can only take effect when rotation curves are explicitly resampled during the import process.

NOTE: This option will not take effect if the 'Preferred Rotation Type' is set to Quaternion and the 'Keep Original Rotation Controller Type When Possible' is disabled.

Background Info:

There are several cases where the imported rotation animation needs to be "resampled" from one mathematical format to another, such as if the Euler order has to be changed, or when quaternion animation needs to be cross converted to Euler animation curves for FBX.

The resampling process first converts the imported rotation value(s) at each keyframe to a 4x4 rotation matrix, and then the matrix is decomposed into explicit (X, Y, Z) Euler rotation angles, of the desired Euler order. The Euler angles will always be in the range -180 to 180 degrees.

The primary disadvantage of the traditional Euler decomposition method comes about when the target program (DirectX, MotionBuilder, Maya or MAX) attempts to view the animation in a "slow motion" mode. Since two adjacent frames might have values of, say, -179.9 and 179.9 (or vice versa) on one of the Euler angles, the sub-frame interpolation between these values will result in a quick spin through 359.8(!) degrees, rather than the intended 0.2 degree change. When a "slow motion" mode is not in effect, the user will traditionally never see the sub-frame interpolated values because the -179.9 and 179.9 rotations are absolute and correct values (needing no further interpolation between them).

Problem example: if the imported source rotations are 150.0 deg, 179.0, deg, 185.0 deg, 190.0 deg then after resampling the rotations will be 150.0 deg, 179.0 def, -175.0 deg, -170.0 deg. These are correct. However, programs like MAX, Maya, MotionBuilder and DirectX, during slow-motion playback where sub-frame interpolation is performed, will look at the 179.0 to -175.0 degree interval and create new interpolated values through a 354 degree rotation interval and not the shorter 6 degree rotation.

What This Option Does:

Enabling this option will allow an additional algorithm to be used which detects cases of "-180/180 degree Euler Flips" and attempts to fix them. This alternative algorithm will take the previous frame of animation into account when performing rotation resampling. It will attempt to decompose the rotation into a equivalent set of Euler angles which represents the smallest Euler-space change of values. This makes the algorithm very good for preventing -180/180 discontinuities in the Euler animation curves. This allows "slow motion" sub-frame interpolation to function as ideally expected.

One possible down-side to this alternative algorithm is that Euler angles are free to "drift" away from the normal -180/180 range. Let us suppose you have an animation of a spinning top. Under the traditional algorithm, the top might spin from 0 to 180, then a discontinuity effect occurs, causing the next frames to go from -180 to 0 to 180, and so forth. With this option enabled, the top would spin from 0 to 180, then from 180 to 360 to 540, and so forth. There are hypothetical scenarios where users might not want that to happen. If that is the case, disable this option to ensure that all angles are clamped to the -180/180 range.

Animation Resampling and Reduction Options

Pressing this button will show the animation resampling and reduction options dialog box. This, in general, controls the precision and reduction options used globally during animation resampling (for both import and export). If you find that your imported animation data looks jittery or does not hit target translations/rotations, then reduce the tolerance values.

If you disable keyframe reduction, then resampled animation data will have a key at every frame. You might have a specific reason to desire that output. Leaving keyframe reduction enabled, but setting the tolerance values to zero, will result in a curve which perfectly fits the original curve at all frames, but has all redundant keys eliminated. For example, if a channel is actually non-animated, then leaving keyframe reduction enabled with a zero tolerance will result in far fewer keys than entirely disabling keyframe reduction.