[SOLVED!] coordinate-handedness confusion

[KristyB]

What coordinate system do lDraw parts ACTUALLY use? The documentation *says* "Right handed with -y up", but shows a picture of a left-handed -y up coordinate axis.

Further - how would I go about translating the matrix to a left-handed +y-up format? I am trying to read ldr files inside of UE4, and the typical method of flopping the y/z coords and negating x/y/z is not working.

[Roland Melkert]

What coordinate system do lDraw parts ACTUALLY use? The documentation *says* "Right handed with -y up", but shows a picture of a left-handed -y up coordinate axis.

Further - how would I go about translating the matrix to a left-handed +y-up format? I am trying to read ldr files inside of UE4, and the typical method of flopping the y/z coords and negating x/y/z is not working.

It is right handed, to get the y up it only rotates 180 degrees around x.

the picture might be confusing because it shows an arrow pointing up labeled -Y (if it was left handed it would be labeled just Y)

[KristyB]

to get the y up it only rotates 180 degrees around x.

Oh my god this would have taken me forever to work out, that the whole system rotates to get -y Up rather than just flipping the sinage of Y. Thank you!

Is there anywhere I can submit to have this note considered to be added to the documentation?

[Travis Cobbs]

Oh my god this would have taken me forever to work out, that the whole system rotates to get -y Up rather than just flipping the sinage of Y. Thank you!

Is there anywhere I can submit to have this note considered to be added to the documentation?

Flipping the signage of Y would turn it into a left-handed coordinate system.

[KristyB]

It is right handed, to get the y up it only rotates 180 degrees around x.

the picture might be confusing because it shows an arrow pointing up labeled -Y (if it was left handed it would be labeled just Y)

I'm flipping the LDR files Y/Z coordinate to switch from left-handed to right-handed coords, and then rotating 180 degrees about the x-axis to get -y up like you said, but the bricks are all still mis-aligned.

https://imgur.com/a/EwC2rc0

Picture one shows the flipping of each coordinate in a single line of ldr including each vector in the rotator, picture 2 shows flipping the axis of the rotator. I'm not entirely sure the axis of the rotator need to be flipped after each vector component's axis has also been flipped, but I have tried plugging it in straight through and still get garbled location and rotation placements.

[Travis Cobbs]

Don't multiply any axes by -1. Simply rotate 180 degrees around the X axis.

[Roland Melkert]

https://imgur.com/a/EwC2rc0

To go from right handed (LDraw) to left handed (UE4) you need only to flip one axis, I think flipping the Z one is best.

But you need to do that after the whole model is loaded and assembled/flattened into a mesh.

After the z flip you need to do an additional rotation to compensate for the LDraw neg Y up and Unreal's weird z is up orientation.

But the z flip alone should give you a clean model, it will just sit on its side or something without the additional rotation.

Even without the z flip it should be a solid model it will only be mirrored.

So the most important thing is to make sure you assemble the LDraw data correctly, before worrying about the coordinate system.

[KristyB]

To go from right handed (LDraw) to left handed (UE4) you need only to flip one axis, I think flipping the Z one is best.

But you need to do that after the whole model is loaded and assembled/flattened into a mesh.

After the z flip you need to do an additional rotation to compensate for the LDraw neg Y up and Unreal's weird z is up orientation.

But the z flip alone should give you a clean model, it will just sit on its side or something without the additional rotation.

Even without the z flip it should be a solid model it will only be mirrored.

Thank you for all the help so far!

I've tried just passing the rotation and location coords straight in to setting the location and rotation of each brick, but the model it produces is still garbled beyond simply needing rotated/flipped at the end.

The ldr file I'm using for importing:

Code:

0 Untitled Model
0 Name:  UntitledModel
0 Author: 
0 CustomBrick
1 15 0.000000 -24.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 40.000000 -24.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 80.000000 -24.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 120.000000 -24.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 160.000000 -24.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 120.000000 -24.000000 -40.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 80.000000 -24.000000 -80.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3003.dat
1 15 0.000000 -24.000000 90.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 3039.dat
1 15 30.000000 -24.000000 80.000000 0.000000 0.000000 -1.000000 0.000000 1.000000 0.000000 1.000000 0.000000 0.000000 3039.dat
1 15 80.000010 -30.000010 70.000000 1.000000 0.000000 0.000000 0.000000 0.000000 -1.000000 0.000000 1.000000 0.000000 3039.dat
1 15 110.000000 -20.000000 70.000000 0.000000 0.000000 -1.000000 -1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 3039.dat

Image of the stud.io file I generated the ldr from: https://i.imgur.com/3L3CUqW.png
Actual stud.io file I'm using, in case there's something hinky going on with Stud.IO's ldr exporter: https://drive.google.com/file/d/1xGRxNRW...sp=sharing
The results in UE4: https://i.imgur.com/242mQB0.png

So the most important thing is to make sure you assemble the LDraw data correctly, before worrying about the coordinate system.

I'm pretty confident I'm parsing the ldr lines correctly, but I'll post my node setup and explanation, as well as a preview of the output of the first line of the above ldr here as well.

Step 1: https://i.imgur.com/0UoYYXl.png
The ldr string is parsed into an array ArtificalBrickArray01, delimiting each array entry by the newline character, i.e. each entry in the array should be one line of ldr file. The commented section removes the first four lines, 0 through 3, and stores them in it's own array SetInfo, so that ArtificialBrickArray01 is just brick color/location/rotation/brickID info.

Step 2: https://i.imgur.com/vrzfOsf.png
BrickSet is an array of a custom data structure called ldrLine that follows the line type 1 format: https://i.imgur.com/QlmJMlm.png 'file' is for 'brickID'.
Step 2 loops through ArtificialBrickArray and turns each line into it's own array delimitied by a space, ' '. Each array then has each element stored into it's appropriate spot in an ldrLine structure, and has that ldrLine structure added to the end of an array 'BrickSet', resulting in an array of ldr data that can be easily broken into it's base components.  The function that does this is pretty straightforaward: https://i.imgur.com/CUijzd9.png

Step 3: https://i.imgur.com/j5c14Ot.png
The rest of the code has already been shown. From here the array of ldrLines is iterated through, each line is broken, and sorted into it's component vectors for location, and each axis of the rotator. The code in the upper right simply uses the brickID to locate a mesh in a directory, then adds that component to the blueprintInstance, scales it, and then moves on to the brick placement, which I've shown before but will show again for completion's sake.

Step 4: https://i.imgur.com/QL3xtVl.png
Pretty straight forward. I am just plugging the Location(here poorly named 'Position') into UE4's built-in SetRelativeLocationAndRotation, using the built-in Make Rotator to make a UE4 rotator out of the ldraw rotation axis.

A line from the array of ldrLines: https://i.imgur.com/hm1SI3q.png
As far as I can tell this, and every element of the array, lines up perfectly with the lines of code in the ldr file.


And finally, the actual project zipped and uploaded to gDrive: https://drive.google.com/file/d/1zq24FAv...sp=sharing
I'm not sure if asking to look at the UE4 project is in bad-taste or not when asking for help, but I'm at the end of my ability with this project.

[Roland Melkert]

And finally, the actual project zipped and uploaded to gDrive: https://drive.google.com/file/d/1zq24FAv...sp=sharing
I'm not sure if asking to look at the UE4 project is in bad-taste or not when asking for help, but I'm at the end of my ability with this project.

I actually wanted to take a look at UE4 at some point, but I have zero experience with it at the moment

Maybe this weekend if there aren't too many hoops one must jump trough in order to download it.


I think the main problem is I assumed you imported the whole model as a single mesh, but it seems you are using loose bricks.

This means you need to convert the LDraw type 1 line matrices the same way the brick meshes did.

Where did the brick meshes come from?

[KristyB]

I actually wanted to take a look at UE4 at some point, but I have zero experience with it at the moment

Maybe this weekend if there aren't too many hoops one must jump trough in order to download it.


I think the main problem is I assumed you imported the whole model as a single mesh, but it seems you are using loose bricks.

This means you need to convert the LDraw type 1 line matrices the same way the brick meshes did.

Not a lot of hoops to jump through if you're on Windows, you do need an Epic account though. Not sure about Mac, on Linux I had to compile it myself. Which wasn't terribly hoop-jumpy, I've seen worse with a lot smaller projects. HMU if you want help with any of it.

And yep, I'm aiming to build something that let's users drop an ldr file in their compiled game and have the engine read it on load to build a model out of it, hopefully to be released open-source as a tool for other game developers to use.

I'll walk through the z-flip of the type 1 lines here to make sure I am doing it right.
Flipping the z-axis for each set of coords in a line type 1: https://i.imgur.com/sBgsRFp.png
Results: https://i.imgur.com/l1p57El.png

Also flipping each axis of the rotator: https://i.imgur.com/ugFZC9t.png
Results: https://i.imgur.com/aH6oViE.png
Similar to just flipping the z-axis for each set of coords, but note the bricks on the bottom are more garbled.

Where did the brick meshes come from?

I downloaded lDraw's entire database, then import each .dat file using Toby Nelson's lDraw Importer: https://github.com/TobyLobster/ImportLDraw. I leave origins and orientations as-is. I then export as an fbx using the default transform settings, which are "-Z Forward, Y Up". This seems counterintuitive to me, but when I import them into UE4 (again using default import settings), they load visually being upright. For the project I am working on I will have to import and export every single brick anyways, so if there's transform settings here that you think would work better I could tinker with that.

[Roland Melkert]

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.

[KristyB]

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.

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'.

"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.

[KristyB]

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?

[Roland Melkert]

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.

[Roland Melkert]

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':
   

Hope that makes it more clear.