About Gallery SF.net Project Bug tracker Downloads Forums Manual Wiki DevBlog News

Archive for September, 2010

Planets, a reality of the hard working

Thursday, September 2nd, 2010

Earlier I posted about a dream I had.

Today I’m posting about a project I have.

Hopefully, soon I’ll be posting about the game we have.

There’s no discussion about it: my areas of expertise in game development are graphics, and sound. I did a tiny bit of sound earlier, with streaming support. I’ll be back in those realms eventually, to complete streaming support for music which won’t be immediately apparent to users but it’s an important step for the audio system. Anyway… I’ll be back with sound eventually, but right now I’ve been taking some time off sound to revitalize my mind. I did that by thinking about graphics this time :)

Yep… switching from task to task is recreational for me - it lets me come back afterwards with renewed ideas and energy. Is that weird? I don’t know… but that’s me.

So, I’ve been playing with planet shaders. I got them looking nice, as I posted earlier, and lately I’ve been hooking those shaders into the system generator. Sorry folks, but I have some bad news in that front:

It’s done.

You say bad news? Ftw?

Well, it’s bad news because for it to take effect (whenever I commit it, which I haven’t done yet) you’ll have to delete all your generated system files. Bummer. All the systems you thought you knew you know no longer.

Sadly, I don’t know of an alternative. There’s no easy way to add the shaders to existing systems, and there are tons of parameters to play with. Texture files have to be set, technique names, parameter overrides… all that is generated pseudorandomly once, and the result stored in a private folder of your system (close to where savegames are stored).

But hold on, there’s more bad news.

I’ve only done the terrestrial worlds. I’ve been working  hard to get gas giants, and although they look cool at the moment, I’m not entirely happy with either the looks or their performance right now.

So I’ll keep working on them, but I’ll commit the terrestrial planets so everybody can enjoy (and comment - feedback is the best development tool, second only to contributors). I may go ahead and tackle rocky planets and asteroids before I get the giants right… the technique I chose for the gas giants bring my GF9800GT to its knees. Knowing a lot of people play with Intel GMA, which is orders of magnitude slower, we certainly can’t afford a shader that renders a planet full screen at a blazing 10fps on that kind of hardware.

The bad news I’m talking about is that this process of deleting your generated system files will have to be repeated every time I commit new planet shaders (if you want them). Which I expect to happen more than once or twice. Sorry folks, it’s the price of progress.

With planet shaders come tons of engine improvements:

  • I finally found how to hook randomizable parameters to planets, so expect more variety than texture changes alone. I’ll probably play with other parameters that make up the looks of a planet, like cloud coloring and whatnot.
  • sRGB framebuffer support is increasingly important with the multipass techniques the planets use. sRGB framebuffers mean you’ll experience improved color reproduction and fidelity. In fact, part of the graphical appeal of the planet shots I’ve been posting come from accurate gamma correction. I’ll be transforming all the other shaders into using those accurate gamma-corrected techniques.
  • Shaders support preprocessor #includes. That sounds technical I know… but it means it will be easier to work on new shaders given that we’ll have a reusable “standard library”. In fact that’s where all the gamma-correction stuff resides.
  • The “reload shaders” hotkey was not working. Now it is :D (mostly) - I kind of needed the key to avoid having to relaunch VS hundreds of times while developing the shaders.
  • City lights and atmosphere glow is now part of a planet’s technique, and not weird hacks in system files. Crafting beautiful systems just got easier :D - the bad thing here is that they don’t work in shaderless systems. Sorry folks, but progress needs programmable shading, if you find yourself forced to disable shaders, VS will start to look uglier every release. I’ll struggle to keep it playable, though… just not pretty.

Well, I think that’s it with the features.

But those features need art.

I’m formally requesting help here… we have quite varied planet textures, but a lot of the “layers” in those planets are missing. We have tons of terrestrial worlds (forest, carribean, etc…), but they usually don’t have neither city lights nor cloud maps or normal maps!

City lights, though a bit unrealistic (in reality, the nightside looks completely black, city lights being just too faint against the bright sunny side), they add a lot of beauty to the scene. So from an artistic point of view, planets need city lights. Besides, they become a lot less faint once you fly up close to the planet (say, while docking).

Cloud maps are obviously important, just take a look at the screenshots, cloud maps are 80% of the beauty of terrestrial planets. 100% of gas giants, and 40% of desert planets. They’re important. Yet we only have one or two of good quality (high-res enough to be interesting and with the proper format). As soon as terrestrial planets become commonplace, this lack of variety will be very very evident. I’m working on techniques that, without adding tons of new cloud maps, will add some variety - but I still need help here… I need contributions in the form of varied and high-quality cloud maps.

Normal maps are in fact normal plus height maps. Normal goes in color, height in alpha. I may change the technique in order to better pack the textures (right now, normal maps cannot be compressed without loosing a lot of precision), but the fact is that absolutely no planet besides earth has a normal map. And that’s very, very bad. Rocky planets, from my musings on the subject, will base their entire looks on complex, interesting normal and height maps. Without them, rocky planets will be dull. Terrestrials can get away without normal maps, but if anyone cares to take a trip to Sol and visit earth, you’ll notice while flying up close how normal maps can actually increase the perceived level of detail when flying close to the surface.

So we need normal maps. I cannot produce them all - in fact I don’t know how to produce even one of them, all the tools nVidia and the other companies provide for authoring normal maps are windows-only :(

I’ll be more than glad to help any generous soul that sets on the task of producing any amount of normal maps for the planet types we already have in SVN. It’s not like ship normal maps. You can’t just draw a random black & white “greeble” bump map and be done, planets are actually all about topography. Of earth we have topographic maps (that’s where its normal map comes from). From mars kind of too. But for our made-up planets?

So my job is far from done, and I’m already asking for help. No wonder commercial games need millionaire budgets ;)