LDraw.org Discussion Forums

Full Version: [SOLVED!] coordinate-handedness confusion
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I've been playing around in Unreal Engine using your project and managed to get it to convert correctly (I think).

The problem is the very confusing UE4 coordinate system, it claims to be left handed using Y pointing towards the user, Z up and X to the right.

BUT then it goes on about X is front, Y is right and Z is Up.

Yes it's still left handed but why not use this orientation every where?

The solution was partially in the existing unused "ldrRotator" function (where did that come from it seems to be part of an existing ldraw importer.).

So first step is to convert LDraw positional data into this system.

You could do this by rotating and mirroring, but it is easier to just 'map' the axis'.
[attachment=6813]

I made this macro for it.
[attachment=6814]

That's the xyz done, but the orientation part of the LDraw data needs a conversion too.

The a-i values on a LDraw type 1 line represent the rows of the orientation matrix, but UE4 "setRelativeLocationAndRotation" wants abs space vectors. So we must be sure to use the columns of the matrix as a starting point.

The xyz of each column needs to go JUST trough the coordinate shuffle.

I'm not entirely sure why it doesn't need the sign flips, but I think it has to do with the orientation being relative to the current world space (which is visually the same as in e.g. my LDCad editor).

So I only did the xyz shuffle here, using this macro:
[attachment=6815]

There is one last pitfall, the new 'front' orientation doesn't match with the loose bricks assets you used in the project, so we need to correct those by applying a 'rest orientation' before applying the LDraw orientation.

Then we pull it all together in the main blueprint, like so:
[attachment=6812]

Which renders like:
[attachment=6816]

I added a concave slope to make it more obvious 'up' is translated correctly.
(2021-09-05, 17:24)Roland Melkert Wrote: [ -> ]I've been playing around in Unreal Engine using your project and managed to get it to convert correctly (I think).

The problem is the very confusing UE4 coordinate system, it claims to be left handed using Y pointing towards the user, Z up and X to the right.

BUT then it goes on about X is front, Y is right and Z is Up.

Yes it's still left handed but why not use this orientation every where?

The solution was partially in the existing unused "ldrRotator" function (where did that come from it seems to be part of an existing ldraw importer.).

So first step is to convert LDraw positional data into this system.

You could do this by rotating and mirroring, but it is easier to just 'map' the axis'.


I made this macro for it.


That's the xyz done, but the orientation part of the LDraw data needs a conversion too.

The a-i values on a LDraw type 1 line represent the rows of the orientation matrix, but UE4 "setRelativeLocationAndRotation" wants abs space vectors. So we must be sure to use the columns of the matrix as a starting point.

The xyz of each column needs to go JUST trough the coordinate shuffle.

I'm not entirely sure why it doesn't need the sign flips, but I think it has to do with the orientation being relative to the current world space (which is visually the same as in e.g. my LDCad editor).

So I only did the xyz shuffle here, using this macro:


There is one last pitfall, the new 'front' orientation doesn't match with the loose bricks assets you used in the project, so we need to correct those by applying a 'rest orientation' before applying the LDraw orientation.

Then we pull it all together in the main blueprint, like so:


Which renders like:


I added a concave slope to make it more obvious 'up' is translated correctly.

Ahaha this is awesome, thank you so much! I can't wait to get this set up on my end.

Quote:The problem is the very confusing UE4 coordinate system, it claims to be left handed using Y pointing towards the user, Z up and X to the right.

BUT then it goes on about X is front, Y is right and Z is Up.
I think this has been part of my stumbling block. Could you link me to where you found this info, if it's still handy? All I could ever find about UE4's coordinate system was that it was left-handed, but used some right-handed import for fbx files 'for 3DS Max compatibility'.


Quote:"ldrRotator" function (where did that come from it seems to be part of an existing ldraw importer.).

That was a function I created. I disconnected it at some point, but left it in-tact in case I needed to return to it; the blueprint equivalent of just commenting out code. I'm glad I left it around if it helped.
(2021-09-05, 17:24)Roland Melkert Wrote: [ -> ]Then we pull it all together in the main blueprint, like so:

In the third image, you combined (A,D,G) (B,E,H) (C,F,I) as the rotator vectors instead of (A,B,C) (D,E,F) (G,H,I), I don't understand why? The documentation shows  [u' = a*u + b*v + c*w + x], which led me to believe that (A,B,C) form the first coordinate of the rotator, is this not so?
(2021-09-11, 11:36)KristyB Wrote: [ -> ]In the third image, you combined (A,D,G) (B,E,H) (C,F,I) as the rotator vectors instead of (A,B,C) (D,E,F) (G,H,I), I don't understand why? The documentation shows  [u' = a*u + b*v + c*w + x], which led me to believe that (A,B,C) form the first coordinate of the rotator, is this not so?

I used the 'columns' because the "make rotation from axes" component wants the abs space vectors for forwards, right and up.

The rows (abc) are the local part space vectors which point to the absolute xyz directions as seen from within the part's own coordinate system.

Given the result was correct I assumed it used the right set.
(2021-09-11, 17:32)Roland Melkert Wrote: [ -> ]Given the result was correct I assumed it used the right set.

You got me unsure about the whole thing so, i did a check in LDCad.

This is why i choose the 'columns':
[attachment=6845]

Hope that makes it more clear.
Pages: 1 2