I agree that you want to be able to author a rotation pivot in *tools* (e.g. scene or cutscene editors). But why do you want this for run-time? Say we have just a rotation, rotation pivot and translation track which are animated. At export I can evaluate the transform and export a single rotation and translation track . At run-time I evaluate, blend and finally compose these back into a matrix for the renderer. Note that I am not exporting a matrix as you suggest in your post, but I collapse all tracks into three (translation, rotation, scale). Are you arguing that the pose at each frame will be noticeable different from composing the matrix from each track at run-time? Run-time animation systems are usually designed for performance and memory. What you are describing seems more computational and memory expensive then it needs to be. A final pose in a game is usually a combination (blend) of many active animations in the game. Even if you don't hit the poses in each animation exactly it will be hard to notice since there are so many animation layered on top each other. From my experience animations don't look good if they don't blend together well. This is usually addressed these days by animating the rig and then run the IK solvers at runtime (e.g. Destiny does this). Can you elaborate more about the problems you had with your system and what you think the reasons were?

EDIT:

I just gave it more thought. Mathematically both methods create *exactly* the same matrices for a specific keyframe at run-time. Given whatever N tracks you use in your animation system the following holds:

Track1 * Track2 * ... * TrackN = Local Transform = T * R * S

So both systems hit the *exact* same pose (within the usual floating point tolerance) at each keyframe. The question is now what happens between the keyframes when we interpolate. What we will get will depend on many things. If your animator is using Euler keyframes for rotation and you export as quaternion the results will be different. If you don't fit the exact same curve as Maya (or any other tool), your result will be different. Good looking animation is about hitting strong expressive keyposes which I do and it is what the animator ultimately is authoring. The more I think about it the less understand the benefit of what you are suggesting. What is the problem your system solves for a run-time animation system? Maybe with an example...

23 hours ago, Dirk Gregorius said:

I think it will much easier for the OP as a first step to simply iterate each frame over each bone in the skeleton and export the local transform similar to what I have shown above for the skeleton. 

Here is an example  how to read an animation from an FBX file. It is the simplest I can come up with to give the OP the basic idea. It will give you the frame rate and length of the animation clip and the keyframes as an array of poses. 

void RnAnimation::Read( FbxScene* Scene, FbxAnimStack* AnimStack, const std::vector< FbxNode* >& Nodes )
    {
    
    }

Thank you for your feedback. I checked your results against my previous results from my first foray into FBX and they somewhat match except that my old code is a lot more bloated. I notice you didn't mention anything about a bindpose or comparing against a bindpose to actually get the mesh to move in the viewport which brings me to some questions: 

I assume I'll be recomposing the vector4 T/R values to get my Model matrix at runtime...looking at my XML file how would I approach doing that when I have so much data? Do I need to compare against a bindpose? I wrote into the XML the decompT/R per joint per frame. In my .abjmesh file I have pos/uv/tan/normal/boneIdx/boneWt information for each vertex. This example mesh rig animation is just half a torso rotating a shoulder up and then to the center like in L. Spiro's example but over a 50 frame duration animated at 24fps.

To sync with the game loop I need the delta time per frame like L.Spiro said, but how do I stay in sync with reading from my XML file if things get heavy and bogged down ? Do you have any next steps after your previous example? I made this XML file from reference from the TLang1991 tutorial.

The bind pose is usually the transform of the exported skeleton. You can also get the bindpose from the FbxClusters, but it should only rarely be different from your skeleton pose in the model. So my two code samples will give you the pose of the exported skeleton and the animated poses. At run-time you now can create poses for the skeleton. In a first step I would simply animate and render the skeleton. That should be pretty simple, but will give you confidence your data is correct. The next step is then binding the skeleton to your mesh. This is called skinning. The skinning information is stored in so called FbxCluster which you get from the FbxMesh. The simplest approach to deform the mesh using skinning is something like this:

std::vector< Vector > VertexPositions;
std::fill( VertexPosition.begin(), VertexPositions.end(), Vector::Zero );
  
for ( each Cluster )
{
    // You need to associate clusters wit bones (usually done by name and then by index at run-time)
	Matrix Transform = Pose->GetBone( Cluster ) * Inverse( Skeleton->GetBindpose( Cluster ) );
    
    for ( int Index = 0; Index < Cluster->GetVertexCount(); ++Index )
	{
  		int VertexIndex = Cluster->GetVertexIndex( Index );
  		float VertexWeight = Cluster->GetVertexWeight( Index );
  
  		VertexPositions[ VertexIndex ] += VertexWeight * Transform * Mesh->GetVertexPosition( VertexIndex );
	}
}

For skinning you have two options. For each cluster (bone) you store the vertices and weights it influences. Games do it often the other way around. For each vertex your store the bones and weights. The later is better for GPU skinning, though I don't know if this is still true now we have all these different shader stages. Maybe someone else can answer this. Let me know if this helps. I can dig up some code using real FBX examples.

This here is a really good course on animation. It will explain many concepts in an accessible way.

https://cseweb.ucsd.edu/classes/wi18/cse169-a/

Also the book 'Game Engine Architecture' has a very good and comprehensible entire chapter on animation:

https://www.gameenginebook.com/

Keyframe animation and skinning are actually two very simple problems. Unfortunately most of the resources and examples on this topic are very bloated and unnecessarily complicated. It is somewhat difficult to find good examples. 

28 minutes ago, Dirk Gregorius said:

The bind pose is usually the transform of the exported skeleton. You can also get the bindpose from the FbxClusters, but it should only rarely be different from your skeleton pose in the model. So my two code samples will give you the pose of the exported skeleton and the animated poses. At run-time you now can create poses for the skeleton. In a first step I would simply animate and render the skeleton. That should be pretty simple, but will give you confidence your data is correct.

 

So you mean creating a series of locators or small boxes with GL_LINE / GL_LINE_LOOP and apply the recomposed model matrix to them?

40 minutes ago, L. Spiro said:

 

Everything in that XML file (which is still not an appropriate file format for models) should be loaded into memory at load-time.  Nothing here needs to be streamed in in real-time.


L. Spiro

In what file format should I save my translated vertex data and skeleton data then in your opinion? This is for my solo development at home as a hobby, not to sell a game at this time but still I would like to know what the "right" format is.

Quote

So you mean creating a series of locators or small boxes with GL_LINE / GL_LINE_LOOP and apply the recomposed model matrix to them?

Yes, e.g. simply evaluate an animation and then draw the pose. That means simply for each bone draw a line from the bone world position to its parent world position. Once you have this working we can move on to skinning.

Quote

In what file format should I save my translated vertex data and skeleton data then in your opinion? This is for my solo development at home as a hobby, not to sell a game at this time but still I would like to know what the "right" format is.

Whatever format you are fine with. For your hobby project the first goal is that you can export models and animations from a DCC application and load it into your game.

@L. Spiro.

Thanks for sharing this information! I understand your points though I am not sure I agree with everything. Of course one can always just implement the most general system as a solution to a problem, but without knowing what the real gameplay requirement were that needed to be addressed in your linked videos it is a difficult to have a discussion about implementation. There is never one answer to a problem.

As a side note. What I suggested  is not necessarily how I would implement an animation system in a AAA engine. I chose a specific example which I found to be the best introduction for the OP on this topic. 

I feel we are hi-jacking the OP thread here since we were talking about basic skeletal animation and not AAA production animation systems and engine integrations. 

Quote

(https://computergraphics.stackexchange.com/questions/4491/detect-a-lossy-matrix-decomposition

This is a typical example of when people don't understand what they are doing. If you support non-uniform scale the matrix cannot be decomposed into TRS anymore. You would need something like:

struct Transform
{
	Vector3 Translation;
	Quaternion Rotation;
	Matrix3 Stretch;
}

You can use Polar Decomposition and then you can just linearly interpolate the stretch matrix. This is sloppy implemented in many engines out here. My favorite example is Unity with its 'LossyScale' element. A positive example is Granny from RAD which handles all of this properly.

This is a good example of what I meant in my earlier post. Of course you can have the most general system, but it usual casts a long shadow into other engine parts and you need to understand the consequences. Many game engines still don't allow run-time bone scaling. A good compromise is uniform scale in my opinion. I suffer in particular from bad decisions here since writing rigid body transform back into a badly defined bone hierarchy is a major pain in the butt