Drawing very large slowly rotating planets

Question

I'd like to draw very large (~500 px) graphics of planets slowly rotating. These graphics are meant to impress. What's the best way of doing this? I don't have experience with any particular 3D engine, and I'm not even sure what platform this game would run on, so:

• I could pre-render each frame, but at 500px and a rotation period of 10 seconds, that's a ludicrous amount of data per planet.
• I could use a 3D engine and map the planet's texture onto a mesh approaching a sphere, but at 500px, I fear the polygon count would have to be huge to make it look good.
• I could write a kind of custom 3D engine that does nothing but efficiently render a textured sphere, by converting the x/y coordinate of each view pixel into the coordinate space of the sphere's texture - but this is involved, and couldn't benefit from graphics acceleration.
• Something else I haven't thought of?

Here's an example animated GIF of what I mean. (At 100x100 px and 60 frames, it's already pretty huge, sorry.) Imagine this much, much bigger, rotating much slower, and animated more smoothly:

But if this were 500x500 px and 10 x 25 = 250 frames, we'd be talking about hundreds of MB of data, so this straightforward approach doesn't work.

Answer 1

The number of polygons to render a "good looking" 500x500px sphere with a single draw call is trivial for GPUs to handle on most platforms, especially if there isn't much else in the scene. There's also some notes about texturing spheres to avoid texel distortion; make sure to use a cube map.

Answer 2

Since you are looking at the sphere with a constant camera, you can do high quality rendering extremely fast with a simple precalculated lookup-table.

As the precalculate step, with any method you like (usually with polygons or raytracing) you render a texture mapped sphere to an offsceen buffer, but instead of calculating the colors based on the texture, you only store the texture u/v-coordinates.

Then when rendering the actual planet you render a simple square and for each pixel you fetch the actual u/v-coordinates from the lookup-table and the pixel colors from the planet texture using those u/v-coordinates. To rotate the sphere you just offset the u-coordinate with the rotation angle.

This technique was very popular in the demoscene for example with texture mapped tunnel effects, but unfortunately I couldn't find any good tutorials about it.

Answer 3

If you are doing this in a 2D setting, see this previous question...

3D Illusion of a 2D Planet Texture

The same concept would work fine with a large image and by dynamically moving the terrain texture on a layer beneath the "hole" in space.

Read the above link to know what I mean by this.

Answer 4

If you compressed the resulting animation with a modern video codec, it wouldn't be particularly big at all and nowhere near "several hundred MB of data" nor ludicrous...

But as already stated, it all depends on what your target platform is and as everyone else said; just rendering a smooth 3D sphere would actually involve an insignificant amount of polygons and very little data storage (the texture being all there is and even at really high resolutions, standard jpeg compression would bring it down to nothing).

It all also depends a bit on how picky you are - if you're after the quarter-pixel-scrolling-look and texture details on par with state-of-the-art demos and not just contemporary games with all their interpolation and aliasing issues even at 8x FSAA - then it could get almost endlessly involved to achieve (and require a bit of artistic trickery as well) ^^

Answer 5

If you have issues with performance doing this the traditional way (texture and normal mapping on a high polygon sphere), which as many have mentioned should not be a problem at that resolution:

"Raytrace" it with a fragment shader. If your camera is fixed all you need is a uniform float input to your fragment shader (for the angle of rotation) and the shader can take care of computing the texture coordinates. The lighting vectors might even be the same each frame as well. As for anti-aliasing you can also get a perfect spherical silhouette with little ingenuity (if pixel is on sphere boundary, compute its coverage)

This has you only sending 4 vertices through the pipeline, and does not require you to allocate a gigantic multisampled framebuffer to fight jaggies.

At the cost of having to come up with several built-to-order algorithms.