Hello all, I have been working on a program for quite a while involving randomly generating a "planet." This may sound like quite a challenging task, but the initial stuff needed, like generating a wrapped height map, was simple. What I did was generate a 2D array of wrapped Perlin noise, or some sort of variation on it.

Anyway, this is where the simplicity ceases, as the next step I wanted to make involved creating weather and climate. (Keep in mind, I'm attempting to keep this to a 2D map; think Dwarf Fortress.) I decided first to start with temperature: I planned on doing so by combining the altitude of the generated land with the latitude, and create a formula to calculate the temperature based on these two things.

Here's the problem: If I create a map on a two-dimensional plane that wraps around both vertically and horizontally, it is literally near impossible to figure out where the poles go.

My first idea was to delineate the top and bottom of the map as the poles. Problem is, this results in only one pole, as the map wraps and both ends meet.

My second idea was to have a second pole in the middle of the map. The problem with this scenario is that if I were to travel left directly from this pole all the way across the map, I would end up back at the same pole, without meeting the other pole as I should.

Now, I can't think of any way to possibly make this work without completely rethinking how the map generation works. So I delve into another idea: a randomly generated map in the style of a Mercator projection, a map design in which the world is laid out as though it were a cylinder.

But this also seems to be a trap, because if I were to keep generating to a rectangular map, it would be impossible to wrap if the player goes past the top or bottom borders of the map.

This may sound confusing, and if I have time later, I may include some pictures helping to illustrate my point. Until then, please feel free to help me solve the mystery of the Single-Pole Planet.

Thanks,

Selenaut

The traditional parametrization of the sphere using latitude and longitude wraps only left-to-right. All the points at the top edge map to the North pole and the points at the bottom edge map to the South pole.

If you don't want to deal with the degeneracy, you can try to use cube maps instead. They are still flat, but instead of one rectangle now you have 6 squares.

Well, you cannot wrap a square or rectangle around a sphere, so your endeavour is already doomed to fail. One thing I can think of is a toroidal mapping, which is just a rectangle mapped around a torus (the edges of the rectangle wrap naturally) but it's not really a planet any more. Though if the planet is large enough the player might not even realise that if you are only concerned with close-range gameplay.

By the way, if you don't want things to end up looking different around the poles, you can try using 3D Perlin noise.

I didn't really want to get into this idea before I had more of a chance to think about it, but what if (and I'm honestly not sure whether this is what the whole cube concept is) I had the map move rather than the player, and actually rotated the map according to how it would on an actual sphere?

Basically, what I'm saying is, if I'm on the equator and I move east, and IF I somehow managed to map both the north and south poles to the rectangular map, then the North Pole would appear to rotate counterclockwise, and the South Pole clockwise. Right?

...

Right?

...I have a feeling this is going to start a REALLY long debate...

Jeez, I'm an idiot.
Why not just have two squares with each holding one of the poles in its center, and laying one on the bottom of the other (ignoring the obvious deformation)?

So like, the edges of the squares would be the equator, and moving east and west would rotate the tiles on the square...

Though to be perfectly honest, at this point I'm beginning to wonder if it's possible to map this with circles.

I worked a project called Revolude (http://www.sourceforge.net/projects/revolude/) that features wrap-around procedural maps, using the 2D heightfield approach, but I knew from the very beginning that this would inherently prevent any 'spherical' landscapes from being produced. A torus is closer, but more of a cross between a wrap-around square and a sphere, where instead of poles you merely have a smaller diameter of space (unless your inner-diameter is zero, but still funky).

I've never actually tackled this problem from a programming standpoint, but I did conclude that utlizing euler angles to represent coordinates (and radius-field points describing the planet's surface) would just be plain sloppy, as the angle-space is still rectangular. Eg: a pitch of 90 or -90 (where 0 is the equator) both still have 360 degrees that represent the same exact point, and would complicate physics and motion along the surface of the planet equally as much as anything else.

The best I can come up with essentially divides the spherical space into the four corners of a cube, as in top/bottom/front/back/left/right, representing everything as a sort of octal sectorization, including origin and velocity. This translates well if you always rely on a 'gravity' to pull everything toward the center, so that if something is moving linearly, and the pseudo-gravity force is applied, it will naturally 'adjust' the linear motion to follow the surface spherically, like a spline.

I figure the goal to be one where XY represent a point on the planet's surface, within a space that is uniformly distant between each point spatially and numerically (as in they correspond 1:1) and Z to be altitude, or radius. The 2D square heightfield allows this to translate easily to current graphics API directly, but as Bacterius says, you cannot map a square to a sphere.

Look up non-euclidean surfaces and non-euclidean geometry.
http://en.wikipedia....lidean_geometry
(Or:

)

The maths is different in non-euclidean geometry.
For example, go look at the earth's atlas. When you said that wrapping around from the south pole gets you to the north pole, that's wrong. The wraparound will keep you in the north pole except it will displace you 180 degrees to either side. For example if I am going up along the 20 degree longitude ill wraparound to the 180+20 = 200 degree longitude, then ill keep going forward and reach the south pole then wrap around back to 20 degree longitude.
Another thing is that the distance between the two ends keeps on changing depending on the latitude. If you are at the equator, and if you go east along the equator and come back to the same point you will travel 2*Pi*earth's radius distance. As you go up this distance(to keep going east until you reach the same point) keeps decreasing and at the poles, its 0.
So when you said you want to go east from the poles, you will keep standing at the same point because the pole's 'radius' is 0. (Because non-euclidean east is not the same as euclidean east)
What you actually meant to say was "I go to the north pole, turn 90 degrees to one side, then start walking" in which case, you will just switch longitudes.
So if you went to the pole along 20 degree longitude and turned 90 degrees and started walking, you would end up moving down along (20+90+180) = 290 degrees longitude. Moving along that longitude you eventually find the south pole as expected.

If you don't understand anything I am saying, get a globe of earth and an atlas of earth(which is essential a 2D representation of the earth - what you want to achieve) and move your finger around the globe and plot the path your finger takes on the atlas. Try to do the things you talked about(moving east from the pole etc.) and see how it plots on the atlas.

Jeez, I'm an idiot.
Why not just have two squares with each holding one of the poles in its center, and laying one on the bottom of the other (ignoring the obvious deformation)?

So like, the edges of the squares would be the equator, and moving east and west would rotate the tiles on the square...

Though to be perfectly honest, at this point I'm beginning to wonder if it's possible to map this with circles.

Yes, using two squares is a very good way to map the sphere as it removes the coordinates singularity which is present with polar representation. You map each half of the sphere with a Stereographic projection from [-1,1]^2. Then you stitch your two mappings on the boundary of [-1,1]^2 (this is a fairly trivial step).
You can do the same with two circles (with polar mapping), but this way you'll loose the absence of coordinates singularity. So in my opinion, using two circles has no advantages.

Jeez, I'm an idiot.
Why not just have two squares with each holding one of the poles in its center, and laying one on the bottom of the other (ignoring the obvious deformation)?

So like, the edges of the squares would be the equator, and moving east and west would rotate the tiles on the square...

Though to be perfectly honest, at this point I'm beginning to wonder if it's possible to map this with circles.

You can try that but it won't be a very accurate simulation of a planet.
It all depends on how accurate you want to be. If you are making a game it's fine, but it's not good for making a simulation.
To see an example of the possible inaccuracies, take a look at this picture(taken from wikipedia):

If you were to try to represent that triangle on a flat surface, you will see that the angles of the triangle will be different than the ones shown(more specifically, the angles will sum up to 180 degrees, they should not).