FBX Export Uses World Axes, not Component Axes

I bought a Pro license so I could export to FBX. Works fine, but when I read the FBX file in Unity, it appears that all components in the model hierarchy have had their local axes (the ones I assigned when I created the components) replaced with the world axes. This makes the FBX file pretty much useless because things like humanoid/robotic animations depend on rotations around local origins (forearm rotates around the elbow, entire arm rotates around the shoulder, and so on).

Is there any way to keep the local axes for child components when I export a model to FBX?

I tested to see if the swap z for y option made a difference, it didn’t. Exporting Collada seems to keep the local axes ok.

Thanks for the research and reply, colin. Unity’s FBX Exporter also preserves the local axes, so the FBX format must allow it. Collada doesn’t do much for me, I’m afraid, as my goal is to meet a criterion Unity imposes for models they are willing to sell on your behalf (and that criterion is that your polygon meshes must all be in FBX or OBJ format).

Now, if one is willing to decompose a model into its individual components and export them one by one, the local axes and the world axes are the same for each such individual. Reassembling the hierarchy in Unity after exporting them is a work-around. But, man, is that tedious! Also seems very error prone.

Do you thinks this ought to become a bug report to Trimble? They’ve supported FBX exporting for so long, I’m kind of amazed this is how it works. (So much so, in fact, that I’m still wondering if I’m just missing something that would be obvious to more experienced FBX users.)

I will check to see who might be interested in exporter issues. They don’t get updated too often!

Back to your Asset Store issue, couldn’t you perfect things via Collada and then export FBX from Unity? Or use Autodesk’s FBX Converter to go straight from Collada to FBX?

I just did a test, took a DAE into the FBX Converter, exported as FBX, and the axes look good in Unity.

It hasn’t been updated for about 7 years, but still works:

Yes, in fact one need not even bring Collada into the workflow. Unity does a nice job of importing SketchUp files directly (I’m using the most recent Long Term Support version of Unity, which is 2018.4, so you have to store your SketchUp files in 2018 .skp format, but that’s no problem). Once imported, Unity’s FBX Exporter seems to handle conversion just fine. The only problem I’ve noticed is that SketchUp and Unity work well together when instancing meshes, but Unity’s FBX Exporter creates a unique copy of every mesh.

That is, if your model includes, say, two identical knobs and you represent them with SketchUp components, when you import your model into Unity, Unity only uses one mesh that each of the two knobs shares with the other. That’s exactly what you want, as it is efficient and guarantees that any changes to the shared mesh will affect all models that use it.

However, Unity’s FBX Exporter creates a separate copy of each mesh. The result is that the exported model will have two meshes defined, one for each knob, even though it could have used just one mesh.

That, of course, is purely Unity’s problem, not Trimble/SketchUp’s. But, it means that if I want to make a final model in Unity’s own internal format (they call it a “prefab,” and their Asset Store criteria also require that you provide one), you have to choose between creating it from the inefficient FBX version with redundant meshes in it, or else extract one copy of the redundant meshes and replace all references to the others with that. Further, to avoid leaving the (now unused) redundant meshes in the FBX model, you have to export each component separately. It all works, in the end, but it’s just a major pain the rump.

All of that, of course, is purely my problem.

Thanks for the pointer to the DAE/FBX converter. I will give that workflow a try. Maybe it will produce FBX files without redundant meshes. If so, that might be a solution I can use.