Evaluator returns NaN values for Quaternion

[chatelain.aurelien]

Hi, 

I am currently using the FBX SDK to parse and bake animations from FBX files and I experience issues when evaluating the transform of some nodes of my scene: in some cases, the node has a scale (0,0,0) (which is actually a trick to make meshes invisible) and when I extract the quaternion from the local transform matrix, I get NaN values.

It looks obvious for me that the way the rotation is extracted from the transform matrix may not handle the 0-scale case, but I wonder if there is a way to get the good values or maybe a workaround to correctly manage animation where some scale keyframes of (0,0,0).

Thanks in advance,

Aurélien

[chatelain.aurelien]

I precise I use the 2016 version of FBX SDK.

I also add a very simple FBX sample that has a scale (0,0,0) for the first keyframe and gives a quaternion with NaN values when extracting the rotation component of the evaluator.

Thanks in advance for any help,

Aurélien

[viviane.rochon]

Bonjour Aurélien,

FbxNode actually has a property for Visibility. Could you try setting that property instead of setting the scale to 0?

void SetVisibility

(

bool

pIsVisible

)

Viviane

[chatelain.aurelien]

Bonjour Viviane, 

Thanks for your reply. I am actually reading incoming FBX files so I don't really have the possibility to force the use of visibility property instead of the scale 0 (even if it is probably the best way to do). That's why I am looking for the "best" way to handle this scale-0 case and avoid to get NaN when using the evaluator.

I also had some FBX files with invalid values in the Lcl properties, like mentionned here: http://forums.autodesk.com/t5/fbx-sdk/problem-with-fbx-file/m-p/4148134/highlight/true#M2473

The SDK doesn't seem to take care of this, if there is a scale (0,0,0) it performs it's matrix calculation and leads to NaN.

For now, I have workarounds to manage the two parts that have the issue:

 - When evaluating the static transform of the node, I check for NaNs and fallback to the Lcl Translation/Rotation/Scaling properties (I keep using the evaluator in the other cases since it helps me to make abstraction of pre/post rotations, offsets, etc)

 - To fix the evaluation during animation, I begin by checking the keyframes and replace 0 scale values by an epsilon (1.e-12 for now). The evaluator outputs good values.

Is there a better way to do this ?

Thanks, 

Aurélien

[Anonymous]

Hello,

I was just about to post the same question and then I found this thread.

I'm also using the evaluator to get position, rotation and scale for each keyframe as it makes it much easier than using curves (specially because we don't need to take care of the interpolation between keyframes).

I understand that below the FBX API, all calculations involve a few matrices, and if we have 0 scales there, we will end up with invalid matrices that, of course, return invalid scales and rotations (position is sepparate and for that reason, no problems there).

What's more interesting is that the invalid rotations and scales, should only show up, in keyframes with 0 scales, but that's not the case. As soon as I set the first keyframe to scale 0, every single keyframe beyond this one will return invalid or wrong rotations. I find this very strange and it's probably a bug.

I'm on the same boat as chatelain.aurelien, so I don't have a solution for this yet. I really want to avoid curves, because I don't know exactly how autodesk interpolates between keyframes, and without that information, it's impossible to replicate the animation correctly.

Regards.

[viviane.rochon]

Hi Aurelien and Megamau,

Here is the developer's insight:

It seems that a scaling of 0,0,0 makes an affine matrix degenerate. Since all computations on affine matrices take for hypothesis that the matrices are valid, we end up with undefined results.

In your case, the developper suggests that you do a pre-process to replace all 0,0,0 scalings to 1,1,1, and to create an animation curve on the Visibility property. This way, your code will be able to compute transforms properly, and to query the Visibility property to know if the object is visible or not.

I hope this helps!

[Anonymous]

Hello  viviane.rochon,

First, thanks for the reply.

The solution you propose could work for some cases, but not all of them. What if an artist wants his cube to start with 0 scale at frame 0 and incrementally increase it's scale to 1 at frame 30?

However you gave me an idea with the pre-process stuff. We could look for frames with scale 0, replace those with scale 1, and then when we retrieve the position rotation and scale later on using the evaluator, we could set the scale to 0 again. This way I think we could retrieve the rotation correctly.

How do we do this pre-processing? Can we change the scale values in the curves themselves?

Regards.

[chatelain.aurelien]

Hi, 

Thanks again @viviane.rochon for taking the time to follow this issue and for your answer.

Also thanks @Anonymous for your participation.

Visibility is something I don't handle for now, and even if I do, the animation of this property is not really supported.

For your solution @Anonymous, yes you can. My current solution is to check all the key values of the scaling property's curve and set a epsilon value (currently 1.e-12) in order to have a very small value that keeps the object "no visible" but allow to get good values from the evaluator.

For now, I can't guarantee it covers all the NaN cases, but it seems to work for my samples 🙂

Regards,

Aurélien

[Anonymous]

Hello again,

Ok, so setting the keyframe values to something near 0 seems to work and allows us to retrieve correct rotations (and scales of course). But let me just give an update on my situation.

I wrote in an ealy post that if I had the fist keyframe's scale set to 0 I would end up with invalid rotations for all keyframes in my animation. It turns out that the invalid rotations are in fact saved into the FBX file, probably because of the same issue with afine matrices (but on the other way around).

I was using Cinema4D for FBX export, but I imagine it happens with other exporters as well, as all of them use FBX SDK to convert their own formats into FBX.

I think that this should be taken into consideration somehow. I know that whoever implements the exporter can workaround this issue, but I'm guessing no one got into this corner case just yet.

[Anonymous]

I had to check the matrix for bad values.  If there were, set the matrix from the SRT values

	transform = pNode->GetScene()->GetEvaluator()->GetNodeLocalTransform(pNode, timeZero);


	bool badMatrix = false;
	for(int i = 0; i < 4; i++)
	{
		for(int j = 0; j < 4; j++)
		{
			if (isnan(frame.localTransform[i][j]) || !_finite(frame.localTransform[i][j]))
			{
				badMatrix = true;
			}
		}
	}

	if (badMatrix)
	{
		FbxVector4 r = pNode->GetScene()->GetEvaluator()->GetNodeLocalRotation(pNode, timeZero);
		FbxVector4 t = pNode->GetScene()->GetEvaluator()->GetNodeLocalTranslation(pNode, timeZero);
		FbxVector4 s = pNode->GetScene()->GetEvaluator()->GetNodeLocalScaling(pNode, timeZero);
		transform.SetTRS(t,r,s);
	}

You can also check for scale = 0, and the set quaternion that way.  IIRC I was checking scale = 0, but changed to this method, but I don't remember why.

I posted about this two years ago, but got no reponse.

http://forums.autodesk.com/t5/fbx-sdk/getq-produces-inf-when-scale-is-zero/m-p/4299569