Absolutely gorgeous. The last picture reminds me of the movie poster for "The Quiet Earth".



Always thought that was a cool poster.

Love how you can see the space station even from the ground. Very cool.

Quote:Love how you can see the space station even from the ground. Very cool.

It's when you're standing looking at it and it starts getting bigger... and bigger... and bigger... and SQUASH! [lol]

Anyway, I wish to make some constructive critiscm if thats allowed [smile]

The second screenshot looks a bit "plasticy" to me - fake almost. Given I've been studying the various lighting models recently, I'd take a guess that it's a regular blinn-phong variant? One of the anisotropic/metallic models might look better imo.

Or, if you can't do that, try and tweak the specular highlights so that they're much sharper (and the other areas are less shiny). The parts in the screenshot(s) where the metal appears matt/dull looks more realistic.

hth
Jack

Very nice :)
But why is it so close to earth? 300 KM is a very low orbit..

Thats pretty damn cool, the sense of scale is amazing! So what's this engine for anyways? I can't seem to remember.

i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i hate you i'm only kidding.

I wish I could be awesome at programmign too, so I could make things that make people drop their jaws in awe.

Quote:The second screenshot looks a bit "plasticy" to me - fake almost. Given I've been studying the various lighting models recently, I'd take a guess that it's a regular blinn-phong variant? One of the anisotropic/metallic models might look better imo.

Yeah, i might try that. I'm currently using the phong model, with a bit of tweaking. It looks like this:

(a + N.L.b).O.D + (R.V)^s.O.G + E.D

With
N = Surface normal
L = Light direction
R = Reflected light direction about N
V = Vertex to camera direction
a = small ambient value
b = light strength
D = Diffuse color
s = specular exponent
G = Gloss factor
O = Ambient occlusion factor
E = Self-illumination factor

Quote:But why is it so close to earth? 300 KM is a very low orbit..

Just an arbitrary altitude, no special reason.. it's just a test after all. The ISS is at 400 Km by the way, so it didn't seem that unrealistic to me.

Quote:So what's this engine for anyways? I can't seem to remember.

-> Link at top of the page :)

I asume that you are using far-positions?
OGRE forum topic. Never used them but they seem to be what you need.

I have one question.
You said you will have billion of planets, so that means you will store a seed for each plane or something.
Now, the client rendering them is one thing, because it needs to render one planet at a time, but you will also need the server to semi render each planet a player is closed by, in order to calculate the colision detection and line of sight, etc.
With 1K players, you might need the server to generate 100 planets at one time. That will be quite a lot of memory and CPU time, no?

BBB: no, i'm using 64-bits floats for the positions, which are converted as 32-bits floats in camera space for each object and each frame (avoiding loss of precision when sending data to the GPU). That's only valid within one solar system (approximately 100 A.U.) though. For galaxy positions, i'm using 64 bits integers.

Raduprv: no, because while the client needs to tesselate the whole planet to be able to render it, the server (for collisions for example) only has to check if the planet is inside a collision radius, and if it is, only generate the planet inside that "sphere". A cache will probably be used to speed up the tests. Finally, the server will not have to handle the collisions tests at the same rate than the client does.

But is your planet generation algorithm so advanced that you can arbitrary generate only a small surface inside any given sphere?
For eample, if you are very close to the surface, it will have to generate full mountains and stuff, for collision detection purposes.
As for caching them, it might be impractical given the almost inifinite size of the universe.

I could be wrong, but I think that he means that the server will only worry that a player doesn't fly thru the center of the planet, but the server will not check if you fly thru a mountain on the surface.

Hmm, that will kind of suck in a dog fight on the surface of a planet :)

Quote:But is your planet generation algorithm so advanced that you can arbitrary generate only a small surface inside any given sphere?

Not exactly. There's a global heightmap at the planetary scale, so getting the heights in the collision sphere is pretty easy. Once you go down the Km resolution, the algorithm uses noise and diamond square to add details.. it could become tricky, but i'm reasonnably sure it can be done.

Quote:As for caching them, it might be impractical given the almost inifinite size of the universe.

Why does the size of the universe have anything to do with it ? It's not like i'm going to generate collision data for planets where no player is, or keep the data in the cache for a long time.. this is just to avoid recalculating the collision data for each player on a planet and each frame.

Well, if you have 100 players that are each near the surface of a planet (1-1K meters away) the server will have to generate and cache a lot of data.
Will the cache be memory only, or on the HDD as well?

Quote:Yeah, i might try that. I'm currently using the phong model, with a bit of tweaking.

Wouldn't really worry about the lighting model. The appearance of metal is defined mostly by texturing and environment reflections, further enhanced by fresnel effect. I'd say it's mainly the texturing of station that needs some serious work on, especially since it also gives bad impression of scale...