Atmospheres

[t00fri]

This atmosphere rendering looks
much more convincing, now.

Fridger, at this "low" altitude, we should really feel the
3D volume of the mountains. The texture looks "flat",
painted on a smooth billard ball. You are too low. And
you need some FSAA (antialiasing) on your
horizon.

I disagree: the actual height of the camera was 205
km. The highest mountains are ~6 km here!
Think one moment what tiny fraction of the
observation altitude the Andes make up for in my 3
images. If I go really closer, my normal map gives
/breathtaking/ 3D views, in fact. But this was not the
issue HERE!

It's always good to do a back of the envelope check
before complaining...


I never (need) to use FSAA with my 1600x1200 19"
analog monitor. Since 19" is a bit too small for fitting in
1600x1200, there is a welcome "hardware AA effect"
due to somewhat overlapping pixels . In case of
smaller digital monitors/resolutions FSAA might surely
be needed. But the images were just for testing the
atmosphere...


Bye Fridger

[Cham]

I disagree: the actual height of the camera was 205
km. The highest mountains are ~6 km here!
Think one moment what tiny fraction of the
observation altitude the Andes make up for in my 3
images.

Well, looking at your pictures, it "feels" flat ! I can easily tell it's a painted ball. In some parts of the images, it's evident that everything is actually flat. Maybe it's an effect of the FOV ? But of course, this isn't the point of the discussion ... Sorry, I'm off topic.

[chris]

This atmosphere rendering looks
much more convincing, now.

Fridger, at this "low" altitude, we should really feel the
3D volume of the mountains. The texture looks "flat",
painted on a smooth billard ball. You are too low. And
you need some FSAA (antialiasing) on your
horizon.

I disagree: the actual height of the camera was 205
km. The highest mountains are ~6 km here!
Think one moment what tiny fraction of the
observation altitude the Andes make up for in my 3
images. If I go really closer, my normal map gives
/breathtaking/ 3D views, in fact. But this was not the
issue HERE!

I agree with Fridger: the 3D effect is very good in the screenshots. The horizon is still quite distant (and also mostly ocean), so I don't find its smoothness at all incongruous. Of course, you can eventually get close enough to the surface to notice the lack of actual relief. I will address this shortcoming in a future release of Celestia when I implement real displacement mapping. I don't anticipate that displacement mapping will replace normal mapping; normal mapping will remain the most practical means of adding extreme detail even with displacement mapped planets.

I never (need) to use FSAA with my 1600x1200 19"
analog monitor. Since 19" is a bit too small for fitting in
1600x1200, there is a welcome "hardware AA effect"
due to somewhat overlapping pixels . In case of
smaller digital monitors/resolutions FSAA might surely
be needed. But the images were just for testing the
atmosphere...

On an LCD monitor, the lack of AA is more noticeable. I run at 2560x1600 on a 30" LCD, and aliased edges are still noticeable with spacecraft models. It's not that bad with planets, especially when atmospheres are enabled.

--Chris

[Christophe]

Of course it is flat. This is not a displacement map, but a normal map. The shadows are the only thing giving you an illusion of volume, of course the effect is much more obvious when you see the shadows change with the position of the Sun than on a screenshot.

[chris]

While Celestians can live with this for another while,no doubt, outside users may find such irritating "phenomena" disqualifying, for example...

While I see your point, I could imagine workarounds that might certainly make the ongoing "nonsense" less evident .

I could turn up the amount of extinction, but this would likely have other unpleasant side effects (like making the moon almost invisible even at night.)

I was thinking of decreasing faintestMag quickly towards 0 from its default night value (~7), whenever the star /appears/ to be located between radius and radius + atmosphere.height?

It's quite complicated to do that . . . For one thing, you only want to adjust the star brightness on the night side of the planet (especially difficult if the planet happens to be lit by multiple suns.) I'd be more motivated to fix the problem by adjusting faintestMag if it was physically correct solution. In reality, the daylit limb of a planet would be so bright that it would drown out the light from all stars in the field of view, not just the ones overlapped by the atmosphere.

HDR Celestia will happen, and will correct all these problems . . . With a floating point frame buffer, Celestia draws a star at it's /real/ brightness, say 0.0001. Then the atmosphere is rendered with brightnesses on the order of 1 (very roughly). Additive blending would result in a total brightness of 1.0001 where the atmosphere overlaps the star-- imperceptibly different from areas where there is no star. Of course, the whole range of brightnesses from 0.0001 to 1.0+ isn't visible on a conventional monitor. That's why post-processing for exposure is required after the scene is rendered: to map the physical brightness values (either linearly or logarithmically) to a range presentable on screen.

A slight aside . . . Here's an interesting article on HDR techniques for processing astrophotos taken at different exposures:

http://www.iceinspace.com.au/index.php? ... 94,0,0,1,0

--Chris

[cartrite]

I've been thinking about normalmaps quite a bit in the past few days and I wondered if it were neccesary to include all those tiles that are generated for the oceans, say past level3. As for the base textures. Would it also be neccesary to include tiles that are "all" ocean color past say level 3. Once a tile is drawn for an area it will keep being drawn if there isn't a new tile at the next level to take it's place, correct? If this were possible it would probally increase performance, save memory, and disk space where VT's were concerned. Fridger, did you include all these files in your VT's? There are a lot of tiles that are 0 elevation or all ocean color in level 4, 5, 6, etc.
sorry if this is a little off subject.
cartrite

[t00fri]

I've been thinking about normalmaps quite a bit in the past few days and I wondered if it were neccesary to include all those tiles that are generated for the oceans, say past level3. As for the base textures. Would it also be neccesary to include tiles that are "all" ocean color past say level 3. Once a tile is drawn for an area it will keep being drawn if there isn't a new tile at the next level to take it's place, correct? If this were possible it would probally increase performance, save memory, and disk space where VT's were concerned. Fridger, did you include all these files in your VT's? There are a lot of tiles that are 0 elevation or all ocean color in level 4, 5, 6, etc.

cartrite

Certainly NOT. In our optimized normal map tiles (nmtools) ALL nm tiles are first checked for being monochromatic (oceans!). If yes, they are replaced by the smallest ones (4x4 pixel ONLY !) required by DXT format. That all happens in one command (nmstiles), along with the appropriate reduction in tile resolution towards the poles!

This saves tremendous amounts of space, since the earth has a lot of oceans

I am sure I described this a number of times in various threads already.


Bye Fridger

[t00fri]

talking about "flatness" here are some shots from an altitude of 65-70 km only.

1) This is really close to where Chris was climbing
Have a click for 1600x1200


2) This is in central Asia,
Have a click for 1600x1200


Bye Fridger

[t00fri]

While Celestians can live with this for another while,no doubt, outside users may find such irritating "phenomena" disqualifying, for example...

While I see your point, I could imagine workarounds that might certainly make the ongoing "nonsense" less evident .

I could turn up the amount of extinction, but this would likely have other unpleasant side effects (like making the moon almost invisible even at night.)

I was thinking of decreasing faintestMag quickly towards 0 from its default night value (~7), whenever the star /appears/ to be located between radius and radius + atmosphere.height?

It's quite complicated to do that . . . For one thing, you only want to adjust the star brightness on the night side of the planet (especially difficult if the planet happens to be lit by multiple suns.) I'd be more motivated to fix the problem by adjusting faintestMag if it was physically correct solution. In reality, the daylit limb of a planet would be so bright that it would drown out the light from all stars in the field of view, not just the ones overlapped by the atmosphere.

Chris, I agree that a non-futched solution is laborious.

Yet my argument is that the present respective situation is so strikingly nonsensical that it might be worth and advisable considering /partial/ hacks for now. I wouldn't be bothered, for example if multiple suns were still at a loss.

+++++++++++++++++++++++
But those views that EVERY (new) user tunes in within the first few minutes of operation should not hurt people's common sense!
+++++++++++++++++++++++

Here is my related story that I remember well: More than 4.5 years ago, when I didn't know you yet, but had just discovered those nonsensical bright stars around star discs, I almost dumped Celestia after my first tries, since I was convinced it's author has no idea about physics .

I actually wrote an upset complaint post, to which you never answered ...

A slight aside . . . Here's an interesting article on HDR techniques for processing astrophotos taken at different exposures:

http://www.iceinspace.com.au/index.php? ... 94,0,0,1,0

--Chris

Thanks, that is VERY interesting.

Cheers,
Fridger

[chris]

I just got atmospheres working for meshes . . . The only realistic usage is for modeling planets with meshes that are displacement mapped spheres, like some of the work by cartrite and others. Also, I'll probably improve the appearance of comet tails with a technique that uses the new atmosphere code.



--Chris

[Cham]

OOOW ! Chris, this could help a LOT to design nebulae ! I was hoping for something like this since a very long time ! This may resurect many old nebulae projects I had, but abandoned.

Does it work too if the mesh has a semi-transparent texture (PNG) ?

[MKruer]

If I could do something like this, I would be happy. The planets has a super strong magnetic field and is very close to the center star, this creates a bow wave that is visible in the visible light spectra (if you could remove the glare) right now the object is really four objects, three planets and one comet. Two the planets are rotated 180 degrees from the main axis, and have an elliptical have to them. (This is one of reason I wanted support multiple cloud layers with definable axis, but I digress)

I hope whatever you come up with is flexible enough to accommodate this.

Thanks Chris this will be/is a huge improvement either way.

[chris]

OOOW ! Chris, this could help a LOT to design nebulae ! I was hoping for something like this since a very long time ! This may resurect many old nebulae projects I had, but abandoned.

Does it work too if the mesh has a semi-transparent texture (PNG) ?

Sure . . .


Ummm . . . weird. There are a couple things that need to be done before this is useful. One thing is that atmospheres are still designed for spherical objects--you can see the bluish sphere in the middle of the atmosphere. The density falls off exponentially with height the surface; but here, you really want that radius of that surface to be much smaller than the radius of the object. The code handles it, but there's no way to specify that alternate radius in an ssc file.

--Chris

[Cham]

Ummm . . . weird. There are a couple things that need to be done before this is useful. One thing is that atmospheres are still designed for spherical objects--you can see the bluish sphere in the middle of the atmosphere. The density falls off exponentially with height the surface; but here, you really want that radius of that surface to be much smaller than the radius of the object. The code handles it, but there's no way to specify that alternate radius in an ssc file.

I'm not sure to understand. However, that picture is showing endless possibilities.

And what if the model is a simple plane ?

[cartrite]

I came up with some settings for Mars.

Code: Select all

   Atmosphere {
      Height 30
      Lower [ 0.8 0.6 0.6 ]
      Upper [ 0.7 0.3 0.3 ]
      Sky [ 0.83 0.75 0.65 ]
                Sunset [ 0.7 0.7 0.8 ]
      #Mie 0.001
      #MieAsymmetry -0.15
      #Rayleigh [ 0.006 0.0025 0.002 ]
      Absorption [ 0.0002 0.0004 0.0008 ]
      #MieScaleHeight 8
      #CloudHeight 7
      #CloudSpeed 0
      #CloudMap "MarsClouds.png"
      Mie 0.00025
      MieAsymmetry 0.15
      Rayleigh [ 0.00175 0.000875 0.00075 ]
      #Absorption [ 0 0 0 ]
      MieScaleHeight 14
      CloudHeight 7
      CloudSpeed 0
      CloudMap "MarsClouds.png"
                # Slightly bluish sunset, as seen in true color pictures
                # from Pathfinder
   }

Some shots can be seen here. I didn't want to bog this thread down with large images.

http://www.celestiaproject.net/forum/viewtopic.php?t=10005

Off hand I can think of 1 thing this new code might be able to do. If someone made a mesh of irregular shape that somewhat looked like nebulae M16 (or others) and had the height very large and put it in the area of M16.........., mabey this could be a way of doing Nebulae.

Edit: After the code could do irregular atmospheres of course.

cartrite

[t00fri]

That's how the sunset looks like on Mars with cartrite's choice of atmosphere parameters:



Bye Fridger

[chris]

That's how the sunset looks like on Mars with cartrite's choice of atmosphere parameters:

I think that the sunset looks too greenish.

Here's a picture sunset on Mars from Pathfinder:


There's a slight bluish color there. I'm not completely sure what is going on with Mars's atmosphere--it seems like some sort of reverse Rayleigh scattering. Absorption of blue wavelengths doesn't explain it, otherwise you wouldn't have the color change at sunset.

--Chris

[ANDREA]

That's how the sunset looks like on Mars with cartrite's choice of atmosphere parameters:
Bye Fridger

Thank you, Fridger, very nice.
But IMHO it looks a bit too dim, considering (respect to the Earth) both the increased distance from Sun and the decreased atmospheric pressure, am I wrong?
Moreover, in the images of sunset and sunrise from Spirit and Opportunity. the sky was looking pinkish instead of greenish like here.
Bye

Andrea

[ANDREA]

Damn... five seconds later than Chris!
Better next time.
Bye

Andrea

[cartrite]

I thought my settings needed some tweaking. I never seen a real sunset picture from Mars so I didn't no what to shoot for. I was trying to match the sky that was a part of the old settings for other render modes in Celestia. Now that I see a real picture I will try to adjust for the sunset.

cartrite