I thought this'd be easy, but I've been crackin' my brain on it for a couple of hours now :D I have a sphere, a position on that sphere defined by a longitude and latitude, a 2D angular direction value (relative to the position, orthogonal to the sphere's surface) and velocity along that direction. What I need to do is arrive at a new set of longitude/latitude values based on velocity and direction. Eg, when I press forward, I need to move forward along the sphere regardless of the actual longitude/latitude the position is currently at. To elaborate on the situation, I'm using spherical coordinates to store the position only because I can't really think of a better method - all my rendering and collision detection is done via Cartesian coordinates - if this is not the best way to do this, please let me know :P Cheers

A crude but workable way would be to forget the spherical coordinates. Just move along the forward vector, and after every step, project the position back to the sphere's surface. Also recalculate the forward vector to be perpendicular again.

Addition: If you need the latitude and longitude for something else, just calculate them from the cartesian position. I wouldn't use them for the actual simulation. Not only are they cumbersome to use, but nasty things happen near the poles.

Yeah, that's about the only way I could think of, but it lacks precision to a certain degree depending on the radius of the sphere (eg you always end up moving slower than the numeric velocity would imply due to overshoot and projection). Then again, realistically, I'm thinking of applying this to a human moving on a planet with a diameter of 30 odd km at walking speed, so that should hardly matter...

Perhaps another solution would be to forfeit simplified collision detection and go fully surface-based - not that that would be an overly more straightforward solution :D

In any case, cheers for the reply, juuso!

PS - I'm pretty sure it's be possible to do this trigonometrically as well, so if anyone can shed some light on that, it'd be awesome :)

You can store both your velocities and your positions in axis-angle format. Such an axis-angle representation, IIRC, is called a twist.

Whenever you want to turn, rotate the axis part of your velocity twist. Whenever you want to speed up or slow down, increase or decrease the angle part of your velocity twist.

You can also think of this as having to do with the exponent and logarithm of a matrix (and the relationship between a Lie algebra [which, I think, is what you have] and a Lie group [which, I think, is what you want]) -- but I need to think about that a little before I reply with that.

I don't think the imprecision would be that bad. Basically it would just be numerical integration. I'd guess that keyboard input lag would overwhelm the differences.

The matrix exponent logarithm Lie group algebra solution sounds.. more hardcore.

Quote:Original post by juuso
The matrix exponent logarithm Lie group algebra solution sounds.. more hardcore.

Pass xD

Emergent - sounds a bit complicated - I ended up using 1 rotate-around-axis call, 2 cross products and 2 vector normalizations for the entire thing (plus projected height calculation as the sphere isn't really a flat boring ball).


In any case - I think I got it working quite splendidly - thus far! :)

Thanks for the feedback, folks.

Quote:Original post by juuso
The matrix exponent logarithm Lie group algebra solution sounds.. more hardcore.

See, I was hoping it might actually simplify things! It'd do that by reducing everything to just a matrix operation...

If you've solved the problem though -- awesome. I guess your work is done! But I'm still kind of curious about this connection, so let me reason it through here, now that I have time.

(Keep in mind that I'm not positive that all this is correct, but it has the right flavor.)

You're a dude on the surface of a sphere. You have an orientation, specified by three vectors:

L -- this points towards whatever direction is your left
F -- this points forward out of your nose
U -- this points up (out from the center of the sphere)

but you're moving, so these vectors have nonzero derivatives with respect to time. What are they?

Well, if you're moving in a straight line (no turning), then your L vector is going to be constant, I think. If you're turning left, then it's going to be moving in the -F direction. If you're turning right, it's going to be moving in the F direction. Let's call your steering control "s," and say that it's positive when you're turning right and negative when you're turning left.

Your F vector is always going to be changing in the -U direction (assuming you're moving forward). Basically, it'll always be going down, in order to chase the horizon. Likewise, your U vector will always be moving forward. Let's say that both of these things happen with rate v.

Your F vector will also move in the L direction when you're turning left, and the negative L direction when turning right. So it moves in the direction of -s L .


Packaging these observations up in a matrix form, we get

  d   [ :   :   : ]    [ :   :   : ] [ 0  -s   0 ] ---- [ L   F   U ] =  [ L   F   U ] <br>  dt  [ :   :   : ]    [ :   :   : ] [ 0  -v   0 ]<br></pre><br><br>Now let's call the matrix with L,F,U as columns "G" and the other matrix (with s and v in it) T (for "transformation").  Then we have,<br><br>(d/dt) G = G T<br><br>or equivalently,<br><br>(d/dt) G' = T' G'<br><br>(where I use the " ' " symbol to mean transpose), so the solution of this differential equation is given by,<br><br> G'(t) = expm(T' t) G'(0)<br><br>where expm is the matrix exponential and G'(0) is the orientation at time zero.  Or,<br><br>G(t) =  G(0) expm(T t) .<br><br>So, there might be mistakes in here, but that's the rough idea!

Emergent, thanks for the explanation, I understand what you mean now :). I have to admit it's an interesting way to solve the problem.

I still maintain my point that for a simple game, the cartesian coordinate thing should work well enough. In both techniques, turning without walking give correct results. And let's consider a guy moving at walking speed on a 30km planet with a 60Hz physics loop. Even if he is fit and eager, he moves about 5cm each physics step. The naive integrator then misunderestimates the ground curvature for about 0.000003 degrees. Not too shabby.

Quote:Original post by juuso
The naive integrator then misunderestimates the ground curvature for about 0.000003 degrees. Not too shabby.

A good point that is! I guess that, practically, your solution is really just as good -- and computationally cheaper. Mine, I suppose, is of interest mainly either for (1) very small spheres, or (2) academic papers.

I'm afraid point #2 is one of the dangers of academic life. :-\ The other day, I had the following exchange with a supermarket checker:

* Emergent and friend from grad school are being slow about packing filled grocery bags into a shopping cart *
Checker: Heh! How many engineers does it take to pack a shopping cart?
Friend: You see, that's the problem! We're engineers! You shouldn't ask us to do anything practical!
Checker: C'mon... what's thought without action?
Emergent: A PhD!

(Mind you, I'm a PhD student myself!)

:-P