FBX Binary Export: bake space transform (change of up axis, scale) into all transforms and vertices instead of only the root transforms #39251
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#39251
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
0005-bake-space-transform-change-of-up-axis-scale-into-al.patch
This is a bit more complicated, and I wish I could test it with animations, but they don't seem to be implemented in the new exporter, yet. This is a port of my code for the old Ascii exporter, so it should work if animated transforms are handled the same way.
In a nutshell:
If T is a transform and G is the global_matrix, which includes the change to the up axis (for example Z up to Y up for Unity) and any scale factor from the export options, the current code does:
T' = G * T
to nodes in world space only.
My suggested patch applies:
T' = G * T * G^-1
to ALL matrices and
V' = G * V
to all vertices. (And the inverse transpose to all normals.) This is only active if "bake space transform" is checked in the export options, which defaults to off.
I prepared a unity package to explain it in detail. Create an empty Unity project and import the .unitypackage from here into it:
http://www.restemeier.org/BakeTest.zip
I'm using Unity 4.3. This will give you a bunch of example blender files and unity scenes. The models are from http://opengameart.org/ .
First have a look at Assets\Models\cubes\bake_test_2.70.blend in Blender.The parent node is at (0,0,2), the child node is at (0,0,6) in world space (0,0,4) in parent space. Neither cube has any rotations.
Now open Assets\Scenes\cubes.unity and look at bake_test_2.70 in the scene graph. The Parent node is at (0,2,0) which is fine, but has a rotation of 270 degree around X (or -90). The Child node is at (0, 0, 4), which means the up axis for this one hasn't changed. This is with the default export options.
Now look at bake_test_270_bake with the new option. The parent node is at (0,2,0), with no rotation. Additionally the child node is at (0,4,0), which means logically the up axis has changed there as well.
Now have a look at Assets\Scenes\dwarf.unity. The interesting bit there are the _scale versions. They have a scale factor in the .fbx export options. fixed_2.70_bake_scale looks correctly scaled, including the armature and skeleton. Skinning works correctly.
The last scene Assets\Scenes\benny.unity was to test animations, but animations seem to be missing so far.
OAQ: (obviously asked questions and discussion points.)
Q: Why is this important?
A: The -90 degree on root nodes causes a few problems in Unity, for example with instancing. If you plant trees onto terrain the instancing code only grabs the mesh data and ignores transforms, because the transforms are used to place the mesh. To work around this without this patch you'll have to place geometry sideways in Blender before exporting, an unintuitive and error-prone process.
Q: Why is it a bad idea to switch this on by default?
A: If you already exported models with the old exporter and used them in the scene or in prefabs then the old transforms were used. If you then reexport them with the new exporter it will break scenes, prefabs or code that used the old transforms.
This should have been the default if this code was in the very first version of the exporter, as it may fix problems with other engines as well, but it's a bit too late for that now.
Q: Can we change the name of the option?
A: Sure. This was just a name I picked when I wrote the code, and I'm not a native speaker. If you can think of a better name please use it.
Q: Should we apply it right away?
A: I'd like to test it with animations, first, though if you understand what this change does it is easy to apply to animations when you implement them. You could hide the option if you want me to test it first once Animations are implemented.
Q: Does this have anything to do with right handed / left handed coordinate systems?
A: No, it doesn't change anything related to that. Unity seems to do a good job applying rhs-to-lhs automatically, so the exporter doesn't have to worry about that.
Changed status to: 'Open'
Added subscriber: @jrestemeier
Uuuuh… this looks pretty much involved, but I think I have the big picture at least - afaiu, this is same issue as reported by one of my testers, i.e. it is often nice to get objects with null rotation, even if UP/Front axes are not the same between Blender and importer app… I actually did not wanted to dive into this, but if you’ve already done the work… :)
Will take some time to understand this fully, thanks for the code anyway!
Yes, I think it is the same problem.
I was considering if I should delay this patch until after animations are implemented, but I think the earlier it is talked about and tested by other people than me, the better.
One thing you most likely want to change is if there is a more efficient way to transform vertices and normals with a matrix. At the moment I'm unpacking the array into Vectors which is probably not the best way, but I'm not familiar enough with the Blender APIs.
Changed status from 'Open' to: 'Resolved'
Feature committed as
53f7bbde2c
.I had a hard time making it work in parenting cases… :P
Thanks for org patch!
Is that the correct changelist? It seems to be related to another bug.
(You could've just rejected the patch and asked me to fix it...)
No, this is not, indeed, sorry about that! Right one is
b0d241f079
. ;)I just looked through that, you don't seem to normalise normals after transformation. The global_matrix may contain a scale value, IIRC.
Ouch… good point. Would rather normalize global_matrix_inv_trans though, much better for performances.