planets v0.2

Development of artwork, requests, suggestions, samples, or if you have artwork to offer. Primarily for the artists.
Message
Author
noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#61 Post by noelte »

To state the facts. We currently have 12 Planets each with 3 variations which leads to 36 frameset. Each frameset is build of 256 frames.

128x128 framesets - leads to about 800MB memory load
64x64 framessets- leads to about 200MB memory load

In game, the greatest planets are 128x128 so if we have to scale the framesets, we do a downscale which looks alright. When using 64x64 the memory load would be imo acceptable. But at least the barren plt rotations looks rather bad (because they use a stuctured surface)

Caching the compressed images and do a uncompress when opening sidepanel takes to long. one open question is what change in mem/uncompress time would occure when using a single png (frames side by side) instead of 256 single files by frameset.

Maybe we use 64x64 for every plt except those how doesn't look right at that res.

Daveybaby
Small Juggernaut
Posts: 724
Joined: Mon Sep 01, 2003 11:07 am
Location: Hastings, UK

#62 Post by Daveybaby »

At the end of the day i'm coming at this from a programmers point of view because thats what i'm good at - doesnt necessarily mean its the best approach (the prerenders are always going to look much nicer) but its what i'm going to use for the cow project.

Well, i wrote some stuff down (mainly to get it straight in my own head) which covers the basics (planet/cloud rotation, day/night cycle and texture merging) so i will post it here in case anyone wants to have a play

I've done some quick images in Paint shop pro (using the arithmetic tool - yes, this stuff really is that basic) which are fairly representative of what the output should look like.

Havent done the spherical conversion yet - trying to come up with an ultra-efficient algorithm that doesnt look too shoddy.




Planet rendering

For each planet we require a number of textures:

(1) Daytime surface map (24 bpp)
Image

(2) Nighttime surface map (lightmap) (24 bpp)
Image

(3) Cloud colour map (24 bpp)
(4) Cloud transparency map (8 bpp) range from 0.0 (totally transparent) to 1.0 (opaque)
Image
I havent got a good transparency map for clouds handy, so for the moment i have just used a greyscale for both, and will bodge the merge function in PSP.

(5) Day Shadow map (8 bpp) range from 0.0 (full night) to 1.0 (full day)
Image

(6) Night Shadow map (8 bpp) range from 1.0 (full night) to 0.0 (full day)
Image

Note that the night shadow map is *almost* a direct inversion of the day shadow map
However, things look much more realistic in general if the dayside is allowed to fade out completely before
the nightlights begin to fade in. Thus there is a 'dead-zone' where neither dayside or nightside are shown.

Also note that there should probably be some fade-off towards the top and bottom of the day shadow map, but this is a very quick bodge at the moment.

TEXTURE ROTATIONS

All textures must be the same size

dx = texture width (in pixels)
dy = texture height (in pixels)

There are 3 different degrees of rotation in the x axis for the planet

r = rotation of surface (applied to daytime and and nighttime surface maps)
rc = rotation of clouds relative to surface (applied to cloud colour and transparency maps)
rs = rotation of shadow map relative to surface

Now, viewing the sphere side-on we only need to display exactly half of the textures at any time.
Thus we start to take the surface texture pixels from x = r to (r+dx/2) for each line from y = 0 to dy
Note that wrap around occurs, thus if x > dx then x -= dx

So we have 3 x values
x = pixel from surface
xc = pixel from clouds
xs = pixel from shadow

Code: Select all

	for (y=0; y<dy; y++) {
		for (x_count=0; x_count<dx/2; x+count++) {

			x = r + x_count;
			if (x >= dx) x-= dx;

			xc = x + rc;
			if (xc >= dx) xc -= dx;

			xs = x + rs;
			if (xs >= dx) xs -= dx;

			... merge pixels
		}
	}
MERGING PIXELS

pd = daytime surface pixel value at (x, y)
pn = nighttime surface pixel value at (x, y)
pc = cloud colour pixel value at (xc, y)
t = cloud transparency value at (xc, y)
sd = day shadow value at (xs, y)
sn = night shadow value at (xs, y)

To get final pixel value p we:

(1) Merge daytime surface with clouds

pdc = (pd * (1.0 - t)) + (pc * t);

Image

(2) Determine visibility of dayside pixel

vd = pdc * sd

Image

(3) Determine visibility of nightside pixel

vn = pn * sn

Image

(4) Merge day and night pixels

p = vd + vn

Image

Note that clouds are not used for the nightside calculations. This is because all they would do is hide the

nightlights, which, while being realistic, is not useful because the nightlights are used to indicate the level of

development of the planet.


Note that if r, rc and rs are allowed to be fractional, rather than limited to intgers, then the pixel values
need to be interpolated.

i.e.

ri = integer part of r
rf = fractional part of r

p = ((1.0 - rf) * p(ri,y)) + (rf * p(ri+1,y))
The COW Project : You have a spy in your midst.

noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#63 Post by noelte »

Thx Daveybaby for the detailed sample. But one thing which concerns me is that you calculate the planet on the fly. I hope there is a solution which use opengl, because all those stuff (calculation) should be handled by graphic hardware.

As i thought about mapping a texture at a sphere i had something in mind like:

1 - map a planet image at the sphere (and do the rotation)
2 - draw a shadow texture above the rotation to get night and day zone

(if i want clouds moving different (speed) i would add a second sphere)

to get nightlights i would replace the shadow map with a frameset.

Daveybaby
Small Juggernaut
Posts: 724
Joined: Mon Sep 01, 2003 11:07 am
Location: Hastings, UK

#64 Post by Daveybaby »

Agreed. If you hand everything over to OpenGL+Hardware it will be pretty straightforward, but youre relying on the hardware being there to do the job for you (admittedly thats not really a problem these days).

I'm interested in whats possible from a purely software approach, so i'm just playing around to see can be done, really. I think its pretty feasible to do all of the day/night lighting and cloud layer in 2-d before warping into a sphere in realtime, allowing you to do a pure software solution. It probably wont look as good as either a prerendered animation or realtime hardware rendered OpenGL, but its there as an option if needed.
The COW Project : You have a spy in your midst.

leiavoia
Space Kraken
Posts: 167
Joined: Sun Jul 20, 2003 6:22 pm

#65 Post by leiavoia »

for an opengl approach, i would do a texture mapped sphere of the planet, then a slightly larger encasing sphere mapped with the atmosphere, then a textured quad "overlay" to simulate the night side without having to deal with lighting. It's cheap, but allows for the planet and atmosphere to rotate independently.

drek
Designer Emeritus
Posts: 935
Joined: Thu Jun 26, 2003 8:07 am

#66 Post by drek »

I'd map the textures to the same sphere.

Textures can be 'rotated' without the need for expensive geometry transformations.

leiavoia
Space Kraken
Posts: 167
Joined: Sun Jul 20, 2003 6:22 pm

#67 Post by leiavoia »

good point, but you'd have to multi-texture it. That may be a problem (?). never done that.

drek
Designer Emeritus
Posts: 935
Joined: Thu Jun 26, 2003 8:07 am

#68 Post by drek »

It should work fine on any modern card.

Impaler
Creative Contributor
Posts: 1060
Joined: Sun Jun 29, 2003 12:40 am
Location: Tucson, Arizona USA

#69 Post by Impaler »

I was just thinking about how Rings will be aplied to planets.

It would seem to me that the best strategy is to have 2 seperate Half Rings. Once layed down UNDER the planet and the other layed down OVER the planet to create a complete and enclosing ring. They might also be animated but if so the animation of the top and bottom ring portions must be well syncronized.

Initialy we could just make a limited set of rings (Saturnish rings, thin Unranus rings, rings with spokes, semi-transparent "frosty" rings ect ect) and have them all large enough to fit the largest planets. Then later with time permiting we could make Shrunken versions that are more specifical for each planet size. In any event I would expect that Rings ocoure most frequently on Gas Giant planets and very infrequently on terestrial size planets.
Fear is the Mind Killer - Frank Herbert -Dune

Elethiomel
Krill Swarm
Posts: 13
Joined: Fri Apr 30, 2004 11:18 am

#70 Post by Elethiomel »

Impaler wrote:I was just thinking about how Rings will be aplied to planets.

It would seem to me that the best strategy is to have 2 seperate Half Rings. Once layed down UNDER the planet and the other layed down OVER the planet to create a complete and enclosing ring. They might also be animated but if so the animation of the top and bottom ring portions must be well syncronized.

Initialy we could just make a limited set of rings (Saturnish rings, thin Unranus rings, rings with spokes, semi-transparent "frosty" rings ect ect) and have them all large enough to fit the largest planets. Then later with time permiting we could make Shrunken versions that are more specifical for each planet size. In any event I would expect that Rings ocoure most frequently on Gas Giant planets and very infrequently on terestrial size planets.
If it's to be done real-time with OpenGL, this is no problem. You just add a plane with a "ring" texture on it (transparent otherwise, of course) to any planet you want to have a ring, and rotate it.

Yoghurt
Programmer
Posts: 376
Joined: Sat Jun 28, 2003 8:17 pm
Location: Heidelberg, Germany

#71 Post by Yoghurt »

To avoid duplicate work: is someone already doing this (OpenGL'ed Planets)? I ask because the next thing on my list is creating a planet-renderer (A texture-creator combined with the OpenGL-stuff you already mentioned). However, it will take 2-3 weeks before I'm finished with this Python-stuff (finally) and can start with it.
Last edited by Yoghurt on Wed May 19, 2004 4:47 pm, edited 1 time in total.

noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#72 Post by noelte »

Yoghurt wrote:To avoid duplicate work: is someone already doing this (OpenGL'ed Planets)? I ask because the next thing on my list is creating a planet-renderer (A texture-creator combined with the OpenGL-stuff you already mentioned). However, it will take 2-3 weeks before I'm finished with this Python-stuff (at last) and can start with it.
hmm, depends on your experience with opengl. I'm on that topic but my experience is very limited. But at near future i would only try to get an impression if opengl sphere have the potential to reach the quality of prerendered framesets. Before i invest much more work on this, i will complete/push my work on sidepanel and planetview. But i hope this won't take long to be done.

vishnou00
Space Kraken
Posts: 157
Joined: Tue May 25, 2004 3:15 am

#73 Post by vishnou00 »

Daveybaby wrote:However, things look much more realistic in general if the dayside is allowed to fade out completely before
the nightlights begin to fade in. Thus there is a 'dead-zone' where neither dayside or nightside are shown.
Isn't it the other way around? I always thought street light lit before complete darkness.
I know those are placeholder surface map to illustrate, but I would have the nightmap more yellowish, imho.

Hangman
Space Krill
Posts: 6
Joined: Wed Jun 23, 2004 4:38 am
Location: finland

#74 Post by Hangman »

vewy yummy looking planets you got there :-p~~
i trust there will be a pleathora of more worlds on top of these eyecandies in the future? a variety of gas giants and more of the different ice world types and such?

how about a terran planet with an ice age going on on it?
and planets covered with xenofungus type of thing, like in the smac starting screen when you chose variables for your random map?
jesus saves, passes to moses, he shoots... score!

Post Reply