Thanks for sharing [USER=“1000157”]The Regurgitator[/USER] ! Great results you get there!
Planet shadow: I added that and it will be in 4.25 if QA does not find anything bad. https://github.com/EpicGames/UnrealEngine/commit/b8ee0a2c43f29695720ad37051a0571e194268eb.
Only tested by me so far. ALso be careful since when per pixel transmittance is enabled, every triangle “inside the virtual planet” will be black (because it intersects with it and thus is in shadow).
Flickering bug: yes this is the bug we already have registered but I have not been able to reproduce so far… Still in progress, stay tuned.
Performance: space view as of today forces ray marching per pixel. This is because LUTs are optimized for ground view are less effective in space. So right now this is more expensive yes, especially at 4k. This is not a path we have used and tested a lot yet. So stay tune for future improvements.
What I recommend you to try locally for your case since you still stay relatively close to the planet: do no force ray marching when out of the atmosphere (this can be done by increase the atmosphere radius for instance). See how it looks and increase the resolution of the transmittance, multiscattering, skyview and aerial perspective as needed. You might find a sweet spot that works for you.
@SebHillaire Thanks for the update! I’ll try out the transmittance shadow soon.
I am now pretty much convinced that the flickering has something to do with specular (or possibly screen-space) reflection of the bright directional light in the scene.
@SebHillaire Would it be possible to add an overwrite for the sun disc scale and visibility? Right now if I increase the source angle to get nice soft shadows with RT I end up with a giant sun.
I think the point of physically based rendering and especially Ray Tracing is having shadows related to light source properties. So it just makes sense that softer shadows make sun bigger. Not saying you should not be able to do that if ever needed, but I don’t think it belongs right in the main Sky Atmosphere UI as an instant “break accuracy” button. There could be some modifier but it should be hidden away more.
Yes, I suppose that would actually make sense. I am just worried about new users who are not yet sure what they are doing. Controls like this exposed by default go into opposite direction of explaining new users the basics such as shadow softness being related to light source size.
Two factors come into play. Scattering of light in the atmosphere and glow/glare from the optics capturing the image. Some earlier atmosphere models such as Mental Ray’s physical sky did a big mistake of embedding the glare right into the sky model itself, not just atmopsheric scattering. But that does not seem to be the case here. Just turning of bloom in post processing settings displays the actual sharp sun disc. You will also be extremely surprised how tiny the sun disc really is. Generally, people tend to underestimate how small the sun disc without the glow actually is. That may in fact tie to @The_Distiller 's request above, where he may have gotten giant sun disc mainly due to a glow.
Some examples:
Default new sky with default amount of bloom (no PP volume present in scene to override it):
@Rawalanche I totally agree. Also, some atmospheric effects depends highly on light physics at certain latitude/longitude. I have experimented some Sun effects to approach this picture, originally captured at Sweden on a very specific weather conditions and also during a certain season as follows: [video]https://twitter.com/i/status/1134892762246144002[/video]
That one would be beyond difficult It involves basically a simulation of caustics inside volumetric media. That would be tricky even for an offline renderer. You can see that when the sun disc goes out of frame, the whole thing stays in place, so it has nothing to do with the camera optics at all. It would be overkill to simulate such an advanced dependencies in Unreal’s realtime renderer, so this would have to be faked somehow
Just wondering, if it causes such a significant performance drop, shouldn’t the debug text be set to 0 by default, so that all the people who use the new sky level template get proper performance out of the box? I mean it’s a bit silly that if user selects one of the 3 level templates, he has to lurk forums to find an obscure cvar to fix it to get proper performance so he can start working on the level… ?
In my project, I’m placing the cine camera very far from Earth. The camera is moon distance in centimeters and I’ve cranked up the focal length.
The atmosphere looks fine up close, but at a long distance under a high focal length it begins breaking up.
Curious if there’s a way to keep my camera distance and eliminate the noise/breakup of the atmosphere.
I’m also noticing the clouds are not visible at this distance.
I’ve reproduced this; it appears the effect breaks down, possibly due to z-fighting with the surface below it, or possibly due to some other issue in the sampling.
@Rawalanche Yes I agree I was hesitating with that solution also. But the message is important (and only there when using a Sky material shader). I’ll see if 4.24 can still take that.
@GTJC Great scene As mentioned by [USER=“1000157”]The Regurgitator[/USER] this is likely due to some imprecision when tracing and/or zfighting with you planet mesh. far camera + small fov can cause that and we have not invested time in such cases yet. Other solutions to try: use Ortho projection then distance to earth does not matter and will look very similar to your use case or increase the atmosphere height and Mie/Rayleigh distribution in the atmosphere (would look different but might be acceptable).
@SebHillaire and [USER=“1000157”]The Regurgitator[/USER]
I was hopeful to maintain perspective camera as opposed to orthographic. I’m interpreting an older work and thought it’d be cool if I could apply as much of a realistic setup as possible.
I’m a Maya artist making the switch to Unreal (slowly). Currently with this short project my goal was to have the same animation/camera etc. setup up in both Maya and unreal so they are 1:1 in setup/scale. Then I was going to use Maya/Redshift as my guide for matching post process closer to my maya render.
At first I tried a realistic earth/sun/moon scale/distance, then miniaturized it, which is what I posted on page 2 of this forum. Looking back it was clear the atmosphere with a ground radius of 100 looked very wrong.
So, I rebuilt my scene to match the default ground radius in Unreal (which appears to be real world scale in centimeters). This is far more appealing.
From there I stubbornly built the real world sun scale and distance (ignoring the fact that that is an absurd expectation of Unreal/Maya or any 3d package), but found the sun wasn’t visible in viewport unless I selected it making it hard to artistically adjust bloom/flares/color etc.
From that point I built a mini sun/closer to earth.
The real moon distance and scale seems to work within the clipping planes of the camera so I kept it.
With each of these steps I reanimated everything at the new scales/locations.
I suppose, worst case scenario I could find a false moon distance at which the atmosphere works and find a new focal length. And then reanimate. But before I do this, I will dig a little.
I tried playing with the atmosphere height and Mie/Rayleigh distribution (with meshes present under the atmosphere) with no luck.
To test the theory that it’s z-fighting the geometry below the atmosphere, I hid all geo and left only the initial directional light (the one tied to the atmosphere) and the sky atmosphere node.
Looks like the atmosphere breakup still happens without any geometry present:
This likely isn’t relevant to the cause of the breakup, but I tried it to see if it improved or not . . . it looks like the breakup changes dramatically depending on the AA. Again, not likely relevant.
I will try playing with the atmosphere height and Mie/Rayleigh distribution settings with no meshes present next, but have to get ready for work and will try more tonight.
Thanks for the investigation and nice report. So if it still breaks without geometry then it is only due to the atmosphere tracing itself. I made sure it is on the *to-investigate *list.
If you try again to reduce the radius of the planet then the atmosphere setup needs to be adapted (it does not scale automatically while preserving look):
proportionally reduce the atmosphere height
proportionally reduce the height distribution for Mie and Rayleigh
same for the absorption tent distribution altitude and width
scattering and absorption coefficient will need to be made inversely less high
It might still look at bit different I believe because earth curvature will be different (especially at the light to shadow transition). I hope it can help you.
If you do beauty shots from space, you might want to increase r.SkyAtmosphere.SampleCountMaxused when tracing the atmosphere (see the reference pagefor all the settings). I’ll add details on rendering the atmosphere from space to the documentation for 4.25.
Hi all, I have a noob question, do I have to use a skydome at all? Because for new Sun Sky plugin it seems like I don’t have to (at least from visual perspective). I have volumetric clouds in the scene and I’m blending different cubemaps based on day time. I’m also planning to mix one extra cubemap for overcast. But if I had no specified cubemaps there would skybox be required for captured skylight?
@SebHillaire thank you for adding it to the to-investigate list. I was overseas for work and am back now to continue my digging.
It’s apparent I have not played with many of the rendering commands in Unreal in general nor in relation to the Sky Atmosphere node.
Playing with the r.SkyAtmosphere.AerialPerspective.StartDepth and r.SkyAtmosphere.SampleCountMax is cleaning up a bit of the noise, not completely gone but definitely cleaner:
@GTJC Ok then. I am surprised the AP commands improves the result in this case.
@Z0DI4C.2.0 You do not have to use the sky dome shader with IsSkyTicked. That is only if you want to render a sky dome (with custom composition of clouds, planet and whatnot) as unlit opaque while not having the aerial perspective (atmosphere fog) apply on it again.
It involves basically a simulation of caustics inside volumetric media. That would be tricky even for an offline renderer. You can see that when the sun disc goes out of frame, the whole thing stays in place, so it has nothing to do with the camera optics at all. It would be overkill to simulate such an advanced dependencies in Unreal’s realtime renderer, so this would have to be faked somehow 
