JonahPlusPlus
commented
10 months ago That would be out of scope for this project. How it currently works is that whenever properties of the atmospheric model are changed, it renders and caches a cubemap. This helps performance when updates are infrequent and used to support features like splitscreen. What you are describing would require frequent updates to render the planetary body from different perspectives in realtime.
What I recommend instead is looking into signed distance fields (SDFs). I haven't worked on rendering planets before, but I this is where I would start (since an SDF can be used to represent altitude on a planet, which would control particle scattering). Of course, take a look at the surrounding literature first.
However, if you are planning on rendering multiple planetary bodies, I think it would be significantly easier to just make 3D models and use custom shaders to render the surfaces. Then, if you want to travel to the surface of the planet, just use bevy_atmosphere and play with altitude and direction settings to change the sky.
PS, no, the density isn't constant. If you compare the shader to GPUGems, you can see the implementation of drop off. Drop off is controlled by the scale height parameters. (I'm a bit rusty with this code, haha)
Hey there! 👋
Does your implementation use constant atmospheric density? You've done a great deal of preceding work here and it would be very interesting to use the Nishita implementation to provide atmospheric scattering for a spherical planetary body, where the exponential drop-off in density is quite relevant.
Do you think it would be a lot of work to support spherical bodies and viewing from the outside?
Friendly regards Moritz