Several years ago I overheard a technique that gives the user the illusion of a rotating planet by using a 2D texture. Given that the user isn't able to change its position or viewport.
What's the name of this technique?
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.Sign up to join this community
OK I think I have the rep now. Contents of previous post with images embedded. Is this the rotating planet effect you're looking for? Its simply a scrolling 2D image viewed through a semi-transparent "hole" in the star field.
I put together a quick little animated gif of what the effect would look like. Clearly it could be animated a lot smoother - I shifted the planet surface by 4 pixels each frame. It's also not set to wrap the image so there's a glitch at the end of the loop.
I did do this all in Photoshop, but the concept should work in a 2D rendering environment that lets you do alpha transparencies, etc. Here are a series of screenshots showing the process...
To animate your planet's surface, just move the underlying planet surface texture. You'll have to get clever about shifting the texture when it reaches the edge to get a seamless and endless rotation.
Hope this helps and is the effect you were looking for!
PS Saw this article about artists with a rather novel way to create planet textures - made me think of this answer :) http://www.behance.net/gallery/Pan-Planets/9557465
im going to guess at what you mean, and just throw an idea out there, but it's certaintly not going to be the 'famous' way to do it.
all in 2D
take 2 textures. one your land mass, the other your clouds. clouds should have a alpha layer that matches so you can 'see thru them'.
make the textures tileable, that is they seamless wrap. there are programs that help you make these or tutorials in photoshop you can follow.
then finally you make a stencil mask that is just a circle, so you are in effect looking thru a round hole at your square textures, thus masking off the corners.
now you animate the texture matrixes of the land and cloud textures to make them move. make them move in different directions and speeds and it will appear to be rotating. it all depends on how seamless you made your textures.
I think this article describes the technique. (It is in Russian, so I post translated link.)
I've implemented it here. http://github.com/meric/renderplanet
Basically you take an image that encodes the orthographic projection (http://mathworld.wolfram.com/OrthographicProjection.html) and wrap your planet and cloud texture around it using a shader. Offset the planet texture according to dt to make it rotate. Use an prepared translucent image for the atmosphere ring and shadow, or generate it by drawing translucent arcs and some experimenting with the shader for the shadow.
Here is the image:
For each pixel within the circle,
Red + Green/255 is normalised X coordinate of planet/cloud texture to lookup and
Blue + Alpha/255 is normalised Y coordinate.
Here is the result:
The planet and cloud textures should be in equirectangular projection.
Your question is unclear as to the restrictions on context you're working in. The vast majority of textures in 3D rendering are 2D. So if you're just showing a 3D sphere with a 2D surface texture mapped around it, this isn't really a problem. If you can't use 3D rendering, then you have to say exactly what you can use.
The basic issue is that you have to render a flat texture over the surface of a sphere, which you get for free with 3D rendering. As the planet rotates, the visible portions of the planet's surface animate in a non linear way (the equatorial parts of the texture move faster than the poles). So I think either you have to distort the image yourself as you map it over the disc, or you do as VirtualVoid suggested, and simply have multiple images which you change between over time.
It would be horrible to implement, but if you are able to render the texture, pixel by pixel, then you could basically do the rasterisation calculations for each line of the sphere separately. Let's assume that your surface map texture is flattened out, so that at the equator there are 512px of image. Let's also assume your visible disc is 256 px wide. Now think of each line of the rendered disc as a sliding window on the surface texture. On the equator, the window is 50% of the texture width, and you simply copy each of the 256px onto the equivalent pixel on the disc. The next line down on the disc will be slightly less than 256 px, but because of the distorted surface map, there are still 256px of input surface map data. So you then sub-sample the input surface map data, and render out the resulting pixel. For easy maths, let's assume that 1/3 of the way between the equator and the pole is 128px wide in the output disc. So each of those 128px is going to be the average of 2 neighbouring pixels. When you get down to the pole, you'd be averaging all 256px into only a few output pixels.
You could also do it the other way, and have the lines in the source texture be of different lengths. So while the line containing the source data has 512px in it, the line 1/3 of the way down has only 256px, and the line at the bottom has only a few pixels. But each line is double the width of the disc at the equivalent y coordinate. That sort of a texture would be absolutely horrible to have to create though. And would probably suffer from horrible aliasing issues.
In both of those cases your animation is simply then incrementing the start pixel x in the input texture, and wrapping around to the start of the input texture line.
The more I write about this now, the more I'm convinced that it's a horrible idea, that you'd only implement if you really had absolutely no other choices. And you'd have to be in a very unusual situation to have no other choices.
I don't believe I've heard of any solutions to this (rather vague) problem as a specific named technique.
Sprites. It sounds like what you're describing is a 2D sprite in a 3D game engine to render cheaply (the Nintendo64 did this all over the place, as did many early 3d engines).
If you wanted to render a planet rotating, you'd just have to display a 2D sprite that was animated based on a sprite sheet that was a pre-rendered planet rotation. Just like, an animated .GIF for instance. The problem is that it would be pre-rendered, so as you said, this only works if the user isn't allowed to manipulate the view angle.