Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

alt text

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.

share|improve this question
This is impossible to answer if you have no idea what your target platform is. – AttackingHobo Dec 17 '10 at 21:10
Well, if it's 500px in size, it's not a pre-4G iPhone / equivalent Android, which is about the only thing I'd expect to have trouble with such a simple render. – user744 Dec 17 '10 at 21:23
Hmm, I think the answer may simply be "Zarkonnen, you have no idea how powerful GPUs are these days". :P – Zarkonnen Dec 17 '10 at 21:38
This doesn't seem like a huge amount of data. – The Communist Duck Dec 17 '10 at 21:41
up vote 10 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
I really do not like that method, because it looks exactly like how it is. A flat texture being moved with no distortion as it turns. – AttackingHobo Dec 17 '10 at 23:06

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) ^^

share|improve this answer
-1 - "standard jpeg compression" doesn't exist for textures, and your third paragraph doesn't really make sense. "Quarter pixel scrolling" is achievable via standard filtering in OpenGL/Direct3D, and AA would be trivial for such a scene. – user744 Dec 19 '10 at 12:09
True. In my defence, when the question stated "ludicrous amount of data per planet" for an animation solution - I thought of data storage, not data throughput. The last paragraph was mostly a remark asking how high the bar was set. I've never seen AA as trivial, even the most rigorous offline render solutions for film doing hundreds of passes in exotic ways have some aliasing as soon as things start moving, especially on low-density pc screens - but most people aren't that picky. – Oskar Duveborn Dec 27 '10 at 23:31

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.