Free Support Forum - aspose.com

Transformation confusion in Node

I have a fbx file with a small node hierarchy. At the root there is no transformation at all, but in the level below there are some. The strange thing is that the Node.Transform and Node.GlobalTransform gives different result. Also node.Transform.TransformMatrix gives also another transformation than the Node.Transform.

Here are the values printed:

transform.Translation: (-82167.960938 -101406.03125 -205951.96875)
transform.EulerAngles: (90.000003 0 0)
transform.Scale: (1 1 1)
globalTransform.Translation: (-82167.960938 -101406.03125 -205951.96875)
globalTransform.EulerAngles: (0.000003 0 0)
globalTransform.Scale: (1 1 1)

As you see the difference is the euler angles.

VegaNils.zip (893.4 KB)

@fredrik955

Thank you for contacting support.

Would you please share narrowed down sample application reproducing this behavior, so that we may investigate further to help you out.

I have narrowed it down to a single C# file. Please change the filenames on top of the file.Files.zip (894.7 KB)

The fbx file is also attached in the same zip. The program prints the Transform, the GlobalTransform, and both matrices. The matrix I get is also wrong, and not according to the Transform.

Can you please answer back to this address: nils.fremming@cognite.com, I am now assigned to this bug.

I hope you can expain this for us,

Regards,
Nils Petter Fremming

@fredrik955 @fremming

Thank you for sharing requested data.

We have logged a ticket with ID THREEDNET-449 in our issue management system for further investigations and resolution. The ticket ID has been linked with this thread so that you will receive notification as soon as the ticket is resolved.

We are sorry for the inconvenience.

Is there any progress on this? I have this problem.

@anderscognite

Thank you for contacting support.

We would like to share with you that Aspose.3D gives correct global transformation that has Euler angles (0 0 0) which is different to the local Euler angle (90 0 0).

The reason it has this “unexpected” result is that there is a PreRotation attribute defined in the node with value (-90 0 0), you can also find out this value in “Autodesk FBX Converter” tool. So a rotation (90 0 0) with a pre-rotation (-90 0 0) will eventually result into a rotation (0 0 0).

Moreover, The PreRotation and PostRotation is also exposed through Node.Transform. Since Node.GlobalTransform is a lazy evaluated property, it calculates the value only when you need it, and it decomposes the final global transformation matrix into Translation/Rotation/Scale. That is why they are all read-only properties, the Pre/Post rotation become meaningless in the global transformation.

We hope this information will be helpful. Please feel free to contact us if you need any further assistance.

aspose_bug_reproduce.zip (894.8 KB)

Thanks for answering. We have implemented the post and pre rotation, and this is not an issue anymore.

However, the last node in the hierarchy is still wrong located. It is shifted about 400 units up, comparing to other applications. We have been working hard to detect why, and figured out that there is a issue with how Aspose load the fbx file. In the code I have enclosed, I have compared the global matrix both in Aspose and the official FBX stk, and getting a significant difference. The node is called “P1705081404” in the hierarchy and is the last one.

For us this is a really show stopper and we have been working hard to encapsulate the issue.Further investigation has lead us to that you do not load the “Geometry translation” of the node itself.

Can you please take a look at it and give us feedback.

@fremming

We have recorded your feedback with the ticket for further investigations and will let you know as soon as any further update will be available in this regard.

Do you have any progress on this issue?

@fremming

Thank you for getting back to us.

We are afraid it is currently reopened and any updates are not available at the moment. We have recorded your concerns and will update you as soon as any significant information will be available in this regard.

@fremming @fredrik955 @anderscognite

Thank you for being patient.

We are glad to inform you that the ticket THREEDNET-449 has been resolved in Aspose.3D for .NET 19.7. Please feel free to contact us if you need any further assistance.

Thank you for this fix. But we still have som issues here. We actually want a function that can give us the Matrix for the geometry transform. We have looked in the code and the method for this is internal and obfuscated (as of Aspose 19.7.0). For the moment we had to make a great hack to get this function by refleksjon.

So, I ask you to make this function public, so we actually can get the matrix for the nodes correct, and avoid the hack in the code. It might also be useful for the rest of the Aspose community.

@fremming

We have added a new method EvaluateGlobalTransform in Node class:

/// <summary>
/// Evaluate the global transform, include the geometric transform or not.
/// </summary>
/// <param name="withGeometricTransform">Whether the geometric transform is needed.</param>
/// <returns></returns>
public Matrix4 EvaluateGlobalTransform(bool withGeometricTransform);

We have created a hotfix for you. Aspose.3D for .NET 19.8.1

Thank you! We implemented it today and it seem like it work fine. BUT we have looked at it and it seem that the AssetInfo.UnitName, AssetInfo.CoordinatedSystem and AssetInfo.UpVector are all null when we try to load it. In the NavisWorks, another aappication we use for loading, these are set to something other than default, unit is for instance “mm”, and the up vector is (0,1,0). Cean you please take a look at it again!

VegaNils.zip (893.4 KB)
The file is here

@fremming

Thank you for your kind feedback.

Information like vendor, software are placed in scene.AssetInfo while measurements, coordinate systems are stored in scene.RootNode.AssetInfo. This design was learnt from Collada, although it may cause confusions.

The scale factor can be retrieved from scene.RootNode.AssetInfo.UnitScaleFactor which is 0.001, the unit name was null because it is undefined in the FBX file (Found by using Autodesk FBX Converter). Default unit measurement name in FBX is centimeter where it is meter in Aspose.3D, so the unit of shared file VegaNils.fbx is actually 1mm (0.001m)

And the Up vector is X axis, as it can be retrieved from scene.RootNode.AssetInfo.UpVector, it is unusual, but in the FBX file the raw value of up vector here is 1, according to FBX SDK:

enum EUpVector { eXAxis = 1, eYAxis = 2, eZAxis = 3 }

So it actually has a X axis as up vector in the FBX file.

Coordinate system was not properly set from the FBX file, but you can still get the raw FBX setting values using following code:

Scene scene = new Scene();
scene.Open(@"VegaNils.fbx");

string[] keys = { "UpAxis", "UpAxisSign", "FrontAxis", "FrontAxisSign", "CoordAxis", "CoordAxisSign", "OriginalUpAxis", "OriginalUpAxisSign", "UnitScaleFactor", "OriginalUnitScaleFactor" };
foreach(var key in keys)
{
Console.WriteLine("{0} = {1}", key, scene.RootNode.AssetInfo.GetProperty(key));
}

We hope this will be helpful. Please feel free to contact us if you need any further assistance.

Thanks for answering. But another problem appers on some of our files. It is regrading the geometry transformation again, it seems like Aspose’s geometric rotations are PI / 180.0 of what they should be (meaning they seem to interpret radians as degrees somewhere). A temporary workaround may be to rescale the rotation ourselves, but we would need to make sure this is removed when the bug is fixed in Aspose. Area you able to fix this ASAP? Should be very quick since we had describe the bug and how to fix it.

Cube_Combied_with_geometric_transform.zip (130.2 KB)
Here is the file.

Capture.PNG (38.4 KB)
Here is a more detailed description if this helps.

@fremming

Thank you for the details.

We are looking into this and will get back to you soon.