Getting the correct IG Euler angles for a world node

[Amerio.Stephane]

Hello,

I need to find the correct IG Euler angles of a node placed in the world. To be more clear:

• there is a node placed in the world at some specific coordinates, with some specific orientation
  • node->getWorldPosition() and node->getWorldRotation()
• I need to place a CIGI entity at the exact same spot, with the exact same orientation
  • what is the code to be used to find these values? (world can be flat OR round!)

What I am currently doing:

const Vec3 xyz = node->getWorldPosition(); // actual XYZ position
const Vec3 geo = ig->getConverter()->worldToGeodetic(xyz); // actual GEO position
const vec3 rot = ig->getConverter()->rotationToEulerIG(node->getWorldRotation()); // actual Euler rotation

But the Euler angles computation feels wrong to me. Shouldn't the converter use the position to compute the angles? (as it may depend on the location, if we are not exactly at the origin of the projection)

Or am I missing something?

[silent]

Hi Stephane,

Thank you for the report.

We’ve been able to reproduce the issue. Our QA team is investigating the root cause; our leading suspect is the recent transition to Clang as the default compiler on Windows.

We will get back to you when we would have more information (hope it would be quite soon).

[Amerio.Stephane]

Hum there may be a misunderstanding. I'm not reporting a compilation issue, more like a logic issue.

[silent]

The issue here is that with clang compiler there is an additional rounding error occurred when you are using these methods (in position the error maybe 30cm, with angles about 1-2 degree), so currently there is no way to validate the conversion.

For example, for 2.19 if precision is not enough you could use the following code to test (change Z axis angle):

Vec3 geo_position = ig_manager->getConverter()->worldToGeodetic(node->getWorldPosition());
quat zero_rotation = ig_manager->getConverter()->getZeroRotation(geo_position);
vec3 euler_rotation = ig_manager->getConverter()->rotationToEulerIG(inverse(zero_rotation) * node->getWorldRotation());

and see if it produce better results.

But in 2.20 the rounding error is far bigger and there is no way to compensate it. As a result, the rotation would be always incorrect.

[Amerio.Stephane]

Just so I better understand it: the rounding error is caused by all computation made in float instead of doubles? or is it more deep than that?

Could you provide maybe something like Converter::rotationToEulerIG( dvec3 geoposition, vec3 world_rotation) to internally bypass the inverse matrix computation and accumulate less errors?

As it is, we can't position objects correctly nor report the correct position and orientation for long distance range findings.

[silent]

The key point is that this rounding error occurs only in 2.20. After we switched the default Windows compiler from MSVC to Clang, an overly aggressive optimization path may have introduced numerical inaccuracies (unrelated to float vs. double coordinates). We believed we had addressed similar issues, but it appears that some Geodetic functions are still affected.

We're treating this as a bug and are actively investigating. Once we identify the root cause, we'll determine the appropriate fix.

Thank you for your patience and for bringing this to our attention.