Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atmospheres properties #1656

Closed
wants to merge 2 commits into from
Closed

Conversation

irigi
Copy link
Contributor

@irigi irigi commented Oct 31, 2012

WORK IN PROGRESS

This was attempt to solve #1395, #1598 and maybe others. I added specific heats and molar masses of different atmosphere compositions. I open this issue for discussion - there are still unsolved problems with the gas giants.

enum type and one function
* Use element-specific molar masses and specific heats
@irigi
Copy link
Contributor Author

irigi commented Oct 31, 2012

The main problem is that the atmosphere color calculated by shaders still gives too small atmosphere compared to adiabatic model for the gas giants (while it gives larger atmosphere for terrestial planets with hydrogen atmosphere). I don't have a clue why - I did some calculations and the isothermic atmosphere used by the shaders should almost always be bigger than adiabatic atmosphere calculated in Planet.cpp file. I. e. the pressure should always disappear sooner than the color.

Actually, I played a bit with it in Epsilon Eridani system. I changed atmosphere composition of New Hope to hydrogen atmosphere. It indeed got much bigger, both in the shader part giving its color and the pressure-calculation part in Planet.cpp. There, the atmosphere color was reaching even to places where the pressure was 0. This is OK for now, since the two models are not compatible. What is, however, very suprising, is that when I attempt to land on Hercules, it gives me much pressure, but almost no color - precisely the reverse of what happens at New Hope. It seems there is something wrong with calculation of color of gas giants - something more than that there are two incompatible models used. Do you have any idea why?

@Ae-2222
Copy link
Contributor

Ae-2222 commented Oct 31, 2012

I added specific heats and molar masses of different atmosphere compositions

I was thinking of gas/aerosol classes containing the properties needed for doing atmospheric scattering as well as those gas properties required for pressure calculation. The atmosphere would then be composed of a different combination of well mixed gasses and the overall thermodynamic properties be calculated. The aerosol would only effect the rendering, giving colour to atmospheres like that of Mars and gas giants. The main difference is in rendering so I was waiting for Bruneton scattering as available in GPL Proland library to be integrated eventually.

I did some calculations and the isothermic atmosphere used by the shaders should almost always be bigger than adiabatic atmosphere calculated in Planet.cpp file

Agreed:) Gas will always lose energy given it does work as it expands adiabatically in the pressure gradient. There's a quantity in Planet.cpp I called the adiabetic limit which gives the upper bound on atmosphere. If the scale height is very tiny compared to this or, if the pressure at a height is less for the isothermal model given the same surface temp/pressure, then there is an issue.

The only reason I can think of is a difference in the data provided to the two functions.

What is, however, very suprising, is that when I attempt to land on Hercules, it gives me much pressure, but almost no color - precisely the reverse of what happens at New Hope. It seems there is something wrong with calculation of color of gas giants - something more than that there are two incompatible models used. Do you have any idea why?

Ah, the current scattering is very approximate:). It pretends air is actually a coloured fluid. Also the integration is pretty rough.. I wouldn't be concerned about visual discrepancies unless there is a quantitative pressure oddity in the two models.

Edit:
(a 'coloured fluid' means the colour of the gas may be different see SystemBody::PickAtmosphere(). It maybe overridden by body type.)

@irigi
Copy link
Contributor Author

irigi commented Oct 31, 2012

Wow, this Bruneton article is pretty famous I guess, I accidentally read it like one year ago. :-) I was also thinking about playing more with atmospheric compositions - to put more gasses into atmospheres to get some more interesting info there and possibly use it for rendering, but I don't know how strict is the requirement that current fixed-generated universe must not change. I guess that if you will add some more parameters to the planet's atmospheres generate them, it will change everything, right? Maybe one could better use m_oxidizing variable - maybe if one would use "lower bits" of it to decide what proportion of different gases the planet has, the universe as we know it could be saved.. But the trick is a bit nasty.

The only reason I can think of is a difference in the data provided to the two functions.
I was also thinking if there is not some issue with scaling. Shaders calculate everything in units of planet radius and difference between radii of Hercules and New Hope is pretty big. But on first look, everything seems OK. (If there is not some numerical issue - float arithmetic is quite imprecise.) I will try to investigate, what results are given by which function.

Otherwise most of the changes in shaders I will have to probably leave to you - I do not understand graphics at all so it is not very easy for me.

@Ae-2222
Copy link
Contributor

Ae-2222 commented Nov 1, 2012

I don't know how strict is the requirement that current fixed-generated universe must not change

It can change from alpha to alpha:) Until one of the major aspects of Pioneer is not mature it is too early to freeze the physical universe as it might require adjusting to help balance things. Also the physical universe itself still has a lot to be worked on.

I guess that if you will add some more parameters to the planet's atmospheres generate them, it will change everything, right?

Not if the seed is used to generate the atmospheres. The issue comes when new items are inserted in to a list of things which use random numbers from the same sequence. Everything in the list after the insertion is affected. Currently, SystemBody::PickAtmosphere just uses the seed.


What is the exact discrepancy? - is it just colour (which is chosen based on planet type with a random element and with differing alpha values which may cause atmospheres to look thinner even with higher pressures), or the pressure being less at the same height for the isothermal model.


Shaders calculate everything in units of planet radius and difference between radii of Hercules and New Hope is pretty big

Shaders have the scaling taken into account. The shader implementation is simple/fast - the isothermal model features an exponential decay so the scaling height is simply used to calculate the density at a point relative to the surface density. SystemBody::CalcAtmosphereParams is responsible for sending the shaders invAtmosScaleHeight.

If there is not some numerical issue - float arithmetic is quite imprecise.

There's no real issue in shader precision - it just requires an approximate decay, especially considering the points of integration are spaced far apart..

I do not understand graphics at all so it is not very easy for me.

I had practically not even seen a line of graphics code before Pioneer:). My contributions in graphics, so far, have been in terms of algorithmic shader stuff which is mostly physics/maths based (once you know general rendering/lighting theory).

@irigi
Copy link
Contributor Author

irigi commented Nov 1, 2012

What is the exact discrepancy? - is it just colour (which is chosen based on planet type with a random element and with differing alpha values which may cause atmospheres to look thinner even with higher pressures), or the pressure being less at the same height for the isothermal model.

Check this: save parked on top of New Hope's atmosphere, save at the very bottom of Hercules' atmosphere, and modified epsilon eridani system.

The visible discrepancy is in the color density. Otherwise:

Hercules (T 134.0, M 0.002, g 40.58, R 89294 km):
atmosScaleHeight 13727.128906
atmosInvScaleHeight 6504.920898
atmosRadius 1.001537

Hydrogen New Hope (T 287.0, M 0.002, g 6.89, R8504):
atmosScaleHeight 173123.781250
atmosInvScaleHeight 49.121964
atmosRadius 1.203575

In the aerobraking2 save I am 3 km from the Hercules' surface where I should be IMHO immersed into atmosphere according to both models, but there is still no color! At New Hope, I sit ~470 km above the surface and there is a plenty of color.

(I'm thinking now: does the color shader attribute Hercules the color of hydrogen atmosphere, when it is not terrestial planet and has no m_atmosOxidizing variable? I will check that..)

@irigi
Copy link
Contributor Author

irigi commented Nov 1, 2012

The problem is in this piece of code (StarSystem.cpp):

case SystemBody::TYPE_PLANET_GAS_GIANT:
m_atmosColor = Color(1.0f, 1.0f, 1.0f, 0.0005f);

which makes hydrogen transparent for gas giants.. but if I add color to it, it will hide the relief on the gas giant's surface and all gas giants will look the same, like hydrogen. :-( This probably won't have any simple solution. Any ideas?

@irigi
Copy link
Contributor Author

irigi commented Nov 1, 2012

Maybe if we turn the color on when the ship is so close to the gas giant, it anyway cannot appreciate its colors? E.g. when the atmosphere density is above some threshold? It is a dirty trick, but I cannot think of anything better..

@Ae-2222
Copy link
Contributor

Ae-2222 commented Nov 1, 2012

The problem is in this piece of code (StarSystem.cpp):

That's what I thought:)

This probably won't have any simple solution. Any ideas?

Maybe if we turn the color on when the ship is so close to the gas giant, it anyway cannot appreciate its colors?

No simple solution.. the precise issue is that the amount of atmosphere along the camera-point on surface ray (i.e. the integration of density along the ray called the length density product in Tomm's shader) decreases as you get closer to the 'surface'. In reality the camera-point on surface ray extends deep into the planet so approaching the 'surface' does not appreciably change the length density product.

The other thing is that the 'surface' density is defined as 1atm at the given radius. I'm not sure what the temperature is at those altitudes. Gas giant temperatures quoted will be calculated based on the blackbody temperature of the gas giant being hot enough to re-radiate all the incident energy due to the sun and thus maintain thermal equilibrium (this doesn't include all the energy that might be superficially reflected due to the albedo value). Pioneer uses this equilibrium method for temperature calculations in non-custom systems (at least once the temp overflows are fixed in an upcoming branch which also has a lot of lengthy system generation tweaking to do). Literature on gas giant temperature profiles might need to be looked to find the correct temperatures at the 'surface'.

The eventual proper solution would be to have a much smaller radius as far as the rendered geometry goes - and crushh the player's ship before they got close to the 'surface'. There's a way to separate the rendered object and the radius used in other areas like physics/autopilot etc. in #1459. My plan was to wait until 1459 was dealt with.

@Ae-2222
Copy link
Contributor

Ae-2222 commented Nov 2, 2012

Btw, I've now started work on an atmosphere restructure for physics and rendering which I had planned once a scattering rewrite was done. It will be done in a way that allows gas/aerosol classes and support the simple scattering model with one gas, multiple gasses/aerosols with different properties, and Bruneton scattering when it's implemented eventually. I'll merge the work done here on properties into that one. It'll be finished this weekend assuming I get the time.

@irigi
Copy link
Contributor Author

irigi commented Nov 3, 2012

It's good to hear. Do you need something from me? Pull request of this into your code? I will look at your code once you make a pull request, maybe I will be able to add some details or bring some ideas. If you merge this PR, you can probably just close it.

@Ae-2222
Copy link
Contributor

Ae-2222 commented Nov 4, 2012

That was just a heads-up in case you started working on a major change or a restructure, as you weren't on IRC.

I've finished the re-write here. This allows work on detailed atmosphere constituents/properties with all the details needed for an advanced scattering method, before it is implemented. Details will benefit physics and help fix issues in the mean time.

I'll merge your work on details into it and you can resume work based on that (there's a checkout branch function in git). There's nothing for you to do as it's trivial with the new gas objects.

@Ae-2222
Copy link
Contributor

Ae-2222 commented Nov 5, 2012

I PR-ed the new branch with your properties added in #1686 :).

There should be a general issue for discussion about atmospheres though, as pull requests get closed.

From looking at your figures, I guess too much precision is impossible for Cp as it varies with temperature. We might be able to get a slightly better value if Cp at surface temperature was calculated by linear interpolation/extrapolation between two known values (so for instance planets like gas giants with low temps might have a more correct Cp). Cp for custom systems could be manually specified.

Oxygen values were made the same as Earth Air? After Cp and M are exposed to Lua it could be changed I suppose.


I'll look at artificially boosting the scale height for gas giants to give them a fuzzier appearance, for the time being.

@irigi
Copy link
Contributor Author

irigi commented Nov 5, 2012

I will create the "general discussion on atmospheres" issue and respond there. I will close this PR, since it is included in #1686.

@irigi irigi closed this Nov 5, 2012
@irigi
Copy link
Contributor Author

irigi commented Nov 6, 2012

I replied to pioneer-dev via mail. Let me know if the mail have reached you. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants