Coordinate system orientation
-
- 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
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
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
-
- 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
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
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
-
- 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
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
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
-
- 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
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
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
-
- 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
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: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?
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
-
- 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
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
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
-
- 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
Hi Mark,
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.
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.Mark Christy wrote:However, from memory X = Easting Y = Northing and Z = Elevation
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
-
- 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
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
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
-
- 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
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: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!
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.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?
Jed
-
- 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
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:
That rotation is then applied to the OpenGL stack:
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
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));
Code: Select all
glRotated(q.getAngle().degrees, q.getAxis().x, q.getAxis().y, q.getAxis().z);
(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