I'm considering changing my games terrain engine to render on a spherical planet instead of the current flat surface.

I know how to do this, basically I have 6 heightmaps in a cube and then take normalised vectors from the centre of the sphere to each point in the heightmap (Multiplied by the desired sea level radius) and then apply the value in the heightmap as an offset along this vector.

The problem with this approach is that the heightmap density is not consistent across the sphere. i.e. the points on the sphere that correspond to a point close to the edge of an originating cube surface will have more heightmap values per unit distance than a point closer to the centre of a cube surface.

This inconsistent heightmap density concerns me for a couple of reasons:
1. Does this cause any visible distortion to the surface of the sphere? i.e. does it look ok?
2. Lets imagine I have a vehicle on the the 'planet'. If I model the physics on the original flat surfaces of the cube then its easy to get the vehicle to travel at a constant speed in some direction, however when this gets converted to the sphere it will appear that a vehicle is travelling faster in a location that corresponds to the centre of a cube surface compared a vehicle closer to the edge of a surface. This si what really concerns me.

It appears that there are plenty of articles and books that explain how to render a planet, but I've yet to see anything that addresses the problem of objects moving on the surface of the planet and the associated speed problems.

On a normal 2d terrain (with displacement) a simple vehicle may only need a position, a 1D direction angle and a speed (The speed and direction could be modelled by a single 2D movement vector). Calculating the next position of the vehicle is simply a matter of evaluating NowPos = OldPos + MovementVector * Time

On a planet type terrain it seems like a vehicle would need its position expressed in terms of longitude and latitude and for movement it'd need some kind of RadiansPerSec value for both longitude and latitude.

Is this the right approach?

How do others tackle the problems associated with movement on a planets surface?

Thanks in advance
Ben

I think it's much easier to have the position and the velocity expressed as three coordinates each. If you advance some step, you'll have to project back to the surface of the planet (or use gravity in a simulation). You can convert to texture coordinates whenever you need to, but trying to do the computations in that space makes things needlessly difficult.

Thanks Alvaro,

I'm not quite sure how having position and velocity expressed in 3d helps. Firstly do I have the position and velocity stored in the originating cube surface space, or do I use the final world space co-ords on the surface of the sphere?

If I go for position and velocity on the sphere then I'd need to continuously adjust the velocity to match the tangent of the spheres surface at the given position, otherwise the vehicle would just drive off into space.

Ok in the short term you could use a velocity vector that isn't corrected for the planets surface and then after applying the veolocuty to the position you could project the vehicle back onto the planets surface, but is you do this long enough then the velocity vector will become more and more purpendicular to the planets surface, and the net affect would be that the vehicle would slow down the further it moves from the originating position (The position at which the velocity vector was first calculated) until you get to the point 90 degrees around the planets surface where the velocity vector is normal to the planets surface and therefore the vehicle would stop altogether.

It sounds like what I'd have to do is this for each frame:
1. VehiclePos = VehiclePos + Velocity
2. Project VehiclePos back onto surface
3. Velocity = Tangent at surface position * Magnitude(Velocity)

Does that make sense?

Thanks
Ben

Of course I am talking about world coordinates.

It is true that just projecting the position onto the surface of the planet is not enough, because the velocity needs to be tangent to the surface. If you simply project the velocity vector onto the new tangent plane, you'll get a slightly smaller velocity vector, but I think this is something like an artifact of Euler integration. You can renormalize the velocity vector at the end of this operation to make sure you don't lose energy.

Thanks again alvaro, I'vegot a much better understanding of what I need to do now, thanks.

Ben

This is very similar to the problem of moving a camera around through an X-Y interface like a mouse or touch. Imagine the entity to be moving in only two dimensions along the spherical surface. Rather than trying to maintain a set of "coordinates on the sphere" like longitude-latitude, you just use the 3D coordinates as usual, but just convert the desired "2D" motion into motion over the sphere's surface. The mathematics are very similar to those demonstrated in http://www.gamedev.n...ees-of-freedom/ (but you don't need the zRotationValue/zQuaternion to get the right result). If you want to use the built-in motion and collision features, you still can; you just have to keep a record of the 2D speed, set the speed in 3D terms and frequently update it based on its new position, also adjusting for altitude if your sphere is irregular, with hills and valleys.

A slightly less complex way to go about it is, of course, to just set your speed vector to your usual straight line in 3D space (you'll still need the math from above), but additionally apply gravity that pulls the entity towards the planet when not on the surface. It will end up moving in a curve, and I think you can control the tightness of the curve by multiplying the gravity by the magnitude of the motion vector as a normalizer.

Anyway, I hope that helps augment what Ben is describing. I think we're about on the same page.

http://mathproofs.blogspot.co.at/2005/07/mapping-cube-to-sphere.html?m=1
i havent read the whole thread, but this did the job for me