FBX Binary Export: bake space transform (change of up axis, scale) into all transforms and vertices instead of only the root transforms #39251

Closed
opened 2014-03-18 16:46:51 +01:00 by Jens Restemeier · 10 comments

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.

[0005-bake-space-transform-change-of-up-axis-scale-into-al.patch](https://archive.blender.org/developer/F81721/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.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Bastien Montagne was assigned by Jens Restemeier 2014-03-18 16:46:51 +01:00
Author
Member

Added subscriber: @jrestemeier

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!

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!
Author
Member

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.

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'

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!

Feature committed as 53f7bbde2c. I had a hard time making it work in parenting cases… :P Thanks for org patch!
Author
Member

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...)

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. ;)

No, this is not, indeed, sorry about that! Right one is b0d241f079. ;)
Author
Member

I just looked through that, you don't seem to normalise normals after transformation. The global_matrix may contain a scale value, IIRC.

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.

Ouch… good point. Would rather normalize global_matrix_inv_trans though, much better for performances.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#39251
No description provided.