Feedback Physically Based Sky

View from the other side:

 

I'm encountering some weird "glittering" white lines coming from the Physically Based Sky. Basically they leak through a lightmapped solid enclosed room from certain angles. It's not from the SSR or some reflection probe.

 

The Sky is far from done.

A. Star pattern when dark.
B. At least a decent Sun texture representation.
C. The Moon should rise after the Sun sets.
C2. Ideally a proper moon system because the moon does not only come out in the night.
D. A nice Ambient Lighting preset during "night".

 

And to all this we must add many more things.

The performance is the great weak point of PBS. But there are more issues that have been discussed in this thread before.

It's a shame for years that it hasn't received any improvements... "really", not the last update that sets the number of rebounds at 3 instead of 8 and a few more things that practically don't really improve PBS.

Regards

 

I don't know about the Moon. There are a lot of games where action happens on other planets with more than one moon or with none. But yes, there should be an easiear way to handle several celestial bodies.

The main problem is that this sky is in the half-baked state with no further plans for improvement. Also It is not extensible, in any way, except modifying sources, which is always a bad idea. I could not write my own PBS, because we have no access to lightning and could not change light color depending on sun angle. Also we don't have an access to atmoshperic scattering or fog to make it consistent with a custom PBS. Lastly, we could not even provide custom scatterig tables to PBS. So we locked to use what was provided or fallback to 2010 tech using static skyboxes and doing other manual work.

 

Indeed, but let's cover the basics first, and then look at the many more things.

 

sorry, but if you think that "The performance is the great weak point of PBS. But there are more issues that have been discussed in this thread before." They are not the most basic things, I think we are going wrong...

I think currently one of the top priority things to fix on PBS is performance, atmospheric dispersion, and some things that have already been covered in this thread...
If we have a PBS that doesn't offer realistic "in-light" results and performance is an issue, it can't be used for AAA... And HDRP is mostly focused on AAA. So PBS becomes a practically useless resource in most uses for AAA.

Anyway... it's just my point of view.
Cheers

 

Other than possibly the last one these aren't strictly the PBS itself or atmosphere that it also is a part of but celestials, its possible that it may be out of scope of the "sky"

As a suggestion though, you can still achieve most of what you've asked.

There's a slot starmap on PBS ( can use planets too)
Alternatively you can add planet cookies if you have any atlas space.

You can add a second Directional light for the moon ( with shadows unchecked).

You can normalise movement between a starmap/sun/moon and sync it all in timeline.

Hope that gives you some incentive to explore more components that pair up with PBS to see if it can fulfill your needs

 

I released a new update for my improved PBS;
https://gitlab.com/bad-bug-busters/...mmit/f561c7d4e0ac7adf502ed5881a5aa44209a1d207

The spherical PBR fog got reworked and optimized.
It now applies to the sky itself too, which helps to mimic better multiple scattering and reduces banding artifacts.


The atmosphere within the planets shadow is no longer pitch black and still receives some light as it should.


Banding artifacts (especially at low sun angles) are now greatly reduced.

 

Thanks a lot for the suggestions. I will give them a try.

The thing is, I should not have to. All other engines offer this as standard so that we do not have to waste our time building missing features on a half baked system.

Being "out of scope" is not really a good reason for not providing something that should be part of the scope in the first place.

If that was a good reason, maybe all we should have for sky is a slot with the color blue.

There. Done Night was out of scope

 

No problem at all, I'm happy to help where possible.


Regarding scopes, I guess it all just depends on the scale you're looking at; global, macro, micro, that sort of thing.

Tme is a big factor of this, and it begs the question of whether you want partial systems in place now that will grow, or wait for a complete solution down the line and have nothing in between.

For the company large, regular and good feedback could provide insight into how resources could be better allocated.
-Many smaller parts focused on a wide variety of tooling (macro/micro)
-or just one big large step for some strategic benefit, like an acquisition or a complete solution (global)

The latter is the most costly and resource-intensive, especially in time.


I'm personally grateful I don't have to code the engine, am able to use it and have lots of different tools to work with, even if that means that the ceiling may not align with my expectations perfectly and may slow down my ideal workflow.

When unforeseen issues arise in a project, it can be rough, but I guess that's just where talking about them and sharing ideas and solutions can help or inspire ideas on how to solve those pains.

Just keep talking about it

 

Keeping tabs on this. Would be fantastic to have some of the improvements suggested by seb.

 

I think almost all of sebs issue tracker posts have been addressed now, which was pleasingly fast in response either by design or in review stages for 2022

One of the main changes was rejected by design I believe, hence sebs continued git efforts. Which is good to see something branch like that, offers choices. Definitely appreciate Seb and the teams input into it all in general.

 

This make me wondering would it be possible to separate the PBS sky though? this way maybe @SebLazyWizard sky can be installed as a custom sky inside vanilla HDRP?

 

I actually considered to make it into a custom sky, but since all functions to scatter/absorb light within an atmosphere are tightly bound to the PBSky's ID itself, I would loose access to those.
That would skip all manipulations which the PBS does to directional lights and requires some hackery to get that functionality back in.

I also would have to inject a custom type of spherical fog too.

In the end it's much more work (well mostly workarounds) to "just" implement a custom PBS, so editing the HDRP source directly skips all that hassle.

Extending HDRP beyond basic stuff isn't much fun.

 

i see, if that's the case then yeah that's too much

 

Hey, I kinda new to this, I would like to install all those fixes, do I need to compile the code from gitlab, or there's some kind of installing solution?

 

At first you have to move the hdrp package folder "com.unity.render-pipelines.high-definition" from "YourProject/Library/PackageCache/" to "YourProject/Packages/" in order to make it an editable package.
Then simply overwrite the package files with the ones I uploaded to GitLab https://gitlab.com/bad-bug-busters/unity/improved-pbs/-/tree/main/HDRP Package Files
That's it.

I'm about to port it over to 2022.2 and HDRP 14 btw.
Things like the flipped textures on the planet- and celestial bodies got finally fixed by Unity.

 

Oh thanks a lot. You're doing god's work, sometimes perfect feature consists of such unnoticed details (half-baked in this case).
Hell, i'd even throw some bucks for such things in the future, just to compensate hours and frustration

 

So there's the updated version for HDRP 14 (beta branch);
https://gitlab.com/bad-bug-busters/unity/improved-pbs/-/tree/beta

Once Unity 2022 LTS releases I'll merge it into the main branch ofc.

 

Night sky support and visual fidelity improvements were mentioned in the GDC 2023 roadmap talk.

Would be great to see some list of changes/improvements that are planned.

 

is the talk available online?

 

Yes -

 

Oh it was unlisted, Thanks for that

 

@SebLazyWizard Sry for ping, but do you have any idea how to rotate Space Rotation by the code? It seems there's no way to do that, little to no info about that anywhere.

I want my stars rotate along with the moon

 

Are you just looking for it's parameter?
There it is; https://docs.unity3d.com/Packages/c...ghDefinition_PhysicallyBasedSky_spaceRotation

 

You need to access the sky from your current volume profile... and the space rotation is a Vector3, no Quaternion.
Try this;

Code (CSharp):

1.     public VolumeProfile volumeProfile;
2.     public float rotationSpeed;
3.     PhysicallyBasedSky pbs;
4.  
5.     void Update()
6.     {
7.         if (volumeProfile.TryGet(out pbs))
8.         {
9.             pbs.spaceRotation.Override(new Vector3(0, 0, rotationSpeed * Time.deltaTime));
10.         }
11.     }

 

I'm having some issues with the PBS sky that sometimes gives me some headaches so I'll try to post couple of questions, hopefully someone will point me in the right direction. Note that I'm testing version 2023.2.0b4 so maybe some things are known and will be fixed.

1) I can't pinpoint what's the problem but sometimes I get this weird aliasing in volumetric clouds, what could the problem be? Note that "perceptual blend" setting is "OFF". Preatty default PBS sky with out of the box "cloudy" volumetric clouds preset.


2) When doing day/night cycles, as I disable shadows on Sun the "automatic moon phase" breaks giving me full moon. Which DOES make sense (no shadows, no dark part on the moon) but then how can I still mantain the correct moon phase when I have to switch off sun shadows to activate shadows on moon, based on time of day? I could animate/switch stuff but it feels somehow not a solid solution


Marco

 

Hey Marco, @RevC2

1. Aliasing in clouds. Those do look bigger than not using TAA in scene or game mode, but perhaps it's the cloud quality settings in general.

In the inspector you have quality settings, the three that come to mind are


- Temporal Accumulation Factor
- Num Primary Steps
- Num Light Steps

There is also the flare size and falloff properties on the directional light, usually I'll either have these at 0 or something like 32/256 respectfully, over the default 2/4.

I'm not sure on the internal workings of how the sun system changed in 2020/21, but it falls greatly into the Bloom post effect now.

As well as the primary
- diameter ( sun disk size)
- flare size ( affected by bloom )
- fall off ( affected by bloom)

You also have the additional components and postFX like lens flare & bloom.

I can imagine if you're using the default bloom and flare values with a 0.5 diameter sun the clouds obscure the volumetrics and bloom like behaviour when the sun is behind, so you'll witness the pixel like shape.

At least that's the alternative that I can think of if it isn't the clouds pixelating like that.

To debug, you could also force full resolution clouds in the HDRP asset, and observe if it's the same in play mode like that, I wouldn't keep that on for a real time project though but for debugging it can come in handy.

Another to double check if it is the clouds is the Volumetric Cloud view in the render pipeline debugger.

It'll show only the clouds in black environment so you should be able to better determine if it's lights or clouds related.

Hope that gives you some avenues to look until someone who knows more come along.


2. Weight blending states can help a little, though I have tried this in 2023 with the moon phase set up. Usually we have three volumes two controlling the typical post FX fade between day and night and the final fading in the shadows I believe, when it gets to the right "spot" to switch shadows without it being too obvious. At least I think that's what was done it's been a while since I've looked at that particular set up.

 

Any ideas how to keep vanilla lighting for clouds and fog while rotating planet with applied earth texture on it? (Yes, the lighting changes based on texture surface of the planet)

 

I'm guessing you're rotating the PBS planet?
To get an idea of what is happening there, the texture you're applying is rotating the Ambient light probe.

Typically you'd use a volume override with different settings, however you can do that with PBS because it's precomputed and will just spoke on any changes or weight Blends will snap.

Instead you could go down the Decoupling route, unity docs has a statement on it, but you'll create a static ambient ( part of the lighting environment), Decoupled from PBS (Visual environment)

Once the visual environment and Lighting environment are decoupled, you should be able to rotate your world and it only effect the visuals, and the lighting shouldn't recompute everytime. You may not need to even use PBS for the lighting environment then.

I can't say I've used this idea with PBS in mind, usually with HDRIs but it's worth experimenting.

 

Wow. Looks really nice. Hopefully official can bring it to URP too soon and support mobile platform especially Android. Of course it won't get exactly same quality like HDRP when it's at mobile so it will need to have tweakable scalable settings to scale across all URP supported platforms.

 

Great to hear that. 2023 LTS means we can expect these improvements to be added to 2023.3 at some point. Right?

 

@adrien-de-tocqueville

Great. Do you plan any updates regarding sun angles below 0 degrees (civil, nautical and astronomical twilight)? Or maybe there were already some improvements in 2023.1 or 2023.2 related to this.

Thanks.

 

- realtime update of atmosphere parameters

Does this also mean that PBS isn't solely 100% precomputed now we can actually change values a runtime without re-computing the whole stack? or are these specifically new parameters?

 

Any chance for teaser video for these? highly interested on these updates since it's regarding performance

 

Same. I'll check the github every now and again since commits often land there before their corresponding alphas come out.

 

Does that mean rotating sun in runtime eats less resources?

 

This is wonderful Adrien, very happy to hear.

 

Oh it's probably updating shadows then?

 

Great progress so far!
I assume the PBSky got rewritten from scratch right?
It looks quite similar to Hillaire's implementation, I bet it's based on that.

 

So I just tested the new sky and I have to say it's a great improvement compared to the earlier implementation, especially the better multiple scattering, ozone layer and aerial perspective.
Great work so far!

However the banding at twilight is still very visible unfortunately;



Are there any plans on improving it?

 

I also just did a bit of testing on the latest alpha, and can attest that this is much, much better than before, the atmospheric scattering really completes the look of outdoor scenes. One problem I feel the need to mention however, is the fact that the ambient probe as a whole seems to but pretty buggy in this version. Volumetric clouds are especially visible, and setting the ambient mode to static seems to clear the ambient probe entirely, even for scene objects.

The clouds also seem to be missing atmospheric scattering. (Applies to cloud layers as well)

 

@adrien-de-tocqueville

First of all it's great to see the new sky implementation and improvements!

Both volumetric clouds and cloud layer are affected by atmospheric scattering. Anyway there is some bug with volumetric fog and volumetric clouds/cloud layer in 2023.3.0a14. I'm trying to reproduce it but for a report but I can't find what triggers it in a fresh project. So now I have two empty projects and the bug is only visible in the first one.

Volumetric clouds and cloud layer are washed out/very bright, like there is no self shadowing/lighting calculation when the volumetric fog is active. (first image)

Clouds are still visible even though the sun no longer illuminates them because it is too low or when it is completely off. (seconds image)

It's probably the same problem as on your screenshot.

As I've mentioned before, I don't know what triggered this issue. I have two new projects created for testing this alpha version, but this problem exists in only one of them.