Re: globe trotting?
- From: DaveC <bobason456@xxxxxxxxxxx>
- Date: 13 Jul 2005 18:11:13 +1200
Ok, Thanks for that Gene, I've taken your (and others) advice and gotten
rid of the lonitude and latitude coordinants all together. Now I'm just
working with x,y,z cartesian. Good.
I still have a couple of questions, related to not yet having followed your
advice fully ;)
Here is the code I have at the moment.
// First we do the look up and down rotation on the x axis.
glRotatef(cam1.lookupdown,1,0,0);
// Then take the cam position and normalize it, this becomes the
// Up vector.
float p[3];
p[0] = mainWnd->cam1.x;
p[1] = mainWnd->cam1.y;
p[2] = mainWnd->cam1.z;
mathsNormalize(p);
// Using the up vector, I've derived a plane equation to find forward.
// based on heading.
float xt = cos(mainWnd->cam1.heading * piover180);
float yt = sin(mainWnd->cam1.heading * piover180);
float zt = (p[0]*xt + p[1]*yt) / -p[2];
// Then the look at.
gluLookAt(cam1.x,cam1.y,cam1.z,
cam1.x+xt,cam1.y+yt,cam1.z+zt,
p[0],p[1],p[2]);
Ok, so this rotates the world correctly, except I'm still confused with the
heading, I think my use of the plane equation is a little wrong, because
the view flips around as I pass through x=0, and rotates through y=0.
Ignoring heading for a moment.. I used the plane equation to find a vector
perpendicular to the up vector.
DaveC
"Gene" <eugene.ressler@xxxxxxxxxxxxxxx> wrote in
news:1121210612.832202.271350@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
> Thanks for asking! This makes a great teaching example I had never
> considered before.
>
> The other replies saying forget the spherical coordinates are dead on.
>
>
> A good camera scheme has a minimal set of "just right" independent
> variables. In this case, consider storing only a camera origin
> (xo,yo,zo) and a view direction. You call this the heading, but it
> should be a 3d vector to allow the virtual viewer to move her head up
> and down and turn left/right.
>
> The difference between this problem and the usual is how you update
> these quantities.
>
> Assume the world origin at the center of the sphere. Initialize in
> some logical way, for example
> Camera orgin = (0,R,0), view = [0,0,-1]
> where R is "big enough" to put the camera outside the sphere.
>
> In the normal course of events, up is outward from the sphere center
> up = (xo,yo,zo) - (0,0,0) = [xo,yo,zo]
> This is invariant unless your virtual viewer lies down, stands on her
> head, etc.
>
> You imply "walking" follows a great circle about the center of the
> sphere in the view direction, a good idea. This amounts to a rotation
> of the whole camera about the world origin on an axis perpendicular to
> both the view direction and "up." Use a cross-product to find this
> axis,
>
> axis = up X view
>
> The angle of the rotation is a function of walking speed, radius from
> the sphere center, and dt = elapsed time (since last update)
>
> theta = dt * speed / r where r = sqrt(xo^2 + yo^2 + zo^2) // in
> radians
>
> Any good graphics text (or the OpenGL docs) will tell you how to build
> a matrix or a quaternion R(axis,theta) for rotation by theta about
> axis. Using this, update the camera origin AND the view direction.
> They're both walking at the same time!
>
> (xo,yo,zo) <- R(axis,theta) . (xo,yo,zo) // this implicitly updates
> the "up" direction as well
> view <- R(axis,theta) . view
>
> You will also need to update the view direction as the camera/viewer
> turns left or right. This is just a rotation of the camera about the
> current "up" direction,
>
> theta = turn_rate * dt; // positive turn_rate is left turn;
> negative right; units are radians/time unit
> view <- R(up,theta) . view // changing view implicitly changes walking
> direction too
>
> In practice after rotation you will want to re-normalize the view
> direction to (say) unit length and (xo,yo,zo) to its initial radius r
> from the origin to prevent numerical inaccuracies from building up. If
> your interface should currently have the view direction tangent to the
> sphere, looking off toward the horizon, you can defeat numerical drift
> with
>
> view <- unitvec( (up X view) X up )
>
> To simulate the viewer pivoting head up-down,
>
> theta = up_down_rate * dt // up_down_rate is user-controlled
> axis = up X view
> [view_x, view_y, view_z] <- R(axis,theta) [view_x, view_y, view_z]
>
> Finally, to set up the view, use gluLookAt to construct a view matrix
> as usual:
>
> gluLookAt(xo,yo,zo, // "eye point"
> xo+view_x, yo+view_y, zo+view_z, // "look at" point
> xo,yo,zo); // up vector
>
> This is untested and I apologize for errors in advance, but it ought to
> be very close.
>
> Cheers!
>
.
- Follow-Ups:
- Re: globe trotting?
- From: Gene
- Re: globe trotting?
- From: DaveC
- Re: globe trotting?
- References:
- globe trotting?
- From: DaveC
- Re: globe trotting?
- From: Gene
- globe trotting?
- Prev by Date: Bezier Bounding Box
- Next by Date: Re: Query on distance between 2D line segments
- Previous by thread: Re: globe trotting?
- Next by thread: Re: globe trotting?
- Index(es):
Relevant Pages
|
