Limitations Of Fbx And Other Exchange Formats For Materials And Nodes
Loss of Material Information
When exporting materials from one 3D software package to another, certain types of material data can be lost or simplified. This is especially true when using exchange formats like FBX, which only supports a subset of possible materials.
Missing texture maps and nodes
One major limitation is that procedural or nodal texture networks generally do not translate between applications. For example, a material in Blender using multiple texture nodes mixed together will likely export to FBX as a simplified material using only basic color and texture map properties. Any complex node network will be lost entirely.
Simplified material network
Similarly, even basic node materials may export as simplified non-nodal materials. For example, a PBR node setup using separate texture maps for properties like base color, metallic, roughness, normals, etc can export to a basic “lambert” style material with only a color and monolithic texture map.
Loss of procedural textures
FBX also does not support procedural texture types like clouds, wood, voronoi, musgrave, etc. These complex generating and noise algorithms for textures have no equivalent in FBX. When exported, procedural textures will either be lost entirely or baked down to an approximate static texture map.
Loss of Node Data
In addition to issues with materials, various types of nodal data on objects can also fail to transfer reliably between applications. Animation, physics, constraints, and parameter drivers are examples of object data that is not officially part of the FBX format specification.
Animation and physics nodes stripped
Any complex animation or simulation rigs built with nodal networks or visual scripting tools will likely not export properly to FBX. This includes rigs for skeletal animation, lattice and mesh deformers, physics simulations, particle systems, etc. Only basic static mesh geometry and simplified materials tend to make it through.
Constraints lost
Another common issue is that constraints like child-of, floor, limit distance, rotation limits, etc often do not transfer via FBX. This can lead to animations failing to behave properly when imported into other software missing those constraints.
Drivers not transferred
Drivers and rig parameters that control aspects of animation via expressions, scripts, relationships, etc also tend not to be included in FBX files. For example, a character rig with facial controls driven by morph target sliders would lose all those driver relationships on export.
Workarounds
While FBX does have limitations in these areas, artists and developers have come up with some workflows and workarounds to compensate.
Bake textures and use images
For procedural and nodal textures, one option is to “bake” them – rendering the texture down to a static image file before export. The image texture can then be transferred even if the nodes cannot.
Recreate materials manually
Complex materials with many layers, masking, blending modes, etc will need to be manually re-built in the target application from scratch after export. Tedious resconstructing work, but necessary if those nuanced material features are essential.
Export animations instead of actions
Rather than attempting to export rigs and constraints, another approach is to bake animations down to animated mesh geometry, and then transfer those baked animations between programs. This obviously only works for static renders and not interactive content.
Alternatives
While FBX is a widely adopted exchange format, there are alternatives emerging that address some of these issues of lost data.
glTF retains more material data
The glTF format specifications include more robust definitions for physically-based rendering (PBR) materials. Software that supports exporting or importing glTF files tends to preserve more details of PBR materials compared to FBX.
Alembic handles better large sets of animation data
Alembic files are designed specifically for storing rich animated data including complex hierarchies of transforms, deformers, constraints etc. This makes Alembic better suited than FBX for transferring animation rigs between applications.
Recommendations
Based on these issue and limitations observed, here are some recommendations for working with FBX and material/node transfer between applications:
Check exchanged files thoroughly for errors
After exporting and importing FBX data between programs, carefully inspect the results in the target system. Check for missing elements,broken hierarchies, deassignment of materials, loss of animation data, and other errors.
Use FBX mainly for static meshes without complex nodes
Limit FBX exports to fairly basic static geometry and non-procedural materials whenever possible. Maintain rigging, animation, procedural materials etc in native formats rather than trying to force transfer via FBX.
Consider glTF or Alembic for materials and animations
For critical animated and rendered content, experiment with glTF and/or Alembic pipelines as potential alternatives to error-prone FBX transfers.
