Hi, I'm working with a 3rd party lib which works with set coordinate systems (i.e. right handed coordinate system with Z as up) to place things / add effects. However the application im working with is using a spherical world (planet scale). I know I can assume that when I am close enough to the surface it can be treated as relatively flat. The problem is that the lib requires a projection and model view matrix passed in to update its view each frame, but this view matrix would need to be rotated in relation to the internal coordinate system the lib is using (right handed with Z as up) before being passed in. I considered using long / lat / elevation vectors to get the needed forward / up vectors to feed the view matrix:

// Pos is the xyz camera position in the world
// vFor is the forward vector from the cameras transform
// vUp is the up vector from the cameras transform

Vector3 uvh = Terrain::GetInstance()->LonLatHfromXYZ(pos.x, pos.y, pos.z);
Vector3 targetUvh = Terrain::GetInstance()->LonLatHfromXYZ(pos.x + vFor.x, pos.y + vFor.y, pos.z + vFor.z);
Vector3 aboveUvh = Terrain::GetInstance()->LonLatHfromXYZ(pos.x + vUp.x, pos.y + vUp.y, pos.z + vUp.z);
Vector3 upUvh = aboveUvh - uvh;

But these vectors are then normalized when the lib sets the view (in order to cross product them), which, because of thier height components, messes with the extraction of the frustum planes from a combined matrix (view matrix * proj matrix). Getting a frustum like: RIGHT_PLANE: x:-0.0003, y:0.0000, z:-1.0000, w:997.833374 LEFT_PLANE: x:0.0003, y:0.0000, z:-1.0000, w:997.774536 BOTTOM_PLANE: x:0.0000, y:0.0003, z:-1.0000, w:997.811523 TOP_PLANE: x:0.0000, y:-0.0003, z:-1.0000, w:997.796387 FAR_PLANE: x:0.0000, y:0.0000, z:1.0000, w:111683.046875 NEAR_PLANE: x:0.0000, y:0.0000, z:-1.0000, w:997.239746 At a random camera point looking down at the surface. It seems like the frustums side plane normals are almost aligned with the normal of the near plane? So this long/lat approach doesn't seem like its going to work. I need a way to take the camera's current up and forward vectors, get rotated versions of them to be relative to the fixed coordinate system the library is using, then passing it in. Is there a 'proper' way to go about constructing this? Thanks for reading, any help would be great.

Sorry for such a big post, I guess a shortened version of what im asking is:

Is it possible to rotate arbitrary 'forward' and 'up' vectors (from the cameras transform) so that they conform to a fixed coordinate system? So that it will create a local view where I can assume a flat x,y with z as up at the camera location.

Thanks.

Hi,

Sorry to bump this again, but does anyone have any ideas?

thanks.

Quote:but does anyone have any ideas?

I read your posts a couple of times, but I don't fully understand the problem.

I will say that I think you could probably do whatever it is you're trying to do without dealing with spherical coordinates at all. However, since I don't know what sort of behavior you're trying to implement exactly, I can't really be any more specific than that.

Quote:Original post by Hodgman
You've got 3 vectors (f/r/u) that define the local coordinate system of your camera? These 3 vectors are all perpendicular to each other?

You're trying to generate a matrix that will transform things from this local coordinate system into a different coordinate system?

Yes, correct, and this is what I need to do.

The 3rd party library that i pass a view matrix into has a fixed coordinate system it expects to work with. Lets say the camera is above Australia and is looking down at the surface, its forward/up/right vectors would be completely arbitrary, so if I pass a look-at view matrix contructed with those vectors into the library it will fail as it assumes the view is relative to its coordinate system.

I need the ability to rotate these vectors to create a view matrix that is relative to the fixed coordinate system that the library is using. So that at that point on the globe I can assume the surface under the camera is an assumed flat x,y plane with z as up. Even though the surface is curved, the part where the camera is looking would be relatively flat.

I hope I am making sense.
Thanks.

Quote:The 3rd party library that i pass a view matrix into has a fixed coordinate system it expects to work with.

Can you tell us what the library is?

If not, can you explain what you mean by 'fixed coordinate system'? (I'm really not sure what that means out of context - none of the graphics libraries or APIs that I'm familiar with can really be said to have a 'fixed coordinate system', I don't think, so I'm not sure what exactly that would mean and what the implications would be.)

Quote:Can you tell us what the library is?

I'm attempting to integrate speedtree into the application.

When i mean 'fixed coordinate system', I mean that at initialization I have to tell speedtree what coordinate system they should use for rendering / shaders / billboards etc (either right or left handed coordinate system, with either 'Y' or 'Z' as up). I set it as a right handed coordinate system (same as the app) with positive Z as the global 'up'.

So im attempting to rotate the view matrix extracted my camera to some kind of local frame that will be relative to what speedtree is expecting. I'm just confused as to the steps of how to achieve that.

Sorry for the confusion.