FreeOrion

Awesome! Could you post a screenshot with a fully developed planet?

That's really cool! Visible development from space. How would it look on the other environments, particularly inferno against all that glowing lava?

P.S. There's a face in the top of the pic on your post. Easter Egg or coincidence

For some reason having the entire planet as one megacity feels wrong to me, it might just be that I wouldn't want to live on a planet without any countryside.

The Inferno one looks very good, I'd leave the lava it looks nice the way its been built around.

Barren Bump map looks great

And I'd leave the comments on but then, I'm bias

The growth doesn't seem very natural to me... It starts out with a few isolated bright spots, which grow, which is fine, but then lots of smaller new growth spots appear roughly uniformly spread around the globe. This seems unnatural... more like lichen (or bare rock) flatly covering the surface than a growing mesh of interconnected cities and infrastructure. It might look / work better if threads of growth / light spread out between and connecting the larger initial centres. Inspiration from neurons, with their cell body having many axons and dendrites spreading far away towards other neurons might help. Following features of the underlying texture might also help, particularly on terran type worlds with obvious coastlines, but presumably also on infornos with bright or dark spots and borders between them. Inferno cities might start at the centre of dark patches and be enclosed by lighter / glowing regions, for example. Or development might spread around the rims of adjacent craters on barren worlds, avoiding the flatter areas in between until the rest of the world is full, and then filling in the empty areas by expanding from the surrounding developed areas, and not by dropping new starter cities that grow out.


Do those have self-shadowing? I'm not seeing it if they do... If not, could you fake it by assuming the light source is always coming from the same direction? We'd have to orient the asteroids in-game all with the "light" side facing towards the star, which presumably isn't a huge problem.

Re: Self-shadowing, I intend to use this normal mapping shader I got out of a book to do normal mapping, parallax mapping, and self-shadowing all in one shader. It is intended for use on the high-contrast, low-color objects, like asteroids and barren planets. I don't know yet how well the technique works, or how much GPU it will eat up, but if it's not generally useful, we could bake the self-shadowing effect into asteroids and planets like you mention, since the light source will be constant.

There are no shadows baked in the color maps, besides some minimal Ambient Occlusion. Self-Shadowing is the process of an object casting shadows on itself - it's not relevant for us.


Baking shadows in the color map won't work either and I'm not a friend of rotating all roids in a similar way, so that the (predetermined) light side is facing the sun. I assume it will look weird and very regular, which shouldn't be the case.

Those roids are by the way just the really big ones. For the many smaller ones, we need to find another solution. Maybe a sprite based approach.

Regarding the growth pattern: I imagined an advanced species will colonize a planet in a very planed, organized way. They might start with just 3 settlements, but they will add more and more at different locations. That said, it's not hard to try out new patterns. Neurons are a great reference, thanks.
Following the underlying texture is hardly possible, because it will change from planet to planet. Having specific lightmaps for each surface color map is insane. What we can do however is simply mask out oceans and lava.

I wouldn't worry about realism, different races will develop differently making all patterns unrealistic, instead I'd focus on making it look good. A neuron inspired pattern would probably work, and I like the fact it will leave some countryside intact.

Its a pity following the texture is impossible, it would have been cool.

Just to be clear, when I said "bake", I was talking about a preprocess pass at runtime, not before runtime. The distinction is that we can do the calculations for self-shadowing once, and use the results in every frame if the objects orientation never changes relative to the star. That still allows for that the object to be in different orientations, with different self-shadows, in different combats.

Wow, that sounds great. "Baking" is used in a slightly different context by artists, so thanks for clearing this up.

Why do you say self-shadowing is not relevant? The asteroid has a complicated concave surface with lots of places where a star-side prominence would cast a shadow on a flat area further away from the sun. Just using the normal to determine lighting only takes into account the local surface orientation, which makes the object look a lot less interesting and realistic when primarily lit by a signle directed light source.

Would it help if you didn't make so many frames? The light map growth won't be animated as in your example; at any given time, the player will only be shown a single frame for each planet. We don't really need so many farmes as you've shown... three or four per colour map would probably be adequate (plus a blank one for no development).

From my experience, self shadowing is usually hardly noticeable(if absent), even more so in our case(example .avi or .mov). I thought it's not worth it, especially with the idea of baking it into the texture and this alignement issue in mind. However, if it can be done as tzlaine described it and it's easy on hardware resources we should go for it.


It's still 9 (planet types) x 3 (color maps each) individual light map sets. Multiplied by the races, if we are going to vary them between races.

Compare this to just 1 set per race, that gets individualized by masking out certain parts. Also I argue, that players won't look that closely at planets anyway. He wouldn't notice if the lights follow the terrain, especially considering, that the terrain isn't even visible at the dark side.


I've provided 10 steps. The animation is done by blending those. Not really that many, considering the population goes from 0 till 30 or something in some cases. Which brings me to the question, should those lights rather show the population level or maybe the infrastructure?

It's barely noticable in those examples, and if that's more like what we end up seeing, there's probably little need. The earlier examples had brighter blue-coloured lighting from the other side, so the shadows were more obviously missing to me. (Although the missing shadows might be a bit more obvious if the light source was from a different direction or the asteroid rotation axis was oriented up/down in the video...)


That's a good point, although it might be obvious as terrain passes under the terminator and lights appear in random places unrelated to the lit texture. Masking would presumably fix this, though.


Probably both. The texture could be chosen based on the sum of the population and construction meters, or the lesser of the two numbers.

Pd`s Guardian looks very impressive.



The level of detail and the overall quality of the design seem to be light years ahead of the ship designs that MOO 3 offered. However since I don`t know too much about polygons and Ogre I have to ask. Can we see ships with similar quality in FreeOrion`s space battles? And if so, do we already have some sort of an idea of how much computer power is needed to run a big space battle with ships similar to The Guardian?

_________________
What is your favourite alien species and WHY?
Preliminary thoughts about diplomacy
Some unfinished ideas for specials

The funny thing is, 2220 is not a lot of polygons by today's standards. It's about the amount game characters have used 2-3 years ago. Current game characters use 10000 or more.

I'll add the ship to SVN soon and hope we'll be able to do some performance testing.

Regardless it's very nice.

Just ten hundred more models like this one....

_________________
Photo-dump.

Musings