8197a611fa
Co-authored-by: Gordon MacPherson <gordon@gordonite.tech> Co-authored-by: Andrea Catania <info@andreacatania.com> Co-authored-by: K. S. Ernest (iFire) Lee <ernest.lee@chibifire.com> This is a complete rewrite of the importer. It will give more deterministic behaviour and has been sponsored by IMVU inc, over 1 year has gone into the development of this importer to remove the burden of the FBX SDK. This was my project for 1 entire year and I really enjoyed the opportunity to add to Godot. Along the road of implementing fixes we implemented fbx pivots, animations and inheritance type handling, which in most cases works properly. We have implemented animation and mesh skinning too this should work out of the box, if there are issues let us know. It's designed so that you can expand this with ease, and fix bugs easily too. It can import from Autodesk Maya and import into Godot, with pivots. There are bits we could polish but for now this is good enough. Additional fixes made before upstreaming: - fixed memory leaks - ensure consistent ordering on mac linux and windows for fbx tree. (very important for material import to be deterministic) - disabled incorrect warnings for fbx_material - added compatibility code for /RootNode/ so compat is not broken - Optimise FBX - directly import triangles - remove debug messages - add messages for mesh id, mesh re-import is sometimes slow and we need to know what mesh is being worked on - Document no longer uses unordered maps - Removed some usages of &GetRequiredToken replaced with safe *GetRequiredToken() function - Added parser debugging - Added ERR_FAIL_CONDS for unsupported mesh formats (we can add these later super easy to do now) - Add memory debugging for the Tokens and the TokenParser to make it safe - Add memory initialisation to mesh.cpp surface_tool.h and mesh.h - Initialise boolean flags properly - Refactored to correct naming for the fbx_mesh_data.h so you know what data you are working on - Disabled corruption caused by the FIXME: - Fixed document reading indexes and index_to_direct vs indexes mode - Fixed UV1 and UV2 coordinates - Fixed importer failing to import version 7700 files - Replaced memory handling in the FBX Document with pointers, before it was dereferencing invalid memory. - Fixed typed properties - Improved Document API - Fixed bug with ProcessDOMConnection() not working with the bool flag set to true. - Fixed FBX skinning not deforming for more than one single mesh - Fixed FBX skeleton mapping and skin mapping not being applied properly (now retrieved from document skin list) - Fixed set_bone_pose being used in final version() - Fixed material properties exceeding 1.0. - FBX Document parser revamped to use safe memory practices, and with graceful error messages. - ScopePtr, TokenPtr and various internal types have been fleshed out to use proper typedefs across the codebase. - Fixed memory leaks caused by token cleanup failing (now explicit cleanup step, no shared_ptr, etc) - Fixed bug with PropertyTable not reading all properties and not cleaning up properly. - Fixed smoothing groups not working - Fixed normal duplications - Fixed duplication check for pre-existing coordinates. - Fixed performance of vertex lookup in large meshes being slow, using lookup table separate to the data for indexing, this reduces import time from 10 minutes of bistro down to 30 seconds. - Fixed includes requiring absolute path in headers and cpp files using CPPPath. Bugs/Features wish list: - locator bones - quat anim key interpolation (most fbx maya files have euler rotations from blender and maya, nobody uses this) - some rigs skins scale up when SSC enabled inconsistently per bone - some skins can disappear entirely - material mapping needs expanded, but this will be done for 4.0 as it requires rewrite. Workarounds for issues found until we patch them: - mesh -> clear skin can resolve most of the bugs above. - locators can be worked around by removing them before exporting your rig. - some material properties wont always import, this is okay to override in the material properties. **If you are having issues or need support fear not!** Please provide minimal rigs which can reproduce issues as we can't spend a lot of time investigating each rig. We need a small example which breaks and we can then sort the problem. In some cases this is not possible so its okay to privately send models to us via IRC or a ticket and we can provide an email address, we won't reveal or disclose privately sent rig files to any companies, or to companies I work for, they will not be shared, only tested and bugs will be drawn up from the conclusions. Also include identifying information about what you did and how it didn't work. Please file each file separately in a bug report, unless the problem is the same. This was sponsored by IMVU, and a special thanks to everyone who supported this project. Signed-off-by: Gordon MacPherson <gordon@gordonite.tech>
198 lines
7.6 KiB
Markdown
198 lines
7.6 KiB
Markdown
# Open Source FBX Specification for the Importer
|
|
|
|
The goal of this document is to make everything in FBX clearly stated, any errors will be corrected over time this
|
|
is a first draft.
|
|
|
|
## fbx parser - originally from assimp
|
|
|
|
- Folder: /modules/fbx/fbx_parser
|
|
- Upstream: assimp
|
|
- Original Version: git (308db73d0b3c2d1870cd3e465eaa283692a4cf23, 2019)
|
|
- License: BSD-3-Clause
|
|
|
|
This can never be updated from upstream, we have heavily modified the parser to provide memory safety and add some
|
|
functionality. If anything we should give this parser back to assimp at some point as it has a lot of new features.
|
|
|
|
# Updating assimp fbx parser
|
|
|
|
Don't. it's not possible the code is rewritten in many areas to remove thirdparty deps and various bugs are fixed.
|
|
|
|
Many days were put into rewriting the parser to use safe code and safe memory accessors.
|
|
|
|
# File Headers
|
|
|
|
FBX Binaries start with the header "Kaydara FBX Binary"
|
|
|
|
FBX ASCII documents contain a larger header, sometimes with copyright information for a file.
|
|
|
|
Detecting these is pretty simple.
|
|
|
|
# What is an OP link?
|
|
It's an object to property link. It lists the properties for that object in some cases. Source and destination based by
|
|
ID.
|
|
|
|
# What is a OO link?
|
|
Its an object to object link, it contains the ID source and destination ID.
|
|
|
|
# FBX Node connections
|
|
|
|
Nodes in FBX are connected using OO links, This means Object to Object.
|
|
|
|
FBX has a single other kind of link which is Object Property, this is used for Object to Property Links, this can be
|
|
extra attributes, defaults, or even some simple settings.
|
|
|
|
# Bones / Joints / Locators
|
|
|
|
Bones in FBX are nodes, they initially have the Model:: Type, then have links to SubDeformer the sub deformer
|
|
is part of the skin there is also an explicit Skin link, which then links to the geometry using OO links in the
|
|
document.
|
|
|
|
# Rotation Order in FBX compared to Godot
|
|
|
|
**Godot uses the rotation order:** YXZ
|
|
|
|
**FBX has dynamic rotation order to prevent gimbal lock with complex animations**
|
|
|
|
```cpp
|
|
enum RotOrder {
|
|
RotOrder_EulerXYZ = 0
|
|
RotOrder_EulerXZY,
|
|
RotOrder_EulerYZX,
|
|
RotOrder_EulerYXZ,
|
|
RotOrder_EulerZXY,
|
|
RotOrder_EulerZYX,
|
|
RotOrder_SphericXYZ // nobody uses this - as far as we can tell
|
|
};
|
|
```
|
|
|
|
|
|
# Pivot transforms
|
|
|
|
### Pivot description:
|
|
- Maya and 3DS max consider everything to be in node space (bones joints, skins, lights, cameras, etc)
|
|
- Everything is a node, this means essentially nodes are auto or variants
|
|
- They are local to the node in the tree.
|
|
- They are used to calculate where a node is in space
|
|
```c++
|
|
// For a better reference you can check editor_scene_importer_fbx.h
|
|
// references: GenFBXTransform / read the data in
|
|
// references: ComputePivotTransform / run the calculation
|
|
// This is the local pivot transform for the node, not the global transforms
|
|
Transform ComputePivotTransform(
|
|
Transform chain[TransformationComp_MAXIMUM],
|
|
Transform &geometric_transform) {
|
|
|
|
// Maya pivots
|
|
Transform T = chain[TransformationComp_Translation];
|
|
Transform Roff = chain[TransformationComp_RotationOffset];
|
|
Transform Rp = chain[TransformationComp_RotationPivot];
|
|
Transform Rpre = chain[TransformationComp_PreRotation];
|
|
Transform R = chain[TransformationComp_Rotation];
|
|
Transform Rpost = chain[TransformationComp_PostRotation];
|
|
Transform Soff = chain[TransformationComp_ScalingOffset];
|
|
Transform Sp = chain[TransformationComp_ScalingPivot];
|
|
Transform S = chain[TransformationComp_Scaling];
|
|
|
|
// 3DS Max Pivots
|
|
Transform OT = chain[TransformationComp_GeometricTranslation];
|
|
Transform OR = chain[TransformationComp_GeometricRotation];
|
|
Transform OS = chain[TransformationComp_GeometricScaling];
|
|
|
|
// Calculate 3DS max pivot transform - use geometric space (e.g doesn't effect children nodes only the current node)
|
|
geometric_transform = OT * OR * OS;
|
|
// Calculate standard maya pivots
|
|
return T * Roff * Rp * Rpre * R * Rpost.inverse() * Rp.inverse() * Soff * Sp * S * Sp.inverse();
|
|
}
|
|
```
|
|
|
|
# Transform inheritance for FBX Nodes
|
|
|
|
The goal of below is to explain why they implement this in the first place.
|
|
|
|
The use case is to make nodes have an option to override their local scaling or to make scaling influenced by orientation, which i would imagine would be useful for when you need to rotate a node and the child to scale based on the orientation rather than setting on the rotation matrix planes.
|
|
```cpp
|
|
// not modified the formatting here since this code must remain clear
|
|
enum TransformInheritance {
|
|
Transform_RrSs = 0,
|
|
// Parent Rotation * Local Rotation * Parent Scale * Local Scale -- Parent Rotation Offset * Parent ScalingOffset (Local scaling is offset by rotation of parent node)
|
|
Transform_RSrs = 1, // Parent Rotation * Parent Scale * Local Rotation * Local Scale -- Parent * Local (normal mode)
|
|
Transform_Rrs = 2, // Parent Rotation * Local Rotation * Local Scale -- Node transform scale is the only relevant component
|
|
TransformInheritance_MAX // end-of-enum sentinel
|
|
};
|
|
|
|
enum TransformInheritance {
|
|
Transform_RrSs = 0,
|
|
// Local scaling is offset by rotation of parent node
|
|
Transform_RSrs = 1,
|
|
// Parent * Local (normal mode)
|
|
Transform_Rrs = 2,
|
|
// Node transform scale is the only relevant component
|
|
TransformInheritance_MAX // end-of-enum sentinel
|
|
};
|
|
```
|
|
|
|
# Axis in FBX
|
|
|
|
Godot has one format for the declared axis
|
|
|
|
AXIS X, AXIS Y, -AXIS Z
|
|
|
|
FBX supports any format you can think of. As it has to support Maya and 3DS Max.
|
|
|
|
#### FBX File Header
|
|
```json
|
|
GlobalSettings: {
|
|
Version: 1000
|
|
Properties70: {
|
|
P: "UpAxis", "int", "Integer", "",1
|
|
P: "UpAxisSign", "int", "Integer", "",1
|
|
P: "FrontAxis", "int", "Integer", "",2
|
|
P: "FrontAxisSign", "int", "Integer", "",1
|
|
P: "CoordAxis", "int", "Integer", "",0
|
|
P: "CoordAxisSign", "int", "Integer", "",1
|
|
P: "OriginalUpAxis", "int", "Integer", "",1
|
|
P: "OriginalUpAxisSign", "int", "Integer", "",1
|
|
P: "UnitScaleFactor", "double", "Number", "",1
|
|
P: "OriginalUnitScaleFactor", "double", "Number", "",1
|
|
P: "AmbientColor", "ColorRGB", "Color", "",0,0,0
|
|
P: "DefaultCamera", "KString", "", "", "Producer Perspective"
|
|
P: "TimeMode", "enum", "", "",6
|
|
P: "TimeProtocol", "enum", "", "",2
|
|
P: "SnapOnFrameMode", "enum", "", "",0
|
|
P: "TimeSpanStart", "KTime", "Time", "",0
|
|
P: "TimeSpanStop", "KTime", "Time", "",92372316000
|
|
P: "CustomFrameRate", "double", "Number", "",-1
|
|
P: "TimeMarker", "Compound", "", ""
|
|
P: "CurrentTimeMarker", "int", "Integer", "",-1
|
|
}
|
|
}
|
|
```
|
|
|
|
#### FBX FILE declares axis dynamically using FBX header
|
|
Coord is X
|
|
Up is Y
|
|
Front is Z
|
|
|
|
#### GODOT - constant reference point
|
|
Coord is X positive,
|
|
Y is up positive,
|
|
Front is -Z negative
|
|
|
|
### Explaining MeshGeometry indexing
|
|
|
|
Reference type declared:
|
|
- Direct (directly related to the mapping information type)
|
|
- IndexToDirect (Map with key value, meaning depends on the MappingInformationType)
|
|
|
|
ControlPoint is a vertex
|
|
* None The mapping is undetermined.
|
|
* ByVertex There will be one mapping coordinate for each surface control point/vertex.
|
|
* If you have direct reference type vertices [x]
|
|
* If you have IndexToDirect reference type the UV
|
|
* ByPolygonVertex There will be one mapping coordinate for each vertex, for every polygon of which it is a part. This means that a vertex will have as many mapping coordinates as polygons of which it is a part. (Sorted by polygon, referencing vertex)
|
|
* ByPolygon There can be only one mapping coordinate for the whole polygon.
|
|
* One mapping per polygon polygon x has this normal x
|
|
* For each vertex of the polygon then set the normal to x
|
|
* ByEdge There will be one mapping coordinate for each unique edge in the mesh. This is meant to be used with smoothing layer elements. (Mapping is referencing the edge id)
|
|
* AllSame There can be only one mapping coordinate for the whole surface.
|