@SebHillaire To be specific, I’ve narrowed it down to the one render command, r.SkyAtmosphere.AerialPerspective.StartDepth
It seems values between 10 - 100 give a cleaner look (the look you see in my last images). If I put a value of 1, it gives the look I initially see (or if I close and reopen the project).
I’m finding a value of 100 crushes a bit of the transition area between the light/dark side so I’m playing with values between 10 - 75 currently.
I’ll post more soon.
Tried last night. Won’t install for me.
4.25 Preview 3 installs for me, in case anyone on this thread wanted an update.
Nice to see the atmosphere now renders behind the moon and not in front of it
Hey there. Concerning relations between the new Sky Atmosphere and the old Atmospheric Fog…
Firstly, what is the fate of the latter, will it be removed, supported independently, or somehow merged with Sky Atmosphere in the future? I am using Atmospheric Fog, I’m not satisfied with all colors it makes, especially too dark evenings (the sky must be still blue right after sunset, not black or grey with a greenish tint) but I would be upset if it’s gone.
Secondly, I’m a bit worried about performance of Sky Atmosphere compared to Atmospheric Fog. I am using Atmospheric Fog with stars skydome and at least two layers of translucent cloud meshes (cumulus/cirrus). My clouds shader is lightweight enough, even multiple cloud layers yield dark green shader complexity. But if I use Sky Atmosphere expressions with materials, numbers of instructions dramatically rise. Just a blue skydome with custom clouds, but shaders go dark red, while the colors are hardly better, and evenings are still too dark. Even the example material with poor 90x-games-like cirrus clouds has as much as 296 ps instructions! I really don’t understand why I need this all, so the first question is more important.
Hello @Alakuloinen ,
A few answers:
- AtmosphericFog will simply be removed at some point.
- Shader complexity: instruction count doe not do everything: texture fetch, scheduling and more also influence performance. You have to measure the actual GPU performance for your use case. usually the sky is not full screen and when it is, a lot of the world is not visible so it balances. There is also some smart pixel work culling happening on GPU. Cost of the sky is usually tiny as compared to the rest. Fortnite has very complex sky and has shipped on ps4, xb1, switch and mobile, some of them being at 60fps.
- Dark evenings: SkyAtmosphere can render beautiful evening with blue sky even when the sun is way below the horizon at sunset. Just make sure you have an exposure setup to see something. If it is too dark you can do the following: add a moon because on earth it is a high contributor at night. You can also use the more expensive (just a bit more) but more accurate multiple scattering evaluation by setting r.SkyAtmosphere.MultiScatteringLUT.HighQuality 1 (just noticed a name error in the documentation, we will fix).
Looking forward to that. It will hopefully remove tons of ambiguity and confusion. Right now, there are just too many wrong combinations possible
AMEN to that, too much confusion indeed, so we should use one over the other NOW ? Anyway , I am using Dynamic lights, takes too long to compile static till I upgrade a little, BUT as player moves, or even as camera moves, I get these nasty circular ( I guess) shadows to move along as player does.how does one REMOVE those, they are a real realism killer, and ya I have a world comp world 4 tiles (atm) just to verify this is on topic and I"m using Sun & Sky .
I am quite worried about usability. Unreal’s keyboard shortcut mapping was never very strong, but skylight gizmo takes this to a whole new level. Ctrl and L keys are about 20 centimeters from each other on an average keyboard, making them borderline impossible to press at once with one hand. At the very same time, the light direction gizmo can NOT be operated using the mouse without the combination pressed together, so it’s absolutely necessary to press those extremely distant buttons together using just one hand, and keep the hand in this very uncomfortable position during the manipulation.
This really needs to be done better. Right now, it’s a bit of UX failure
new sky in 426 , look great!
@Rawalanche if you meant left CTRL key, then yes that is not the intended use case. You do not have any right CTRL key on your keyboard?
I do, but that’s not how the muscle memory works. This is the first time I tried to use right Ctrl key in probably over a decade. I am willing to bet that the vast majority of people work with software by having one hand on the keyboard and other on the mouse. Of course that changes often, when you switch to typing text for example, but generally not otherwise. Your hand resides in leftmost area of the keyboard, assuming one is right handed. Here it makes all the less sense given that you actually **need **to interact with the mouse at the very same time.
So it becomes matter of using left Ctrl for every single software as well as every single other hotkey operation in UE4, and using right Ctrl just for this one specific hotkey in this one software
In any other case, if there’s a Ctrl key combo with the key being far from right Ctrl, I’d usually just take my other hand off the mouse to press it, Ctrl+P being an example. Not a big deal. I guess what’s so incredibly jarring here is that you can’t really do it here as the other hand needs to remain on the mouse to orient the light direction.
Ok thanks a lot. I guess it depends on people, I am fine with moving my hand this way
I’ll raise the point with our UX team.
Thank you, @SebHillaire, I’ve got better evenings with only exponential height fog.
Okay, instructions don’t do anything (though some 1-2% FPS drop I’ve experienced) but I can’t keep calm if a simple operation of retrieving a sky color in a pixel or rendering a simple sun disk adds dozens of instructions to the shader. If a pixel is occupied by several translucent shaders, calcuations are duplicated, am I right? Okay, similar AtmosphericFog material expression is even more heavy, so I feel I’m missing something. Many years ago I tried to make my own dynamic sky system, it was in pure GLSL, it also used LUTs, but it wrote the result into vertex colors, so I needed a good topology of the skydome, taking into account sun trajectory, but it was extremely cheap on hardware supporting OpenGL 2.1 and nothing newer (+ free fake lens rays out of interpolation artefacts:p). It would be good if Sky Atmosphere allowed something like that (tried VertexInterpolator, did not compile).
Anyway, I have another question. Is it possible to render the sky without super-bright sun disks/glows? I mean default rendering without sky materials. I tried using Scene Capture Cube with Atmosphere flag, and it’s almost okay, but sun/moon disks are imprinted into the cubemap as freaky distorted clumps of HDR pixels, making the map good for distant reflections but ruined as ambient. Rendering as sky mesh is hardly possible as it captures many unwanted objects. The workaround is (temporary) setting the light source angle 0, but maybe there is (or will be) something like Disable sun disk flag in AtmosphericFog?
I’ve asked for it a couple months ago. An overwrite for the sun disk scale under the “Art Direction” tab would definitely be a nice addition.
@The_Distiller @Alakuloinen 4.26 will come with a color per light to multiply the sun disk luminance with. So setting it to black will make the disk disappear.
I get a lot of noise from aerial perspective. Maybe it has something to do with the depth buffer? Only thing that I have found to help is increasing the sample rate, but I have to crank it pretty high (up to like 512). Maybe that is ok?
The atmosphere looks fantastic from the ground
@Blakeanator by default, when on the ground, the FastSkyLUT and AerialPerspectiveLUTs are used. When in space we switch to per pixel tracing (LUT not adapted to space view). 2 things to see here
- The high frequency pattern should not be visible and should go away with TAA. When you move the camera super fast, there is a camera cut happening (restarting TAA) so it is visible when moving fast in space. There is a cvar in 4.26 to change the camera cut threshold (r.CameraCutTranslationThreshold).
- Large circle become visible due to the way we adapt the sample count. It is more visible when the density of medium in the atmosphere is higher and very concentrated close ot the ground. Typical ray marching issue. The only way to fix that today is to pay the cost and increase the number of samples using r.SkyAtmosphere.SampleCountMax or r.SkyAtmosphere.DistanceToSampleCountMax. Or to hack/tweak the atmosphere when in space to make it have less particles near the ground (more uniformly distributed, increase the height distribution)
This is quickly discussed in https://docs.unrealengine.com/en-US/…nalinformation. We plan to add a discussion about space in the documentation soon.
Was sun & sky removed from 4.25, its not anywhere via search in the new Place actors, hence my scene is all blue without said actor, is the assumption to switch to Sky atmosphere instead ? Sure I can start to fix that, but my scene looked darn near perfect in 4.24 with Sun&Sky ,?
Sub&Sky is meant to stay and should be in 4.25. Have you enabled the plugin as explained there?