Jump to content

[NOTABUG] Rotation values inconsistent with C#/C++


photo

Recommended Posts

After evaluating the recent Community edition of Unigine a few areas cause unnecessary friction/confusion:

  1. Rotation values are not consistent between the Unigine Editor and C# (vec3 vs quat)
  2. Using node.setRotation(node.GetRotation()) works as expected but node.setRotation(new quat(node.GetRotation().x, node.GetRotation().y, node.GetRotation().z, node.GetRotation().w)) displays a different result which makes troubleshooting difficult (tested with LightWorld node)

Trying to create a simple day/night cycle often highlights these issues, with the documentation occasionally referencing features/methods not available in the Community edition (search term: quat)

Hopefully these issues can be addressed in future releases.

Link to comment

Hello,

The coordinates of the axis and angle must be passed to the quaternion constructor quat(float x, float y, float z, float angle). In your case, you pass the quaternion components themselves, but this is not axis and angle. In order for this to work correctly, you need to create a new quaterninon, and then fill components:
 

quat rot = node.GetRotation();
quat newRot;

newRot.x = rot.x;
newRot.y = rot.y;
newRot.z = rot.z;
newRot.w = rot.w;

node.SetRotation(newRot);

 

Link to comment
Quote

 Rotation values are not consistent between the Unigine Editor and C# (vec3 vs quat)

What do you mean by that? As far as I understand you are looking for decomposeRotation*() methods? They are located here: https://developer.unigine.com/en/docs/2.11/api/library/math/math.matrix?rlang=cs#decomposeRotationXYZ_const_mat3_ref_vec3

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
On 5/22/2020 at 7:51 AM, karpych11 said:

In order for this to work correctly, you need to create a new quaterninon, and then fill components

@karpych11 @silent Thanks for the example, can you explain why the following results are incorrect? (red)

spacer.png

spacer.png

On 5/22/2020 at 8:24 AM, silent said:

What do you mean by that?

@silent The problem is consistency/continuity between the Unigine Editor and API. For example obtaining an Editor's Rotation values shouldn't be more complex than the Position or Scale (e.g. node.Position.x). If quat is necessary those values should be represented in the Editor without additional/hidden conversion.

Unfortunately discrepancies like this are important to the general user experience, especially for "Creative Enthusiasts" (i.e. non-technical)

Edited by mind.matter
Link to comment

Dear @mind.matter

Hope I can answer your questions both in technical and non technical aspects.

Quote

Unfortunately discrepancies like this are important to the general user experience, especially for "Creative Enthusiasts" (i.e. non-technical)

Fortunately, non technical users don't use API's. So everything represented in degrees and with proper gizmo's and icons and all other tools. Good for them.

Example 1: Good

Example 2: You still need to look at answer given by @karpych11

Example 3: Good

Example 4: It must be Green.

What is the fault that you see in Example 4?

If you need to understand this then you must understand IEEE:754. Floating point Rounding error.

for (double d = 0.1; d != 0.3; d += 0.1)
{
	std::cout << "Counting :: " << d << "The Value" << std::endl;		
}

This will help you to understand. The C++ code above never terminates. If you find out why? You will see Example 4 is Green.

Rohit.

Link to comment
3 hours ago, rohit.gonsalves said:

Fortunately, non technical users don't use API's.

@rohit.gonsalves Historically true but creatives are more open to experiment/tinker nowadays in pursuit of their vision.

 

3 hours ago, rohit.gonsalves said:

Example 2: You still need to look at answer given by @karpych11

@rohit.gonsalves @karpych11 Unfortunately the explanation was unclear, from a user's perspective the result of Example 2 and Example 3 should be the same (the former more concise/simplified)

 

4 hours ago, rohit.gonsalves said:

What is the fault that you see in Example 4?

@rohit.gonsalves Appreciate the explanation but the default behaviour of any value between the Editor and API should be consistent. If the Editor displays a node rotation of 80, 10, 0 the expected API result should be 80, 10, 0. Minor deviation may be acceptable to some but presenting -8.699... instead of 0 is unnecessarily confusing.

Given the Community edition appears to be targeted at "Creative Enthusiasts", with many having Unreal Engine and/or Unity experience already, these inconsistencies make a noticeable difference overall... and this is just one of a few discovered during testing (expectation vs result)

Link to comment

Dear @mind.matter,

Quote

Unfortunately the explanation was unclear, from a user's perspective the result of Example 2 and Example 3 should be the same (the former more concise/simplified)

Here is the small explanation.

In example 2 you are actually creating qauts (Complex numbers) from Cartesian axis angle. In Example 3 you are creating quat and assign quat. So two things are different. In example 2 your complex numbers are taken as axis-angle to create completely different quat.

https://eater.net/quaternions Refer this if you can generate info from this. It always takes years to understand quaternions in detail.

Quote

80, 10, 0.  and -8.699... instead of 0

-8.669443E-07 = -0.0000008669443. It is not -8.669 but almost = 0

Hope this helps... Are you using Unreal and Unity API's?

Rohit

Link to comment
4 hours ago, rohit.gonsalves said:

In example 2 you are actually creating qauts (Complex numbers) from Cartesian axis angle. In Example 3 you are creating quat and assign quat.

@rohit.gonsalves Thanks for clarifying though it's still a questionable semantic/syntactic technicality given node.GetRotation() and node.SetRotation() should be using interchangeable XYZW values.

 

4 hours ago, rohit.gonsalves said:

-8.669443E-07 = -0.0000008669443. It is not -8.669 but almost = 0

@rohit.gonsalves Probably true for software developers but an unexpected result for those not "In The Know". This topic alone demonstrates a clear on-boarding/migration issue despite all the due-diligence performed over the last 4 weeks reading documentation, blog posts, forum searches and training videos.

 

4 hours ago, rohit.gonsalves said:

Are you using Unreal and Unity API's?

@rohit.gonsalves Only via the Blueprint visual scripting system within Unreal Engine.

Edited by mind.matter
Link to comment

The Editor itself is also using rounding when drawing the numbers in UI. It uses FastFixedDtoa method (with fractional_count= 5) from double-conversion library:

And you get almost the same numbers when you do the DecomposeRotationXYZ. You can round them to 5 digits and you should see the same values that Editor is displaying in the UI.

We will think how to improve this behavior in the future versions of SDK.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Dear Silent,

I think Editor is fine, But as a programmer I would always like the real numbers returned by an API than some changes made by SDK before returning it.

Rohit

Link to comment
5 hours ago, silent said:

The Editor itself is also using rounding when drawing the numbers in UI...

... You can round them to 5 digits and you should see the same values that Editor is displaying in the UI...

@silent Good to know for future troubleshooting, thanks.

Link to comment
  • silent changed the title to [NOTABUG] Rotation values inconsistent with C#/C++
×
×
  • Create New...