Spherical Worlds

Hi,

You are asking quite fundamental question about how a world should be arranged in the game (flat vs. spherical).

You'll notice lots of difficulties with spherical world such as texturing, patching it, having units moving around it etc ...

Still, I like the idea and I would like to create one someday too.

Could you ask something more specific about it ?

Quote:

Original post by Anonymous Poster I think in the original Populous game, the world was not really a sphere, but actually a flat square, where the top wraps to the bottom, and left wraps to right. So topographically it was a torus. Locally it is always flat. And they used some graphical effects to make it look like it had a spherical curvature.

Hahaha, sorry, but are you talking about the... the first populous ? [smile]

Populous beginning was made with a sphere I can assure it. And units were sprites.

The AP is absolutely correct. The world in Populous 3 (i.e. Populous : The Beginning) is indeed a flat square that wraps in both directions, resulting in a toroidal map. When rendering they just "bent" the mesh a bit to make it look curved.

mmmh ??

Ok why not.

Here is some screenshots :

http://images.google.fr/imgres?imgurl=http://popvault.strategyplanet.gamespy.com/img/screenshots/Neutral_AOD_3.jpg&imgrefurl=http://popvault.strategyplanet.gamespy.com/screenshots.php&h=235&w=319&sz=16&hl=fr&start=34&tbnid=27EeloN1c8c2lM:&tbnh=87&tbnw=118&prev=/images%3Fq%3Dpopulous%2B3%26start%3D21%26ndsp%3D21%26svnum%3D10%26hl%3Dfr%26lr%3D%26sa%3DN

For me, that's a sphere, I don't know why it couldn't be. But I'm maybe wrong...

lol what a bug !

Quote:

Original post by Anonymous Poster I think in the original Populous game, the world was not really a sphere, but actually a flat square, where the top wraps to the bottom, and left wraps to right. So topographically it was a torus. Locally it is always flat. And they used some graphical effects to make it look like it had a spherical curvature.

Well even this isn't correct, the way you explain it, the world is a cilinder where both ends are connected with teleporters or something. Just look at a torus, the inside has a smaller radius than the outside thus if it is a torus it would talk less time to run in one direction till you get to the starting point on the inside than it would on the outside but since both sides have equal length it's just a cilinder basicly :).

Sorry for the offtopic but i had to note this since i've been thinking about this subject also :).

Definately a toroidal square rendered to look like a sphere - it wasnt even a good attempt at it (sprites are all the same size regardless of distance for example)

Its been a long time, but I played that when it was new. You could zoom your camera out far enough that the whole globe was visible and spin it around. If that thing mapped as a torus, they were brilliant in hiding the fact. It would have required less brilliance to just make a sphere, I reckon ;)

On the other hand, its pretty clear that the underlying grid is sqaures and those don't map well onto a sphere. And the little world map in the corner doesn't look like it would map onto a sphere without distortion. So who knows.

Anyhow, I've been monkeying around with spheres for quite a while now and I can generate a pretty decent parametric model. I do it on a geodesic sphere and use a Perlin noise function to displace the vertices in a shader. What I havn't tried to do is any sort of fractalism - I just use a fixed density of vertices and a fixed number of octaves and there's the planet. So they come out very toy like - similar to those in Populous 3, in fact. My pseudo scale makes a building on a planet about the same size ratio as a standard dice or a thimble on a basketball. Its fine for me since my overall aesthetic is whimsical.

I still have lots of technical issues to overcome on the rendering side. Like, even with a sphere of around 10k vertices, the hexagonal form of the mesh is apparent. But on the analytical/topological front I'm pretty well all set. I can get from this vertex to that vertex and avoid impassable terrain on the way.

I couldn't find much in the way of useful information either, btw. I just made it all up. I'd be happy to share all my secrets with you if there were any - but there arn't. So I don't have any real advice to offer apart from the suggestions above and to assure you that if a knucklehead like me can figure out a workable system, anybody can :)

Feel free to send me a PM if you want to talk about what I've done. Its a little off-topic for this particular board.

[Edited by - dalep on January 20, 2007 11:20:22 PM]

Quote:

Original post by dalep Feel free to send me a PM if you want to talk about what I've done. Its a little off-topic for this particular board.

Even so dalep; Could you share with us your parametric functions for the surface, I'm really curious!

IMHO the easiest way would be using a subdivided cube with normalised vertices. It's not the most efficient way to create a sphere but it has a lot of advatages:

• all sub-squares are, well, squares [smile], so texture mapping is simple


• since you work with squares only, path-finding is easy as pie - you just have six sectors (e.g. the sides of the cube) and that's all


• due to the simple layout, a map-editor is easy to create since all it has to deal with are well-defined square areas


• a well-defined one-to-one mapping from spherical to square coordinates exists

Just my .02€,
Pat

I've been working on spherical planet rendering for a couple of months now (progress is a bit slow...) but I found one thing which might be useful:

x' = x * sqrt(1 - y*y/2 - z*z/2 + y*y*z*z/3)

(And similarly for other coordinates). This maps from a cube to a sphere but as from what I remember when I looked into it this has significantly better properties because there is less warping - IIRC a square on the cube mapped this way has a worst case edge length ratio of sqrt(3):1 whereas for normalisation it's 3:1. I got this off a link someone posted when this was discussed before so do some digging through the forums if you want more info.

Symphonic - I'd be happy to. But there isn't much to it. You may be disappointed ;)

As I said, I use geodesic sphere models. I orient them so that two of the verts where five (rather than six) edges connect are at the north and south pole - aligned with the Y axis. There are 20 such vertices on a gsphere, btw.

Then I use a perfectly ordinary 3D Perlin Noise function. So you can get your noise in terms of x,y,z. For any given location on the sphere, I can derive a set of coordinates, give it to the function and I get a noise sample back. The noise is set up with an Initial Amplitude of 1 and a periodicity of PlanetaryCircumference. I use six octaves. And so the noise value that comes back will be +/- 1.

Each planet in my galaxy has a integer seed that I use to initialize its Perlin and that seed determines the planet's terrain. Values <0 are below sea level, Values >0 are above sea level. Or you can add an offset to control the amount of water coverage the planet has (the noise will generate samples approximately 50/50 above and below 0)

You can generate a texture off this same Perlin. You just have do calculate a longitude/latitude for each texel. Each row of texels corresponds to a latitude. You calculate the circumference of the sphere at that latitude then iterate over the row, stepping in longitude by (circumferaneAtLatitude/2PI)/texturewidth or whatever it is and then turn the polar coords into a vector. Get the noise sample at that x,y,z and use whatever function to map that to a color. If you look at this texture flat, it will look distorted - all blurred and stretched out near the north and south pole. Sort of like a mercator projection wall map but with longitude varying instead of latitude. But then you map that onto a sphere and it looks fine.

A cube map would actually be more efficient - it can do the same thing but with significantly fewer texels (about 20% less if I recall correctly). The noise isn't all that cheap to generate - a 256x512 takes, I think about 0.1 seconds to produce on my machine. So its not something you can do in a single frame. To generate that, you'd get the coordinates of the texel in 3D space and then normalize it to the planet's radius and there's your xyz for the Perlin.

This is why I don't generate textures. I use a fairly high density gsphere model (around 10k, as I mentioned). I only need one such model because I render it with a shader. I build an array of floats, containing noise samples, that's correlated to the model by array index and shuffle that together with the model in the pipeline where it shows up as a color field on the vertex. I use the value there to displace the vertex a little bit. And that's really all there is to it. 10k vertices is substantially fewer samplings than a texture.

Right now, I'm just useing by vertex coloring in the final render. It doesn't look all that great, though. Need to devise some sort of scheme to stipple the surface somehow.

The same perlin can be used to generate a cloud layer over the planet. For the terrain, I use only one "radius" into the noise. So that leaves infinity-1 more radii for other things. By taking a second set of samples, with an oscillating radius, you can make some nice cloud effects. But I havn't figured out how to do it efficiently enough that it doesn't crush framerate.

I also use the vertex meshes as the basis for my coordinate system on the planetary surface, in support of actual game features. That's outside the scope of this discussion but it imposes a significant limitation on the design: it can't do spheres of arbitrary radius. For a whole host of reasons, the planets need to have their edge-lengths all the same. And since a gsphere can only have an integral number of subdivisions, I can only have certain planet sizes. I use Tiny, small, medium, and large. The planetary location grid for these have 41, 161, 361, and 641 locations respectively. The model used to render each is subdivided a further, um, I think its 3 times, resulting in the 10k vert model for the large-sized planets. The locations are where the user can place buildings. Mobile objects on the surface can move freely. But they still do it in terms of the location grid - that's what I've attached the A* data to. The location of mobiles is tracked in terms of distance from and rotation around the normal of the closest vertex. Like a little polar coordinates within the "hex" defined by each vertex.

I scale the model for each size so that their edge lengths are all the same and that determines each planet's radius relative to the other planets.

In fact, I use the radius of the Tiny planet as my base unit for the entire gameworld.

So, as you see, there's nothing brilliant to it. The whole system is cobbled together with off-the-shelf parts.

[Edited by - dalep on January 21, 2007 10:50:03 AM]

Quote:

Original post by Scorpie Quote: Original post by Anonymous Poster I think in the original Populous game, the world was not really a sphere, but actually a flat square, where the top wraps to the bottom, and left wraps to right. So topographically it was a torus. Locally it is always flat. And they used some graphical effects to make it look like it had a spherical curvature. Well even this isn't correct, the way you explain it, the world is a cilinder where both ends are connected with teleporters or something. Just look at a torus, the inside has a smaller radius than the outside thus if it is a torus it would talk less time to run in one direction till you get to the starting point on the inside than it would on the outside but since both sides have equal length it's just a cilinder basicly :).

This is correct, but note that he said _topologically_ a torus, which I believe is also correct; when comparing things topologically, distances don't matter. (Not that this really matters, I just wanted to be pedantic:)

This site helped me when I was looking at warping a cube into a sphere:

link

Cheers,
Brett