Coordinate system orientation

Discuss Veesus software here, including those for Arena4D and the plug-ins for SolidWorks and Rhino.
Post Reply
apickel
I have made 10-20 posts
I have made 10-20 posts
Posts: 14
Joined: Wed Sep 09, 2015 11:08 pm
8
Full Name: Alexandra Pickel
Company Details: Lidar Guys
Company Position Title: employee
Country: USA
Linkedin Profile: Yes

Coordinate system orientation

Post by apickel »

Hi Mark,

When I overlay the compass, I notice the green arrow is pointing south, is that the positive y axis? Are you using a left-handed coordinate system?

Thanks,

Lexi
--
Lexi Pickel
[email protected]
Mark Christy
V.I.P Member
V.I.P Member
Posts: 322
Joined: Tue Aug 20, 2013 1:11 pm
10
Full Name: Mark Christy
Company Details: Veesus Ltd Arena4D.
Company Position Title: Technology Director
Country: United Kingdom
Linkedin Profile: Yes
Has thanked: 24 times
Been thanked: 45 times

Re: Coordinate system orientation

Post by Mark Christy »

Hi Lexi,

The compass is a world compass so there is no real concept of positive Y/left handed in this view.

If the centre of the earth is 0,0,0 then positive Y would tend to point up to the north pole. However when you're on the surface of the earth your local "up" is somewhat different to the globes "up".

Therefore the blue arrow on the compass always points to the north pole. The blue line points up away from the earth, the red line points east and the green line south. In some instances that may be positive Y.. in others it may be negative Z.. just depends where you are in the world.

Hope that made sense??

Mark
apickel
I have made 10-20 posts
I have made 10-20 posts
Posts: 14
Joined: Wed Sep 09, 2015 11:08 pm
8
Full Name: Alexandra Pickel
Company Details: Lidar Guys
Company Position Title: employee
Country: USA
Linkedin Profile: Yes

Re: Coordinate system orientation

Post by apickel »

Hi Mark,

Thank you for the quick reply...

I'm still not sure I understand how your transformation stack works. :?
http://imgs.xkcd.com/comics/polar_cartesian.png

I have a .obj that is in UTM 13N, x = easting - position_x, y = northing - position_y, z = elevation - position_z.

When I load this into A4D, its rotation and position are incorrect, even after I manually set the position values. How do I transform this so it will be positioned correctly? Presumably I will need to do this transform before importing, since I can't rotate objects by specific angle in A4D?

Lexi
--
Lexi Pickel
[email protected]
Mark Christy
V.I.P Member
V.I.P Member
Posts: 322
Joined: Tue Aug 20, 2013 1:11 pm
10
Full Name: Mark Christy
Company Details: Veesus Ltd Arena4D.
Company Position Title: Technology Director
Country: United Kingdom
Linkedin Profile: Yes
Has thanked: 24 times
Been thanked: 45 times

Re: Coordinate system orientation

Post by Mark Christy »

Hi Lexi,

Our transformation stack is typical OpenGL transforms, nothing special. I think the confusion is regarding the compass you referred to. The compass is obviously a compass for the earth and therefore as you move around the surface of the earth your XYZ values will change hugely (because 0,0,0 is the centre of the earth), but the compass won't move at all because it's still pointing north.. if that makes sense? E.g. At the equator looking north the compass will look the same either side of the earth, but the X or Y value will be 180 degrees different.

So.. I think simply for the moment we just ignore the compass :)

Regarding your data set, if it is in UTM 13N then you should simply select GeoReferenced when you open it and select UTM13N from the list of available coordinate systems and it should appear in the correct place in the world. If it doesn't that suggests that the coordinates aren't what we think they should be. For example, why is it x = easting - position_x and not just x = easting?

If you want we can help with this directly in real time. Please contact Matt ([email protected]) and he can do a screen sharing session with you and get to the bottom of your issue much quicker.

Many Thanks

Mark
jedfrechette
V.I.P Member
V.I.P Member
Posts: 1237
Joined: Mon Jan 04, 2010 7:51 pm
14
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 62 times
Been thanked: 220 times
Contact:

Re: Coordinate system orientation

Post by jedfrechette »

Mark Christy wrote:Regarding your data set, if it is in UTM 13N then you should simply select GeoReferenced when you open it and select UTM13N from the list of available coordinate systems and it should appear in the correct place in the world. If it doesn't that suggests that the coordinates aren't what we think they should be. For example, why is it x = easting - position_x and not just x = easting?
The position offset is being managed manually because most software doesn't support obj files with double precision floating point coordinates. Therefore we need to be able to work with this data set in both local coordinates (x, y, z) and georeferenced coordinates (easting, northing, elevation). To use the GeoReferenced import option directly I would need to write a program that adds the positioning transform to the vertex coordinates. It looks like I would also need to shuffle the coordinates since your obj importer seems to read the coordinates as:

x = easting
y = elevation
z = -northing

In addition to the y-up z-up swap, we've observed that additional rotations and translations are also present but haven't tried to reverse engineer them yet, which is why Lexi was asking for guidance. After importing ungeoreferenced, setting the X, Y, and Z positions of the object in A4D to our manually calculated values gets the model within a few hundred meters of where it needs to be, but it's not quite right. So another question would be: What is the reference point for these position values in A4D? It doesn't appear to be the origin of the data set, so is it the center of mass or maybe something else? Of course, the observed difference may also be due to the additional rotations we haven't accounted for yet.

Thanks for the help.
Jed
Mark Christy
V.I.P Member
V.I.P Member
Posts: 322
Joined: Tue Aug 20, 2013 1:11 pm
10
Full Name: Mark Christy
Company Details: Veesus Ltd Arena4D.
Company Position Title: Technology Director
Country: United Kingdom
Linkedin Profile: Yes
Has thanked: 24 times
Been thanked: 45 times

Re: Coordinate system orientation

Post by Mark Christy »

Hi Jed,

I'll need to read through some source code to give you some more detail, and I don't have it front of me right now.. so please bear with me.

However, from memory X = Easting Y = Northing and Z = Elevation, but the effects you might be seeing is our efforts to get the data pointing "UP" for those who work with non georeferenced data on the globe. So for example if you move your non georeferenced data to the surface of the earth we will apply a rotation so that it's elevation value will be pointing away from the globe. This I would think will explain some of the odd movements you are seeing as I guess you are already compensating for that in your calculations?

Maybe if you let me know your ideal way of working we can put in a mechanism that allows you to get your data in the correct location more easily?

Many Thanks

Mark
jedfrechette
V.I.P Member
V.I.P Member
Posts: 1237
Joined: Mon Jan 04, 2010 7:51 pm
14
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 62 times
Been thanked: 220 times
Contact:

Re: Coordinate system orientation

Post by jedfrechette »

Hi Mark,
Mark Christy wrote:However, from memory X = Easting Y = Northing and Z = Elevation
That's the behavior I would expect. The different mapping I came up with was based on comparing the X,Y,Z positions for the object that I see in A4D if I import georeferenced and set the projection, with the values I get if I convert the coordinates in the obj file to latitude and longitude manually. I think you're right though that this is the automatic y-up to z-up transform that's biting us.

I think the most helpful change would be to provide more direct control over each object's transform. As far as I can tell each object in A4D has 2 transforms attached to it. There is a global transform that can be adjusted by the "Move" tool, which set's the position and orientation of the object's origin. There is also a local transform that can be adjusted by the "Position" tool, which set's the position and orientation of the object's data relative to the origin. Although all of these can be adjusted interactively in the viewport, only the local transform's "Position" X,Y, and Z values are exposed in the UI. I would like to be able to type in values for the translation and rotation components of both the global and local transforms. For completeness, access to the scale values would be good too. Bonus points if I can import and export those 4x4 transform matrices to a simple txt or json format for exchange with other applications. Getting direct access to the matrix is also really helpful when dealing with applications that may apply the translations and rotations in different orders. In addition to solving the specific issue we're running in to in this thread, having better control over object transforms would allow us to start building the A4D project earlier in the pipeline, before all of the object alignments have been finalized.

As for the ideal way I would like to work for this specific case it would be something like this:

1. Import point clouds and set coordinate system appropriately (EPSG:32613).
2. Import .obj file, optionally transforming from y-up to z-up. In my case the .obj is already z-up so I wouldn't want to rotate it.
a. The default origin of the .obj data should be (0,0,0)
b. Manually update the object's transform with the x, y, and z positions we've calculated externally so that that (0,0,0) is translated to (x_position, y_position, z_position).

Basically, I just want A4D to be less clever. ;-)
Jed
Mark Christy
V.I.P Member
V.I.P Member
Posts: 322
Joined: Tue Aug 20, 2013 1:11 pm
10
Full Name: Mark Christy
Company Details: Veesus Ltd Arena4D.
Company Position Title: Technology Director
Country: United Kingdom
Linkedin Profile: Yes
Has thanked: 24 times
Been thanked: 45 times

Re: Coordinate system orientation

Post by Mark Christy »

Hi Jed,

That should all be perfectly do-able.

The reason it's the way it is, is because the vast majority of our customers work with non geo-referenced OBJ models. They then like to place it on the globe for doing videos with the lighting and sky, etc.. Therefore the software automatically rotates non-georeferenced data once it is near the surface of the earth to make sure it's pointing "up" away from the ground.

Obviously in your case that isn't proving to be particularly helpful!

If we gave you an advanced options screen that allows you to manually adjust the matrix information then it would give you as a power user far more flexibility, but it can remain hidden from those who just don't understand that world!

We're flat out on the next release of Data Studio for the end of this month so it will probably have to wait until next month if that's ok? Naturally if we manage to get ahead of schedule we can try to squeeze something in..

Many Thanks

Mark
jedfrechette
V.I.P Member
V.I.P Member
Posts: 1237
Joined: Mon Jan 04, 2010 7:51 pm
14
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 62 times
Been thanked: 220 times
Contact:

Re: Coordinate system orientation

Post by jedfrechette »

Mark Christy wrote:If we gave you an advanced options screen that allows you to manually adjust the matrix information then it would give you as a power user far more flexibility, but it can remain hidden from those who just don't understand that world!
That sounds great, as you say it isn't functionality that needs to be front and center in the UI. I guess another consideration when having precise control over the transforms is that once I set them I would also want a way to lock them so that somebody can't just grab the Move or Position tool and start dragging the object around willie nilly.
Mark Christy wrote:We're flat out on the next release of Data Studio for the end of this month so it will probably have to wait until next month if that's ok?
Not a problem. We need to deliver this project before then so I'll need to come up with a temporary workaround, which should be doable. If you could provide the transform matrix that is being applied when obj files are imported that would make my job a lot simpler since I could just invert it in our source application. Either way though, I really appreciate your responsiveness. I wish all software vendors were like this.
Jed
Mark Christy
V.I.P Member
V.I.P Member
Posts: 322
Joined: Tue Aug 20, 2013 1:11 pm
10
Full Name: Mark Christy
Company Details: Veesus Ltd Arena4D.
Company Position Title: Technology Director
Country: United Kingdom
Linkedin Profile: Yes
Has thanked: 24 times
Been thanked: 45 times

Re: Coordinate system orientation

Post by Mark Christy »

Hi Jed,

There is no matrix being applied when an OBJ file is loaded which is not georeferenced, unless you move it to the surface of the earth. Then of course there is no one matrix as it is different for every single point on the Earth.

To calculate the rotation matrix (in our case Quaternions) we calculate the angle between the "up" at "this" position on the Earth and a nominal "up" of (0,0,1). We then apply that angle to the cross product of "this up" and "nominal up".

Pseudocode would be:

Code: Select all

Vector up = new Vector (0,0,1);
Quaternion q = Quaternion.fromAxisAngle(here.angleBetween3(up),
                    up.cross3(here));
That rotation is then applied to the OpenGL stack:

Code: Select all

glRotated(q.getAngle().degrees, q.getAxis().x, q.getAxis().y, q.getAxis().z);
So ungeoreferenced data which has its Z axis as "up" is rotated so that Z is now pointing along the line that runs from the centre of the Earth to the objects current position.

(One final point to mention, which I don't think will actually effect what you are doing but is probably worth mentioning.. OpenGL treats Y as the "up" axis and Z as the "forward" axis. Therefore to make any models sit correctly we must apply a further 90 degree rotation based on the cross product of Y and Z so that the models Z axis is now pointing along OpenGL's Y axis.)

You can already "lock" the position of an object in Data Studio under its properties, there is a lock from editing check box which means the position tool won't move it. Of course if somebody unchecks that and then moves the object there's not a lot you can do about it...

Hope this clears things up a little more?

Many Thanks

Mark
Post Reply

Return to “Veesus”