I’ve just downloaded 4.24 preview as I was very excited about the new physically based sun/sky/atmosphere model but so far I am very disappointed.
I don’t seem to be able to reach any exposure setup where the new sky model becomes anything else than pitch white
When I lower directional light intensity to acceptable range, the sky becomes visible but any ground below horizon is completely pitch black. Lower hemisphere settings of skylight have no effect on that whatsoever.
When I read that the new model is more physically based and at the same time easier to setup, I was very excited to see something like very popular Hosek & Wilkie physical atmosphere model. That is unfortunately not the case.
Instead, the implemented model contains excessive amount of granular controls populated with quite arbitrary values which have been somewhat eyeballed to get close to earths atmosphere model. This is definitely not going to be a pleasure to work with.
EDIT:
5. Such a crucial functionality as a much better sky and atmosphere model should definitely not be hidden away as an obscure plugin which is not even enabled by default. In fact, it should be possibility to use the new sun and sky model even without the bulky positioner blueprint, and I’d go as far as to say it should replace current, cartoony sky model which is by default created in empty new levels.
I need to give you some background on this prior to answer individual points below.
The SunSky positionner is a plugin that was added in Unreal in 4.21. It lacked of proper shading technology (physical sky). In this release, this has been added to it in the form of extra components that can be used individually. The main use case is for Architecture where maintaining a notion of physically correct values for lighting, camera EVs and material parameters is a recommended practice.
From the comments i read below it seems that you are starting from a project template that isn’t right for that type of use case and hit all the roadblocks that are solved by the Architectural Visualization project templates. I’ll get to that below.
In project settings, enable the following options:
Enable Extend default luminance range in Auto Exposure = true
Apply Pre-Exposure before writing to scene color = true
That will allow lights to go from low to very high ranges.
The lower part of the sky hemisphere is usually done by an exponential height fog that should be added separately to the scene which isn’t part of the Sun Positioner plugin.
This is not the Hosek & Wilkie but still physical. Its using a derived version of the Bruneton sky which has several advantages over the Hosek & Wilkie. Its not something that was defined arbitrarily as you imply. The parameters are different (and more extensive) but it doesn’t means is physically incorrect because of that.
We have hidden the Sun Positionner plugin in Unreal by default but enabled it when using the project templates dedicated to Architectural Vis. However you don’t need to use that plugin to use the new Sky shader. Just add a Sky Atmosphere actor from the Visual Effects category and you have it.
This is very confusing. Let’s say I want to use it to light an interior. If there’s only half the environment, then the illumination is just not right. Ceiling receives no lighting. Exponential height fog doesn’t seem like a right solution. Can it be as efficiently sampled as regular solid color environment? Also, why is there a ground albedo color swatch then? There’s a difference between simulating sky model at undefined altitude and providing some way to define ground albedo as an “average color” of the surrounding environment, such as gray for city or green for forests. Putting a giant plane below scene is less efficient in terms of both prebaked and realtime light transport, and fog probably too.
As for the templates, yes, I am not starting from any archviz templates. I want to use this for games primarily, not for archviz. Archviz templates mostly add just junk for beginners. That still doesn’t mean something like setting up physical sky should be a multi step process which involves turning on some obscure knobs in the project settings. It’s not a hard thing to set up in unity, it should not be a hard thing to set up in Unreal
Hi, just a reminder you still haven’t answered my question about new Sky model ground color. The “use exponential fog” is not really a satisfying answer, as it opens a big bag of more questions. There are several issues:
The new sky model is advertised as a complete sky model solution, yet the default SunSky blueprint comes without any fog component inside, resulting in black area below horizon, resulting in unacceptable results when lighting most of the scenarios. Therefore it does not work out of the box.
Successful use of the new sky model requires knowledge of many obscure knobs which are configured to not work out of the box. Aside those mentioned by you (Enable Extend default luminance range in Auto Exposure = true and Apply Pre-Exposure before writing to scene color = true), there seems to be also yet another knob called “Support Sky atmosphere affecting height fog”, which requires lengthy, project-wide shader recomplie. This is a ridiculous amount of steps necessary to take to get something as simple as a complete sun & sky model going, compared to traditional DCCs. It should not require such obscure knowledge. This is definitely not “easier to set up” as advertised.
Exponential height fog is a fog model, not a solid surface approximation mode. When introduced to scene, it causes excessive fogging around the sun disc while doing absolutely nothing to help you specifically define color of the solid surface below horizon. Yes, it does make it non-black, but no, it does not allow you to define specific color. You can push some settings to the extremes to get close, but that also severely affects the areas above the horizon, radically changing the look of the sky. “Use exponential height fog” is NOT an answer to the issue of the current model’s inability to specify approximate average color of the solid planet surface.
Furthermore, even if the Exponential Height Fog worked as a means of specifying the ground color, it would still be way more difficult to set up and use, because now the complete sky atmospheric model would be controlled by over 40 interdependent parameters fractured between two separate objects/components.
There is just no possible chance anyone who does not do atmospheric optical properties research for living could make proper use of such a fragmented set of parameters.
For comparison, this is a set of parameters for physical sky atmosphere model used in an average offline renderer:
Sure it’s overly simplistic for use in a game engine as game folks will want to simulate other planets than earth, but still, current Unreal’s model goes far into opposite extreme.
All in all, while the current model seems to do a lot, it fails in terms of usability, and I will be very surprised if users turn out to be able to use it properly. At this point it’s so confusing that while users will be able to take advantage of it, it will rarely be in the way it was designed for, and quality of their artwork will significantly suffer from it. I am already preparing for the heaps of UE4 archviz interiors lit by sky model completely missing any illumination on the ceiling, and users creating “why doesn’t it look like Vray” threads…
Anyway, to provide solutions instead of just complaining, it would be enough if already present “Ground Albedo” parameter in the Sky Atmosphere component defined (perhaps optionally) solid color below horizon instead of pitch black. This would remove necessity to introduce any other atmosphere objects in the scene with it’s own set of complicated parameters.
Yes, you should please. This is thread specifically about a new 4.24 feature of a new physically based sky atmosphere model. Yes, it has UI/usability issues, but ones specific to this feature, not those related to general UE4 UI/usability.
There is a project setting that enables Height Fog to be affected by the sky atmosphere. I can’t recall the exact name, but if you search “Sky Atmosphere” you’ll find it easily.
Then in the Sky Atmosphere component’s properties, use the “height fog contribution” property to scale its effect.
the component uses world 0 as its sea level, so if you had a 800km ground radius and a 1km static mesh sphere, then you have to move the mesh down by -800km and scale it up by 1,600 km to match radius.
There does seem to be a obvious POP when it switches to fast distant sky rendering from aerial/ ground view. when its in the ground view the atmo border is very obvious. You can use "r.SkyAtmosphere.AerialPerspectiveLUT.Depth " with some big number like 256 to blend it better, the number you use will depend on your planet size
Aerial samples seem to get distributed based on atmo height and Rayleigh Exponential distribution, greater the height the more noticeable the depth stepping "r.SkyAtmosphere.AerialPerspectiveLUT.DepthResolution " will increase the res.
[USER=“4894”]Tim Hobson[/USER] Even with the project setting checked, it doesn’t seem to be working. @Rareden Thanks for the tips, the planet is centered now.
Yeah apparently the new sky isn’t really integrated with close in fog/volumetric scattering yet, which seems to be targeted for 4.25. So I wouldn’t count on getting the new sky to totally work for a bit.
I’m posting on behalf of Sebastien Hillaire since he’s had some account trouble we’re sorting out. He’s our rendering engineer who worked on the SkyAtmosphere system in 4.24.
**"**Hi,
Thanks for all the feedback, it is great to see dedicated artists like you all trying the SkyAtmosphere component.
When the documentation will be available, the parameterisation and a few questions I see here should be clarified. So take it easy in the meantime.
Still, here are some details:
The black area below the horizon: that is not for the sky to simulate/render/fill up. You should put your world/landscape there, use SkyLight bottom color, or control it via skydome shader.
Some steps such as “Support XXX” and “Support YYY” are required for performance and for not affecting other projects not using this component (for instance: transparent need to sample the aerial perspective when enabled or to get cheaper height fog).
Setup/Use of the properties: all the exposed parameters are required for full control and fine-tuning (and simply to represent an atmosphere). There is a TODO to provide a small blueprint simplified controller similar to Hosek/Wilkie but no ETA.
HeightFog: once enabled you need to set the color on height fog (in-scattered and color) to 0 because those are additive and can hide the sun contribution (we keep them here in case you want to tweak things). The sun adds its contribution on top of that. Otherwise, Height fog is not required, you should be able to play with the Mie scattering component and get the same result even better because it will be react to sun light more correctly (to some extent as it will still be limited by the resolution of the aerial perspective LUT). Your choice.
Planet rendering and fog pop: yes because by default we use special LUTs that are optimised to render a view on ground level (typical use case). For Game/level using the ground to space view transitions with a planet mesh, you want to disable “r.SkyAtmosphere.AerialPerspectiveLUT.FastApplyOnOpaque 0” (and maybe r.SkyAtmosphere.FastSkyLUT). Then more expensive raymarching will be used for the sky and aerial perspective on opaque, then the transition should be smooth. Sample count is then controlled via r.SkyAtmosphere.XX. Please note that this path not using LUTs has not shipped in any application yet.
As of today: limited to only one planet that is not movable
This is an inadequate answer unfortunately. Placing geometry large enough to not cause any gap between it at the horizon line can result in level issues and precision errors. Such geometry would have to be way too giant to cover distance approximating infinity. Specifying color below the horizon using SkyLight bottom color is also inadequate for 2 reasons:
1, This will completely override anything below the horizon, so if there is any kind of height fog atmosphere present, which is affected by scene lighting, such contribution will be missing from the SkyLight capture below the horizon.
2, This change will only affect illumination from the SkyLight, not actual directly visible representation of the Sky atmosphere.
Almost all the Sky atmosphere environment models in both realtime (Unity, Godot) and offline (Vray, Corona, Arnold) renderers have non-black representation of the color under the horizon. It’s that way for a reason.
First, thank you Tim Hobson and Sebastien Hillaire for greatly improving the environment options available on UE4. I’ve personal have been using linear workflows, HDRIs, and advanced exposure controls in architectural animations for about 15 years in 3ds Max and I completely understand the challenges. What you’ve done in 4.24 is a huge improvement and it appears to only be the beginning.
Second, a lot of people are complaining about black bottoms under the horizon. Welcome to what happens when you have zero geometry in empty space. This is very common especially with professional HDRI scenes without geometry. I’ve personally create landscapes that expended out to 100 miles of real world accurate geometry. Or created infinity oceans. Although I haven’t used the new features allowing you to view your site from space, as the new SunSky system appears to allow you to do, but I imagine the best solutions are having geometry at the edge of your scene to fill in the black area. But what they have done so far deserves a thanks, not criticism.
Exactly what I worried was going to happen happened. The new atmosphere model made it all the way to the final 4.24 release without ability to specify below horizon color, despite several preview releases. I’d expect this kind of development from Autodesk, but definitely not Epic
