- User Since
- May 16 2013, 10:29 PM (317 w, 3 d)
Mar 17 2015
Aug 27 2014
This was added to the new binary FBX exporter. You'll have to either export your model manually or tweak the Unity export script to use the binary exporter.
I'm not sure if it is in the 2.71 release, but it is definitely in the current nightly build.
Aug 25 2014
Yes, sorry. My proposal was to implement it first as part of the FBX code so that it can be tested, and evaluate how to best move it into generic code.
Aug 19 2014
By the way, the importer turns it into this:
The reason is that it tries to keep the axis aligned to the original axis, so that animation controls work similar to the original file. This is with "ignore leaf bones".
I made a simple two-bone skeleton in motionbuilder:
(What a weird user interface!)
Aug 14 2014
Example File:(I'm not sure why it is so big...)
Screenshot in Unity:
I could offer this change, which unfortunately is on top of D735: FBX Exporter: (Optionally) add leaf bones and change bone orientation. It handles more cases, but may be easier to break by changes.
The current code as it is now doesn't work for me at all. Children are off by 90 degree.
Parenting to lights or cameras isn't going to work either, baked or not baked, because you apply MAT_CONVERT_* to them and don't correct in children.
I was waiting for your test results, so this just fixes the whitespace problems, adds '''slots''' and changed the debug print function.
Yes, I know. That model uses Empties, and from what I understand you don't like the bake to be applied to empties because you removed it several times.
Aug 13 2014
This revision is probably the smallest version that gives the correct result for models required for game development. It doesn't handle all edge cases that the my more complicated version does, but that would probably be too hard to maintain.
Aug 12 2014
Aug 11 2014
Can you get me an FBX file from MotionBuilder?
Maya implements bone length with an extra joint at the end of a chain. That's why I added the "ignore leaf bone" option.
By the way, I tried what Maya thinks about "Limb" nodes, and they come through the same way as "LimbNode" nodes. The "Size" property is used for the bone head/tail radius.
I must say, I'm quite happy with this code, not only because I spent more than a week writing, debugging and testing it. :) I think it is a big step ahead over the limitations of the old importer, and from now on there should really be only minor fixes required. The work on the exporter will be significantly easier and much smaller, mostly keeping track of 1-2 matrices and some debugging, mainly because we know what all the data means and what it is for.
Aug 10 2014
@Bastien Montagne (mont29), I just tried the files in Unity and got a similar result, i.e. the Blender orientation is 180 degree off from the Maya direction. Both are off 90 degree from the correct direction, but then again Unity doesn't make any attempt to import lights or cameras in the first place.
So I guess we have a bug, or we hit some odd compatibility/workaround code path in the FBX SDK.
@Bastien Montagne (mont29) : That is possible. I am using a system like that for the importer to fix the bone orientations and I can try that out in the exporter when I make bone orientation work in there. Though the transform stack is specified in the SDK, so there shouldn't be any variation in there. It may be simpler to use local transforms so that matrix decomposition can be used like it is now.
I think the pre/post rotations were introduced so that nodes map 1:1 to Maya transforms.
The default orientation is specified in the FBX SDK ( http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/ ) , for example for lights: "By default, a FbxLight points along a node's negative Y axis." or for a camera "By default, a FbxCamera points in the direction of the node's positive X axis." The expectation is that any 3d package convert from and to this orientation automatically. For example Maya camera and lights point towards negative Z, but it converts when reading or writing FBX.
Aug 9 2014
Okay, there seems to be some strange stuff going on...
2.50448e-06 is very small, probably the result of rounding error. It's normally not a problem.
BTW, a picture:
Fix for spotlight exported from Maya: D729: FBX exporter/importer
Exported FBX file. (You may have to extend the falloff of the spot light a bit to see it properly.)
The spotlight is off by 180 degree... something I'll have to fix right away in the importer. :)
Aug 7 2014
Aug 3 2014
Yes, this was old stuff against the ascii exporter and they are already in the new binary exporter.
Aug 1 2014
No idea... the version used for FBX Viewer originally shows the problem and the version I've got installed on my machine shows it.
I had an interesting observation with the old ascii exporter. If you switch to the FBX 6.1 ASCII exporter when writing the model the result doesn't show the jaw problem. Though I didn't have time to compare the output files, yet. (I've got to make some progress on my scheduled work...)
Just a quick update: I was able to reproduce it in FBX Viewer (https://code.google.com/p/fbxviewer/ ) . I had to port it to the latest version of the FBX SDK because the API changed quite a bit...
The problem seems to be related to the FBX SDK (at least version 2013<= and 2015) and animations, but just the skeleton looks fine. Both work fine in Unity3D.
The data in the FBX file looks fine, so maybe the SDK just gets confused by something. You would expect this to break the whole model instead of a single bone, though.
Jul 31 2014
Do you have a link for "Banzai viewer"? Is it this one: http://bonzaiengine.com/modelviewer.php ?
Sorry, I didn't know I could do that myself.
Submitted to git: rBA551f78e6863f
Jul 30 2014
No problem. Ryoko, which application is used to view the FBX file?
I think Campbell may have already committed the customprop stuff.
- the same file exported as fbx-ascii
Now in git after a long struggle: rBAb3fdb7d6cc41
Jul 29 2014
- renamed export-specific settings into FBXExport*
- renamed FBXSettingsImport into FBXImportSettings
- added ColorRGB and ColorRGBA types
- removed debug print
- grouped import settings by use
Jul 28 2014
Argh... I noticed some leftover debug code: line 1331 print (image.items())
- ascii fbx file generated by test program
- bin fbx file generated by test program
Jul 20 2014
It is a duplicate, have a look at T40907 for a workaround.
Mar 21 2014
I just looked through that, you don't seem to normalise normals after transformation. The global_matrix may contain a scale value, IIRC.
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...)
Mar 18 2014
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.
Feb 24 2014
(I assume escaping for ampersand is optional. My own code handles it, but I don't have a Max license to see which characters are escaped by default.)
I am missing this feature from Blender 2.69. Was there a problem with it or should I resubmit a patch against the new fbx exporter script?