Doug,

Thanks for your help but unfortunately it is not a timing issue—my viewer already takes care of time spans, including animations not starting at zero: it uses KFbxNode::GetAnimationInterval to read the spans and offsets the key times accordingly.  Other files that do not start at zero play just fine.

Ciao,
Dario

Doug,

It turns out I was blatantly missing to normalize vertices when the link mode was set to eNORMALIZE—shame on me…
The files I posted animate fine in my viewer now.

Thanks,
Dario

Doug,

Unfortunately I don’t have any older animated FBX files—I only have some (truly old) MotionBuilder samples, and they are just rigged, not properly animated…
I would love to test the viewer on as many animated FBX files as possible, both old and new… but I have no idea where to find reasonably decent files to test on.

Thanks,
Dario

Well, I guess an “official” test suite is still a dream…
However, it would certainly help to have a few stock models, maybe included in the SDK Extras installer.

Thanks,
Dario

I fixed my previous problem (I was not going into the bind pose before exporting the bind pose (yippy)), but now I have new data from the client (protected by NDA so I can not send it, sorry) in which only 2 joints are incorrect.  The jaw and one of the neck bones on this dragon.

I got the FBX DirectX Viewer from Mr. Rogers (thank you) but cannot build it so I cannot single-step through it.

I still have a problem (mentioned above), but this should not be related to splitting vertices.
I realized later that splitting vertices is done to put them into a format in which they can be used by hardware.  This is not what I am doing, as I am converting from FBX to another file format.  Vertices from that file format are decompressed and split correctly as long as the data in the file is correct.

My guesses as to what is causing my current problem follow:
#1: Incorrect exporting of bones or bind poses.
#2: Incorrect weights on vertices.

But neither of these make sense.
#1: How could just 1 or 2 bones be incorrect?  In one export, both of his shoulders are wrong.  Since it happens to both shoulders, there apparently is some specific thing about the data that causes it that was replicated to both bones (which are symmetrical).
#2: Again how could only some weights be wrong and not others?  The jaw moves correctly, just twice as much as it should.  The vertices are apparently attached to the correct bones, but over-weighted.  This doesn’t check out, however, as I checked the weights and they DO all add up to either 0.0f or 1.0f.  No imbalanced weights are exported, so I have no idea.

Also, the client gave me many files, one for each animation.  In each file, the model data is the same, but the animation is different.  Each converted file is corrupt in a different way, one of them a total mess.  For each file, I re-export the model and animation data together.  For each file, the model data should be exactly the same in my second format.  Yet the level of corruption varies greatly.

I have to do more research and render my bones before I can post a more informed question, but is there anything I should know about converting from FBX to another file format?  Splitting is not an issue in this case since that will happen later.

Thank you,
L. Spiro

I’m afraid that in general diagnosing FBX files issues without the actual files is quite difficult—perhaps you should convince your client to release at least one such file.

Anyways, this is just a shot in the dark, but… when you export the bone structure to your format, I assume you’re using the matrices associated with the link node in the skin clusters you’ve got to export.  Have you taken into consideration the geometric transform matrix as well...?

HTH,
Dario

Hi,

Just a hint, for your shoulder problem, check the flag KFbxNode::GetUseRotationSpaceForLimitOnly(). This might explain why “just 1 or 2 bones are incorrect”.

Viviane

Viviane Rochon
Maya Data Platform
Autodesk

I have no installed the TR1 updates, and that is why I cannot build.  But I wanted to save that amount for work for when I knew it would be applicable to the error.  As I found out, it is not.  The skinning data and splitting of vertices is fine.  The error I discovered in my file was that there was no bind pose (at least not in the format in which I expected it).

As for the limit information, just curious how to apply that.
For my animations, I use FBX to get the world transform (so the order of rotations will be handled by FBX SDK) and convert to local coordinates for each bone.

Then I play back the animation at a regular interval, being sure also to hit keyframes, and snap-shot the bone transforms at those times.

I assumed limits would be apply by the FBX SDK as I played back the animation.  Is this incorrect?

L. Spiro

You may be having the same issue that I posted here: 
http://area.autodesk.com/for...wer-for-fbx-files/page-4/

There seems to be an interpolation/evaluation problem in the FBX SDK when two rotations cross Euler boundaries.

This would explain why it only affects one or two bones.

That issue is probably causing the problem I have with jitter at the end of one of my other models not related to my current project.

What I have is a problem with the bind pose.  With the new data the client has given me I can tell easily.
Basically everything is moving twice as much as it should.
The arms flap up, neck bends back, jaw opens, etc., all with twice the range as they should.  The reason before it appeared as if only one part was wrong was because that part was doing most of the moving.  With the other parts staying mostly still I could not detect that they were all in fact wrong.

Now I just need to know how to put the mesh into bind pose for extraction of vertices.  Not the skeleton.

L. Spiro