Sign in to follow this  

Position and velocity at the surface of a sphere

This topic is 2310 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've recently played [url="http://www.youtube.com/watch?v=Jhhocl7jf3o"]Super Stardust HD[/url] (youtube video) and have been curious about how positions and especially velocities could be represented in such a game. I'm currently in an internship where we develop a software which does simulation on the surface of the earth, and positions are represented using latitude/longitude/altitude at the macro level (when manipulating the globe like in google earth) and cartesian coordinates at the micro level (where it looks more like an RTS game). However, I'm no math guru but I'm quite sure using cartesian coordinates cannot work for a small sphere like that of Super Stardust HD.


Spherical coordinate systems using a latitude/longitude approach seem better than cartesian coordinates but, while they can easily represent positions, I have the feeling they'd break pretty fast when trying to represent velocities. Also, the precision of the longitude value changes radically as the latitude changes, and I get the impression that poles would have to be handled with special cases to prevent divisions by zero or similar problems. I guess a mixed approach could be used where the velocity is in cartesian coordinates and everything is mapped back to spherical coordinates after moving but that doesn't seem very robust.

I have nearly no experience with quaternions, but I've been thinking that they could possibly be used for that purpose. It seems to me that a position and rotation on the surface of a sphere is pretty much analogous to an orientation, and that quaternion slerps could be used to "move" (or "rotate") on the surface of the sphere without the limitations of angles. Could this work?

Are there other representations I didn't consider? Could hybrid approaches work? I'd love to hear input on this.

Once again, I'm no math guru, so please link to explanatory articles if your replies get math-heavy.

Share this post


Link to post
Share on other sites
There are basically two approaches.


1. [b]An Atlas[/b]

A [i]chart[/i] on the sphere is some coordinate system on a part of the sphere. These are [url="http://en.wikipedia.org/wiki/Map_projection"]map projections[/url], and there are lots of them (e.g., [url="http://en.wikipedia.org/wiki/Mercator_projection"]Mercator[/url], polar, [url="stereographic%20projection"]stereographic[/url], etc). All of them require cutting the sphere somewhere. An [i]atlas[/i] is a collection of charts. You'd represent your position in terms of an atlas, by storing (1) an index to a particular chart, and (2) a pair of coordinates in that chart. Here, the complicated part is designing the logic for switching between charts where they overlap (though it's not particularly difficult; it just takes a little code).

2. [b]An Embedding[/b]

Here, you just represent everything in 3d. Positions are always in 3d, and so are velocities. With this approach, velocities must always be tangent to the sphere, and you'll have to do something to make sure that, if numerical errors cause you to move off the sphere, that you get back on it. Of course, for the unit sphere, this is easy; just normalize your position vector.


These two approaches are more general than just applying to spheres. These are the two main approaches for working with [i]any[/i] manifold.

Because the projection operation is so easy on spheres, I personally prefer option 2 in that case. If you search in these forums, you'll find a number of threads discussing moving on a sphere; I've described how to do it in some detail.

Share this post


Link to post
Share on other sites
Thanks for your input, Emergent.

I did not think about using an atlas of projections, though I did read about charts on wikipedia. It looks like a good approach but a bit touchy to handle. When using those, do you represent velocities in the projected space or in "normal" cartesian coordinates? For the "embedding" solution, how well does this work in practice? I would imagine that as the speed of an object gets faster relative to the radius of the sphere, the actual distance moved on the surface of the sphere gets smaller after clamping, though maybe an iterative solution could diminish the problem.

As I said I'm not too familiar with quaternion so maybe my suggestion makes no sense, but would it be possible to use them for position and velocity? Is attempting to represent velocity in non-cartesian coordinates a flawed idea?

Share this post


Link to post
Share on other sites
[quote name='Trillian' timestamp='1310932714' post='4836464']
Thanks for your input, Emergent.

I did not think about using an atlas of projections, though I did read about charts on wikipedia. It looks like a good approach but a bit touchy to handle. When using those, do you represent velocities in the projected space or in "normal" cartesian coordinates? For the "embedding" solution, how well does this work in practice? I would imagine that as the speed of an object gets faster relative to the radius of the sphere, the actual distance moved on the surface of the sphere gets smaller after clamping, though maybe an iterative solution could diminish the problem.

As I said I'm not too familiar with quaternion so maybe my suggestion makes no sense, but would it be possible to use them for position and velocity? Is attempting to represent velocity in non-cartesian coordinates a flawed idea?
[/quote]

Sorry for the very delayed reply; I hadn't seen your post. You've probably figured out a solution by now, but I might as well leave an answer in case it's useful to you or to another reader.

In the atlas approach, you'd represent velocities in your local coordinate charts. Then you'd have to transform them when you switch between charts. The map that takes you from one chart to another is called the [i]overlap map[/i], and the velocities are transformed according to the Jacobian of the overlap map.

For spheres, the embedding solution works well, and I like that it avoids trig functions and other slower operations (at most you end up with an occasional square root). It's with higher-dimensional and more complicated manifolds (like the configuration manifolds for mechanical systems) that you start having difficulties (this is the problem of constraint stabilization in multibody simulation).

First-order approximations with an occasional projection have been good enough for me, but you certainly could do actual rotations if you needed more accuracy. A linear velocity in the tangent space has a corresponding angular velocity about the center of the sphere; it's given by the cross product of that velocity with the displacement of the point from the center of the sphere. You can take that angular velocity (call it "w"), use Rodrigues' rotation formula to compute the rotation matrix exp(w dt), and rotate your point by that; that'd have some extra accuracy. At some point I generated a plot of the error vs. "dt" of the first-order predictor-corrector vs. this exact rotation approach; it's around here somewhere in the forums ([url="http://fooplot.com/index.php?&type0=0&type1=0&type2=0&type3=0&type4=0&y0=sqrt%28%28%281/sqrt%281%20%2B%20%28x*pi%29%5E2%29%29%20-%20%28cos%28x*pi%29%29%29%5E2%20%2B%20%28%28%28x*pi%29/sqrt%281%20%2B%20%28x*pi%29%5E2%29%29%20-%20%28sin%28x*pi%29%29%29%5E2%29%3B&y1=&y2=&y3=&y4=&r0=&r1=&r2=&r3=&r4=&px0=&px1=&px2=&px3=&px4=&py0=&py1=&py2=&py3=&py4=&smin0=0&smin1=0&smin2=0&smin3=0&smin4=0&smax0=2pi&smax1=2pi&smax2=2pi&smax3=2pi&smax4=2pi&thetamin0=0&thetamin1=0&thetamin2=0&thetamin3=0&thetamin4=0&thetamax0=2pi&thetamax1=2pi&thetamax2=2pi&thetamax3=2pi&thetamax4=2pi&ipw=1&ixmin=0&ixmax=1&iymin=0&iymax=2&igx=0.1&igy=0.1&igl=1&igs=0&iax=1&ila=1&xmin=0&xmax=1&ymin=0&ymax=2"]here it is[/url]; see [url="http://www.gamedev.net/topic/584384-binding-a-first-person-camera-to-the-surface-of-a-sphere/"]this thread[/url] for more info).

Share this post


Link to post
Share on other sites

This topic is 2310 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this