Large, slowly rotating planet graphics for game

 

For a computer game I'm developing, 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 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.

    Fracplanet can save out "spheremap" texture maps (and bump maps); see the images towards the bottom of the gallery. These are intended to be subsequently read into an app and mapped onto relatively low resolution sphere geometry to achieve the very effect I think you're looking for. This approach will use less memory than the pre-rendered animation approach or using the original full resolution polygon model.

    Yes this is basically your second bullet point but I wouldn't be so quick to rule that approach out and I think you'll find you can get away with a lower resolution sphere than you anticipate; the eye notices the fine detail in the texture far more than it notices the low resolution of the geometry it's draped over. Modern tessellation hardware means you can probably get the GPU to easily generate and render a ridiculous number of polygons for a sphere for you anyway.

    Alternative idea: render a single square quad polygon sufficiently large to cover the planet. For each pixel within that, execute a pixel-shader which computes the screen-ray-sphere intersection point (if any). Look up the colour from the planet texture (taking time and planet rotation into account). Avoids the need for a lot of polygons and gets you an exact sphere.

    If you want graphics acceleration, then polygons are cheap -- a fairly large number of polygons is not a problem.

    I recommend a cube map texture, and a corresponding cube-like triangle grid: start with a vertex grid in the shape of (the surface of) a cube about the origin, and normalize each 3D coordinate to unit radius. This will make computing your texture coordinates easy.

    Keep in mind that you need to choose the right projection for your texture: in the above case, you will want a tangent projection for each cube face, to match your grid.

    The archaic way of doing this would be to pre-create an image of a sphere but instead of storing the colors of the surface texture in each pixel you store the texture UV as a lookup table. Now you can render the sphere by drawing the pre-rendered image but look up the corresponding texel in a planet surface texture from the UV found in the image. In order to make the planet rotate you can add an offset to the uv coordinate found in the lookup table image. Make sure you use a modulus addition so the texture wraps nicely. If you want shading on the planet you can add that as a separate pass on top of the texture.

    This approach would most likely be much faster than a textured polygon version on hardware without built in graphics acceleration and you would also be able to render it with as many polygons as you want since the rendering is a pre-process.

    链接地址: http://www.djcxy.com/p/60410.html

    上一篇: 二维平台：为什么物理依赖于帧率？

    下一篇: 游戏中大型，缓慢旋转的行星图形