Atmospheres

[t00fri]

Friends,

certainly - in this department- most of us know the beautiful /blue/ Mars sunset photo that Chris was showing

Of course I agree with Chris and cartrite that we need to play a bit more for arriving at the perfect Mars atmosphere...

Bye Fridger

[cartrite]

This looks a little closer to the image Chris showed. I don't think there is a way to get a blue halo around the sun that I can think of.

Code: Select all

       Atmosphere {
      Height 50
      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.0015
      MieAsymmetry -0.15
      Rayleigh [ 0.000885 0.000475 0.00061 ]
      #Absorption [ 0 0 0 ]
      Absorption [ 0.0006 0.0008 0.0005 ]
      MieScaleHeight 16
      CloudHeight 18
      CloudSpeed 0
      CloudMap "MarsClouds.png"
                # Slightly bluish sunset, as seen in true color pictures
                # from Pathfinder
   }


edit Caution, what looked alright from the ground looked a little off from high orbit.



cartrite

[Chuft-Captain]

. . . 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

Awesome stuff Chris!! However, I beg to differ... I can think of a great realistic use for this: I've been trying to put an atmosphere inside my O'Neill cylinders for a while now using a variety of kludges, but without much success.

This could be the final solution!

Would it be too much to ask for you to make it possible to put an atmosphere "inside" non-spherical meshes?

[cartrite]

Chuft-Captain wrote:

Would it be too much to ask for you to make it possible to put an atmosphere "inside" non-spherical meshes?

I don't know if the atmophere code was meant to work inside meshes but it already is visible from inside a mesh. While flying around Mars I happened to fly inside the planet when approaching Olympus Mons and the atmoshere was clearly visible from "inside" the mesh. Perhaps a small mesh inside the cylinder with a large atmophere with a height high enough to fill the inside of your O'neil cylinder would work?

cartrite

[Chuft-Captain]

I don't know if the atmophere code was meant to work inside meshes but it already is visible from inside a mesh. While flying around Mars I happened to fly inside the planet when approaching Olympus Mons and the atmoshere was clearly visible from "inside" the mesh...

Thanks for the info cartrite. That's why I suggested it, because I too suspected that interior atmospheres may not be considered as an option, however I think if this could be allowed, it could be very useful in many as yet un-anticipated situations, not just spacecraft. eg. Modelling the interior of gas-giants perhaps ? I always believe in allowing maximum flexibility...as long as it doesn't involve an un-acceptable increase in code complexity.

I'm no expert on the technical details of implementing this, and haven't looked at the code, but perhaps it could be as simple as allowing the atmosphere parameters in the SSC to take their bearings from the normals of the object's surface. ie. If reversing normals can cause textures to display on the inside of surfaces, then why not use the same paradigm for atmospheres...If the normals are reversed, then so too is the atmosphere. Chris, any comment?
EDIT: Damn, I just thought about this again ("clearly" this time), and realised it won't be this simple because the atmosphere is associated with the object, NOT the surface. ie. In a given model, some surfaces may have normals reversed, while others may not.

Perhaps a small mesh inside the cylinder with a large atmophere with a height high enough to fill the inside of your O'neil cylinder would work?

Good thinking, and that is in fact pretty much the technique I've tried up to now, except up until now I've had use a highly oblate planet, and the results are not really acceptable.
From memory, there are problems with making the "planet" invisible whilst still rendering the atmosphere (I don't want to "see" the planet, just the atmosphere), and it's also difficult to constrain the atmosphere to the interior, as the cigar shaped planet is not an exact match to the shape of the model, and atmosphere can extend through the endcaps of the cylinder.

I've also used similar technique to get clouds inside with some limited semi-realistic success, but this had problems as well, and so I put it on the "back-burner". eg. 1. when viewed from certain angles, clouds and atmosphere would disappear; 2. turn up the texture transparency too much and the clouds aren't visible, turn it down to make the clouds appear and I'd end up with unwanted sharp visible edges of the model hosting the clouds.

I'm optimistic that the excellent work done by you on clouds with normalmaps will translate well to my application. I was using similar techniques with semi-transparent models with cloud texture's applied inside my main cylinder, which had some success, but nothing compared with the results you seem to be getting with the new normals stuff. (In my experience, there always seems to be issues from certain viewing angles with these techniques)

EDIT: HERE, I've put a small (1 MB) video depicting a squall travelling thru the San Francisco bay located inside my habitat . This probably represents the best I've achieved to date in terms of interior clouds, and only worked well from certain viewing angles.

I personally think that ideally all parameters such as cloud height, atmosphere height, etc should be measured relative to the direction of the "normals" of the surface. This would give maximum flexibilty for as yet unconsidered applications.

Also, I was wondering if the atmosphere code for meshes will still be spherical, or if it will "follow" the contours of the model. (This is prob. a question for Chris)

Apologies, to you Chris for immediately asking for more, MORE, MORE!!, when you've just cracked this, but just trying to give a point of view that you may not have considered if your code was focused only on exterior surfaces, and perhaps it's not too hard to allow both! (EDIT: Probably also best to make my suggestions earlier, rather than later, before you've invested too heavily in code )

I'm hopeful that your code will accomodate these ideas without too much trouble.
EDIT: In light of my re-think (above) Chris, you might want to ignore most of my suggestions: Of course, you probably have some better ideas about how to do these sort of things anyway. Perhaps an atmosphere can have a negative height instead of being associated with surface normals.

regards
CC

[jgrillo2002]

I have a question regarding the new features. will the atmosphere work on my NVidia Vertex render path. it load alot faster but when I go to OGL2 path, it slows down. I have a GeForce FX5500 256MB and 1536MB RAM

[selden]

...will the atmosphere work on my NVidia Vertex render path. it load alot faster but when I go to OGL2 path, it slows down.

Unfortunately, drawing the new atmospheric effects, Mie and Rayleigh scattering, requires v2 routines.

The OGL2 path always will be slower because its effects are more complex. Many of the new features need OpenGL routines that were first defined for v2, and also require a lot of computation. In the OGL2 path, many of the older, simpler, drawing functions have been replaced by more complex ones. They produce better visual results but take longer: shadows, for example, have smooth edges instead of jagged ones.

Sorry.

[cartrite]

The fix in rendercontext.cpp works great for the semitransparency problem in OGL2. Thanks Chris.

cartrite

[chris]

Also, I was wondering if the atmosphere code for meshes will still be spherical, or if it will "follow" the contours of the model. (This is prob. a question for Chris)

No, it will only work for ellipsoidal shapes. Making volume work for general mesh geometry is a much different problem.

EDIT: In light of my re-think (above) Chris, you might want to ignore most of my suggestions: Of course, you probably have some better ideas about how to do these sort of things anyway. Perhaps an atmosphere can have a negative height instead of being associated with surface normals.

I don't think that negative heights will work. I may offer an option to use an alternate base height for the atmosphere.

--Chris

[t00fri]

Here is another twist about atmospheres:

Titan's atmosphere is among the most challenging cases for how well Chris' new code can really perform. It's also a most interesting environment to model from a more physics-inspired point of view.

All-in-all it's just VERY interesting

What I am dreaming about when looking at my tedious Titan surface work is to be able to dive into the atmosphere through several layers of smog




and fluctuating clouds until I finally see my surface structure...

Venus is another such challenge. So far Venus is a bit dull. While the radar images are hires and at least mind inspiring, the atmospheric "experience" is boring to say the least.

Opinions?

Cheers,
Fridger

[ajtribick]

Venus is another such challenge. So far Venus is a bit dull. While the radar images are hires and at least mind inspiring, the atmospheric "experience" is boring to say the least.

Venus really needs the kind of full-spectrum stuff that you have mentioned in the past, you need ultraviolet to bring out the cloud details.

[Cham]

I agree.

A fog effect can be great for Venus and Titan.

Venus is one of the dullest object and Titan can be improved. The new atmosphere code MUST improve those cases too, not just Earth and Mars. And what about Triton ? And the gas giants ?

There are a lot of possibilities for addons and other worlds here (SF, exoplanets, alien world, etc).

[chris]

Here is another twist about atmospheres:

Titan's atmosphere is among the most challenging cases for how well Chris' new code can really perform. It's also a most interesting environment to model from a more physics-inspired point of view.

All-in-all it's just VERY interesting

What I am dreaming about when looking at my tedious Titan surface work is to be able to dive into the atmosphere through several layers of smog

I will be working on Titan and Venus tonight. There are still some limitations of the new code that make very thick atmospheres look unrealistic. It's definitely a goal that the atmosphere code be flexible enough to give good results for all the atmospheres in our solar system. Multiple layers will take some more time; conceptually, it's not that difficult, but it's hard to make volume tracing fast enough for an interactive application like Celestia.

--Chris

[cartrite]

Chris,
I uploaded that Katrina model to the motherlode today and if you get a chance check out the model from directly overhead and where the light side of the planet meets the dark side. You should see that in OGL2 it is a lot darker than it should be and in other render modes it's lighter than it should be. It looks like there may still be a problem with the values passed to the final rendering and it may be a bug. I couldn't notice it before because the model was always about 50 % opaque. Here is a shot from Don's cloudmap. Notice the storm on the horizon. This is what I'm talking about.

Edit: For what it's worth, what I think I see is that the normalmap texture is being drawn longer then the diffuse texture as the area approaches a no light condition. The diffuse texture seems to be disabled a little too early. The storm on the horizon in the image below has already had the diffuse texture disabled.



cartrite

[AZ_Cowboy]

Chris:

Upon completion of your new code could it also be used to create Gaseous Cloud Nebula (see NEBULA)?

Also, there are usually several cloud levels that move at diferent velocities. I attempted to place multiple levels around Jupiter with no success.