Feedback Physically Based Sky

hard to believe that about the previous sky because it was ridiculously simple.

Perhaps someone convinced someone that it is so.

As for "the current situation", I don't want to get into it.
This thread about the sky and production needs of the majority of the users regarding this feature..

I will just repeat what must be repeated:
For busy people, soon is maximum 2-3 months.
Not 2-3 years.

In two years most serious developers have turned in at least 3 medium scale projects. Or at least 8 small ones. And having to do that while the competition can spit out things faster and/or better is not really a joke.

Someone saying "you do not have to use Unity" is amateurish at least.
If not idiotic.

Studios have invested a lot of time and money to hire and train people and create specific pipelines and in this competitive world most small studios can't afford investing either to learn a new engine and realign their pipeline. Thinking or saying so is like spitting at your users. Huge disrespect thrown around in a multitude of ways.

 

So with HDRP now "out of preview", whatever that means these days, there are still several issues with the PBS.

1) Day/night cycles with realistic light intensities for both the sun and moon are still not accomplishable without graphical errors. At first we still have the banding artifacts on the atmosphere layers at low light angles. And then there's the automatic exposure (well it becomes visible with it) which just can't handle the extreme differences in light intensity before sunrise and after sunset, which results in an over-exposed bright circle (towards the sun position) on an otherwise dark night sky.

Case 1225204

2) Fog isn't taking the spherical planet into account and blocks any sun/moon light if it's altitude is below zero. High altitude objects/surfaces like clouds or mountains are not illuminated at all even if you can clearly see the sun from up there. It works as expected if fog is turned off.
Case 1225209

3) The celestial body of a directional light seems to be excluded from bloom, instead you added the "Flare" option which in my opinion looks way worse than real bloom and has nothing to do with physical based rendering at all.

 

I also noticed the banding for new sky shader. It looks really ugly like you take a screenshot and decreased the color depth to 256 bit without checkerboard dithering. Why are they no smooth transition between the colors?
For a "physically based sky" this looks not reaslistic at all and it will mostly destroy the feeling of any game trying to convince the photorealistic look.

 

I like the Physically Based Sky look. However I can't seem to move the Sun through the sky without massive lag (terrible performance). Is there a different or default way of moving the Sun (i.e. day/night cycles) with it?

 

You shouldn't update it's position every frame, but do it periodically.
Depending on how long a day cycle takes you can update it like every 10 seconds or so.
I really needed a "step-free" transition and ended up with an update once every second with a day/night cycle taking real 24 hours.
At this rate you can't see any difference to a per-frame update.
But again the needed update rate really depends on your specific use case.

 

Even if I put a 10 second timer on it, I get a massive lag spike every 10 seconds. I tried decreasing the increment on the x axis transform position of the Sun, and I can still notice a large performance hit in-game.

I think I might have something checked in my HDRP settings that maybe I'm not supposed to have checked. The profiler keeps telling me it has something to do with the UpdateSkyEnvironment script that Unity is using and perhaps CubeMaps (or updating of the sky cubemap). I'm using Procedural Sky right now though......I didn't think I was even using CubeMaps at all.

Still can't figure it out.

 

I assume the refresh of the cubemap is very expensive, like updating a realtime reflection probe because the sky shader has a setting called bounces and therefore updating every frame a graphical object that has to calculate 10 bounces seems very heavy. So you may increase the performence if you do not set the bounce count to high. If not it seems like a huge design flow for a realtime engine. Other games and engines can update too in a tight frame budget, and they even have to calculate the clouds.

 

Bounces does not recompute on changing light direction.

 

Hi, okay I've been trying to get the Physically based sky to work on a real spherical planet, for around 4 days now, for the life of me I can't get the blue tinting Aerosol to work, like in SebLazyWizard video, the tutorials say it even takes in effect mountains and objects, but I'm seeing nothing, no atmosphere effect at all, and it's not like there are millions of settings, it's set to how all the limited examples say to set it. Can someone who has this working provide correct environment settings for this to work? Thanks.

Unity 2019.3.5f1
HDRP 7.1.8

 

There is no atmospheric scattering fog atm in PBS.

 

No the manual states that PBS has Mie Scattering, started by SeblazyWizard, and his video demonstrates this atmospheric scattering effect?
From the unity manual:

The Physically Based Sky’s atmosphere is composed of two types of particles:

• Colored air particles with Rayleigh scattering.
• Monochromatic aerosol particles with anisotropic Mie scattering. You can use aerosols to model pollution, height fog, or mist

 

Atmospheric scattering consist from two parts: sky color and fog for opaque and transparent objects. You still need to generate precomputed tables for Rayleigh and Mie scattering to get a physically correct color of the sky. The same tables could be used for computing fog color and opacity but currently it is not implemented in HDRP.

 

Since you can only have directional shadows from one light source at a time, what's the recommended way to handle a day/night cycle with sun and moon? My first thought is to disable the sun shadows when it dips below the horizon and enable moon shadows, but unless the moon is directly opposite the sun (also at the horizon) there's going to be a sudden pop in of moon shadows.

 

You can just tweak the shadow dimmer setting of the light during the day/night transition.
But with real sun and moon light intensities you dont really need to do that, because even if the sun is already below the horizon the skylight intensity is still way higher than the moon light, so moon shadows aren't visible for a good amount of time after sunset.
I use light intensities and colors of the sun and moon before their light hits the atmosphere (sun: 128000 lux, moon: 0.5 lux), the atmospheric scattering of the PBS itself controls the final light intensity and color.

 

I don't have Sky and Fog volume in the hiearchy but sky is still there.
Should the sky not exist without Sky and fog volume?

 

HDRP uses the default volume settings if there are no active volume overrides.

So back to topic.
I recently watched a video of Unreals new sky atmosphere system, which is basically the PBS, but way ahead in terms of features and visual quality (no banding artifacts).

Especially the volumetric cloud system looks quite promising and I'm wondering when the planned cloud-system for the PBS might appear.
Is there any news on that? We've been waiting for so long...

 

@SebLazyWizard I am watching Graphics github page for a while and I see they have already started implementing cloud layer.
https://github.com/Unity-Technologies/Graphics/tree/HDRP/cloud-layer

 

and there is new realistic water shader but I don't know if for 7.4

 

I made a post about the pull request for water that was in progress before the SRP repo moved to Graphics and all the pull requests were deleted. I don't know if the guy who was working on it is still around though, maybe @SebLagarde will know more?

 

there is a pull request about clouds
https://github.com/Unity-Technologies/Graphics/pull/461
But clouds seems really weak isnt it? I was expecting volumetric clouds

 

It is just a texture.

 

Well, while there is no official build-in water asset for HDRP, I say you can make your own with Shadergraph and Custom Passes. Of course this requires some fundamental understanding of shaders and SRP and general lighting of water.
But you know, water is mostly just a plane with really dense vertex or tesselated. Put a good wave normal map and a reflection cubemap on it plus some depth fog. Foams are just depth intersections with a seperate foam texture. I think an average developer can make a decent water with Unity.

For the waves, either implement vertex animation with Gerstner waves in the shader or with a C# job. There are a lot of examples of vertex manipulation with C# jobs. Of course you can implement it with a normal script, but for heavy vertex manipulation, I recommended doing the work on another CPU core (C# jobs multithreading).

Also iamarugin is right. It often looks very complicated but it's mostly just a texture generated with a mix of noise algorithms.

 

The fact that the Physically Based Sky renders completely black when the camera goes under the horizon has a consequence also on Planar Reflection Probes. I spent all evening trying to figure out why the probe breaks when my camera goes high enough. Turns out the culprit was the Sky volume, must be something to do with how the Planar Reflection Probe's camera offsets according to the player's location. Had to do a stupid hack of lowering the sea level in the Sky asset to get around it for now.

 

Are we going to get PBS like this ever?

Especially when most of the unity features are already lacking the stability needed to be actually reliable for production

 

Wow, that image on the pull request really looks like something from the 90s "GPU gems":



I made my own clouds using a few noise layers a while back when PBS came out: https://twitter.com/Nothke/status/1188997624680108033. It is only a surface effect tho, "painted" on the ground, because I only needed views from orbit, it's not 3d. I was hoping Unity would come up with a better solution in the mean time so didn't bother to improve. Well, I'm prepared now to be disappointed.

The sun disc also boggles me. It's called PBs but the sun disc is the most un-PB thing ever. It has a simple un-physical fading. Why is it LDR? It seems to peak at at the same intensity as the sky. Increasing sky exposure increases the sun brightness proportionally. Instead, it should rely on physically correct bloom for the "fade".

 

I've been wondering about sun brightness too. It seems the specular reflections from the sun are brighter than the sun disc itself, with bloom turned on I will get a lot of blooming on reflections but none on the actual sun disk itself.

 

Yes, sun disk feels not right.

 

It worked fine in previous versions of the pbs, but then they introduced the "Flare" feature which kinda replaced real boom on the directional light... And it looks totally wrong in a physically based manner ofc, no idea why they did this.

 

How do you change the position of the atmosphere to make it work with floating origin?

sky.planetCenterPosition = new Vector3Parameter(planetPos);
doesn't appear to do anything but change the numbers shown in the editor.

 

Is the camera dropping to a negative y value disabling physical sky a bug ?

 

No, it was intended. Decrease the planet radius to the lowest point, where player could be.

 

sorry I’m not following, I’m new to HDRP

 

No. Just make sure your camera never goes below the ground. The "ground height" is the planet radius of PBS. So, either reduce the planet radius, or lower the planet position Y, or raise the level in scene.

Like this:

Code (CSharp):

1. public Volume volume; // Assign your volume here
2. PhysicallyBasedSky pbs;
3.  
4. private void Start()
5. {
6.     profile = volume.profile; // makes a copy of the profile, so we don't edit the "asset"
7.     profile.TryGet(out pbs);
8.  
9.     // this "ticks the box", next to the value, making it changeable:
10.     pbs.planetCenterPosition.overrideState = true;
11. }
12.  
13. void Update()
14. {
15.     pbs.planetCenterPosition.value = -yourCartesianPosition;
16.  
17.     // or (in which case you don't need to explicitly overrideState in Start):
18.     pbs.planetCenterPosition.Override(-yourCartesianPosition);
19. }

 

What if I have an actual spherical planet at origin? Moving the whole planet up is not an option at this point

 

If the planet is supposed to be at origin, then you will need to move your PBS planetCenterPosition relative to the camera in update

pbs.planetCenterPosition.value = -cameraPosition * scale;

. You'll also probably want to block the camera from going inside the planet.

 

Volumetric Clouds: https://github.com/Unity-Technologies/Graphics/pull/3199
You can test it out from github. It's coming in 2021.2, along with Cloud Layer Volume Override

 

How can I activate the Volumetric Cloud volume override in 2021.2a8? I can only see the Cloud Layer volume override.

 

It's not available in the package manager version atm, only in the git hub repo;
https://github.com/Unity-Technologies/Graphics

 

Ah ok, thank you. I hope Unity migrate it soon.

 

Can I download that using Package manager?

 

How did you add the clouds visible in the sky?

 

It was just a flattened half-dome mesh with a special shader applied to it, however I'm not using it any longer as this solution was quite limited.
Soft cloud shadows were impossible (HDRP still doesn't support semi-transparent shadows) and simulating correct light scattering within the clouds using an unlit shader was a tough task since receiving matching light data (especially in combination with the PBSky) was a big hassle.

 

Hi everyone!!
Does anyone know where I can find a list of changes / fixes / improvements between versions of PhysicsBasedSky?

I have looked at the docs for the different versions of HDRP, but there is little or nothing coming.

Greetings

 

Anyone who knows where to look or if there is a document like the one I mention?
Greetings

 

Well you could track it's related commits at github:
https://github.com/Unity-Technologi...igh-definition/Runtime/Sky/PhysicallyBasedSky
But unfortunately there's not much to explore recently...

The PBS still suffers from poor/glitchy rendering at twilight (dusk/dawn) and it has been like that since it's very first release.
That prevents us from implementing proper day/night cycles.
I guess it's essential to implement an ozon layer to get the lighting right, as described here; (starting from 3.4)
https://media.contentapi.ea.com/content/dam/eacom/frostbite/files/s2016_pbs_frostbite_sky_clouds.pdf

I would also like to see render texture support for the surface texture of directional lights, this way we could implement dynamic moon phases for example. (atm I have to pre-render different moon phases and switch their textures at runtime)

 

atmospheric and mie scattering needs to be implemented in PBS or refactor

 

Not sure what you mean by that, since rayleigh and mie scattering are the core principles of the PBS.

 

In the latest versions of HDRP 11 and 12 I see a very important loss of performance in the twilight and sunrises ... and I do not know why it occurs.

Unity starts a lot of new features and they always leave them in the middle, with a lot of bugs ... or it takes years and years to get those features ready for production.

It's unfortunate about Unity for a few years

 

How the relation of sunlight intensity and physically based sky is designed? Do I need to manipulate the sunlight intesity manually based on its angle or does the sky component adjust it automatically so one fixed value should be used (for example 120,000 lux for realistic values)?

EDIT: just tested it once again properly and looks like the intensity is adjusted automatically.