Vega Strike Forums

Just a quick status update. Looking for atmosphere and terrain shading I checked Sean O'Neal's stuff and decided to reuse some of the code (shaders, texture updates), started isolating/porting the code.

I think even his mesh gen method could be an interesting alternative to the OgrePlanet mesher. Atm it is way too slow, draws a bazillion of tiny meshes and is not threaded.

The minimum target is to use his shaders at least.

Some pics(not in VS yet):

Have you looked to see if any of the other codebases use any type of grey scale height maps? I know several different games (notably Warzone2100 and SimCity 4) can import greyscale bitmaps to create the terrain used in those games. Im wondering if we will need to use something like that to create how we want the planets to look. Not sure how many we would need to keep from having all the planets look the same though.

You would need a few GB of height data(nasa blue marble) to get the details at planetary scale. OgrePlanet and O'Neal's code are using fractal noise. You define the height generator by linking different noise modules and providing a set of parameters. The height values are generated on the fly depending on your current position.

A planet creator/editor where you can play with the noise modules with interactive preview would be cool I think. But need to finish the planet code first.

Something like this: http://lithosphere.codeflow.org/screenshots.html

If we can have height maps in sections we could have a good number and just reuse some of them. Have a struct/class to hold the values of what maps could or should be used with what type of planet to put the whole world together rather than one giant map. Using fractal noise how do we handle adding in vegetation, rivers, cities, etc?

Using fractal noise how do we handle adding in vegetation, rivers, cities, etc?

The fractal stuff is just a dynamically generated(loaded) height map. You can see it as a compression method. The problem about using pregenerated height maps is the data amount. For a one km^2 resolution heightmap of the earth surface you would need about 500MB data for one byte height(80m height resolution?).

Update:
I've got O'Neals scattering shaders running. The only blocker right now is the blending(sky mesh). It is stupid simple in OpenGL, but I have problems to get it right in Ogre3D.

Awesome work log0, can't wait to see screenshots. May try to compile it in a few days - is this work being done in the vegaogre repo? No commits for 2 weeks there.

Some questions:

1. Any idea when this might have an already compiled version posted?
2. Is the sun positioning derived from the actual position of the local star(s)?
3. Any plans of adding lens flairs with Ogre?
4. What is the possibility of including both the Ogre and the VS in-house engines with a line in the config (and possibly a toggle in setup) and switching between the two?

travists wrote:What is the possibility of including both the Ogre and the VS in-house engines with a line in the config (and possibly a toggle in setup) and switching between the two?

They would have to be equivalent for that to work. Even same API.
Are they?
I doubt.

A compile-time flag might be easier.

The code is in the vegastrike experimental branch.
The scattering/atmosphere patch is blocked by the blending issue.
Light direction(sun position in the sky) is the vector from central star to planet, depends on planet position, rotation.
Enabling ogre planet rendering can be done at runtime(vs start). I think BEZ meant he had implemented it for his gravity work.

Next targets are:
Implement normal/color texture cache(per vertex normals look ugly).
Fix the camera issue(move vessel drawing into ogre).
Implement a few different planet types(config file per planet type?).
Port the sun/star shader to glsl, experiment with it.

how is terrain generating going to be handled? will we be able to use images to generate the terrain? i am not too worried about map height, but with earth, for example, it would be good to have all the countries. I know size would be an issue for a detailed map, but what about a 10km^2 map, should detect almost every island on earth, and the size shouldn't be too big.

Or could it be possible to have it load a few seperate images of the land masses, and fill in the rest with water, would reduce images sizes by about half i would assume, with 70% of earth being water

Honestly, I think both methods (height map & fractal) are needed. In Sol: Mars, Luna (Earth's Moon), and Earth it's self all have detailed maps available, and are fairly well known. As such if planetary flight is used, people will expect accuracy, there are also other key planets that specific maps would be nice I'm sure. Conversely, to map every planet would take a huge amount of data and is thus impractical even if there where the artists available to create the content. The only logical solution is to use both methods as appropriate.

Not only that.

One might want to craft some planets in a certain specific way, but not necessarily in full detail. Combining height map data with fractals seems like the best bet: gross shape given by height map, details by fractal.

wonder if this can be tied into the game, http://en.wikipedia.org/wiki/Celestia for some more realistic simulation of the solar system, and some nice textures

VS is already using textures from celestia whenever possible (ie: allowed by their license)

Atmosphere shader patch is here(source+data): https://sourceforge.net/tracker/?func=d ... tid=319507

It has got a few bugs to be adressed, but runs at least(ATI card). Would be great to get some feedback if it runs on other GPUs.

New clips:
http://www.youtube.com/watch?v=abb5ZwLmfjQ
http://www.youtube.com/watch?v=W1upvzYYLc0

Unfortunately the blue sky is not really visible due to blending with the bright background skybox.

Atmospheric glow is great, but should stars be visible on the day side like that? does not look like you're flying high enough for that anyway. Atlantis will be eventually mostly water not desert right?

The vs background box is way too bright for this.

Here a pic with black background(screaming for some hdr processing lol):

Quite good! Can the volumetrics be used to further blot out the background, or would it be better to use a black sphere that is only visible from the under side?

To fix the sky issue one would need backgrounds with somewhat realistic light intensities(not the current cartoonish ones) and hdr rendering maybe.

Or just ditch the backgrounds(I know ain't gonna happen).

I was actually thinking about ditching backgrounds in a number of systems.

In fact, I was thinking of adding nebulae entries to galaxy.xml, that would be used in the system generator to decide which sky to use: black when far from nebulae, some nice and consistent background when close or inside them.

Would anyone help me there? (we could use specially crafted backgrounds for that).

There was an idea floated about where the stars make their own background. Will Nebulae be of realistic size (I.E. light-years across) where they could be done the same?

Yes, but we need lots of new features and content to pull that off.

However, just modifying the way the system generator picks backgrounds is easier.

We could go for the better option entirely anyway. Which is defining light-years-across nebulae in galaxy.xml, define meshes for them, and render them on the background instead of merely a skybox. That will take time, though.