uSkyPro – Precomputed Atmospheric Scattering [2.0 Beta]

It really depends on how you really want the earth looks like when your camera is out of the atmosphere (in space or orbit). By adding extra precomputed space altitude data is not a problem, the sky it-self will render from ground surface to space, however the current clouds 2D (or later cloud 3D) system won't support render in high-altitude. Thus I believe it is still hard to do continuous camera fly from ground surface space with clouds at the moment.

Fading between uSky with other asset that may work or may not i'm not sure about that. Of course it is always easier if you just use some sort of cut-scene to render the earth with other spherical clouds map when camera close to orbit.

 

I'm not super concerned about the cloud system, as I think I've got a good way to do those. Having a more slots in the precomputed altitude data would be very welcome. If we could maybe figure out how to get it to go to black smoothly and completely, I could use another asset in orbit itself, with spherical clouds.

I know it's hard, but that's why I want to do it!! ;-) cut-scenes are for wimps!

 

Hi @Luckymouse ,

There's a bug in the uSkyAtmosphericScattering.cs, when you enable and disable the uSkyAtmosphericScattering component, it becomes more and more expensive each time you do it.

You forgot to remove the command buffer before disposing the m_occlusionCmdAfterShadows and m_occlusionCmdBeforeScreen. (method EnsureHookedLightSource(Light light) )

 

Ok, thanks for report. I gonna check and fix it.

 

Hey Luckymouse

In the scene view i selected the wireframe mode and found a large amount of quads surrounding the scene. i guessing at has something to do with rendering stars or something like that. But, is there a way to disable them if you dont need em?

It is about 16K verts if im not mistaken.

 

Yes, It is star field quads (billboards). To remove it you can edit the uSkyPro script, Comment out the Star.InitializeStarfield() function call in Awake() and render call in Update() function (without star mesh it won't render it anyway).

It has total 4k stars in full spherical shape. This numbers are less than half of the about total 9110 stars that naked human eyes can see on the real sky. Every star content 4 vertices per quad, so total are 16k vertices. Normally you will only see the upper half of the mesh above the horizon level on the sky, thus renders only half of them. I predefined only generate the 1k stars for mobile, you can modify it in the uStar script the total number of star to be generated.

 

Great thx

 

@dnishimura in uSkyAtmosphericScattering.cs adds the RemoveAllCommandBuffers code as below that will fix the bug.

Code (CSharp):

1. void OnDisable(){
2.     instance = null;
3.     activeLight.RemoveAllCommandBuffers ();
4. }

I'm gonna update that in next version.

 

@Luckymouse theres a bug at the uSkyPro Clouds2D shader. When enabling cloud rotation, the direction of the light scattering effect is not being updated by the rotation.

uSkyProClouds2D.cs, Line 107:

Code (CSharp):

1. // switching between the sun and moon direction, avoids the poping issue between lights
2.             float3 dir = lerp (_SunDirSize.xyz, _MoonDirSize.xyz, saturate(_uSkyNightParams.y ));
3.            
4.             // inverse rotation to correct the light direction from vertex animation
5.             OUT.lightDir= RotateAroundYInDegrees(dir, -offsetValue);

You're updating the output value of light direction, and keeping the internal direction unchanged. What I did was update the direction and pass it to the output value.

Code (CSharp):

1. // switching between the sun and moon direction, avoids the poping issue between lights
2.             float3 dir = lerp (_SunDirSize.xyz, _MoonDirSize.xyz, saturate(_uSkyNightParams.y ));
3.             dir = RotateAroundYInDegrees(dir, -offsetValue);
4.  
5.             // inverse rotation to correct the light direction from vertex animation
6.             OUT.lightDir = dir;

As far as I can tell, it fixes the problem. Don't know if causes any weird behaviours anywhere else.

 

You are right, I fixed the scattering direction last version, but I forget to pass the new value to other function for shading direction. The next function should be using the "OUT.lightDir" instead of "dir"(old value). like this:

Code (CSharp):

1. OUT.toSun = mul(rotation, OUT.lightDir).xy * _StepSize ;

Your fix is doing same thing, it will work too. Thanks for report again.
I will add up this fix and submit a new update.

 

Hello, first let me thank you for this amazing asset, worth every cent!

I found a bug in uSky 1.4.2 (Unity 5.5.0f3):

The stars do not scale with the camera's far plane so if the far plane is too small they will stop rendering and if it's too big the stars will draw on top of objects that are far away.

The clouds however, scale properly.

For now I just multiplied the _StarRotationMatrix to fix it for my project.

Thanks.

 

I also would like to be able to control the scale of the stars. I hit this issue this week. The size of the stars effect the scale of the bloom, etc etc...

 

Yes, current stars has a fix distance of 990 from camera in uStars.cs script. I can modify it and make it scale with camera far clip plane.

I'm not sure what is the stars issue with the bloom, can you post some screenshot? If the star is too bright that you can tune down the intensity, right?
If you want to change the star size, you can change starSizeScale (Line# 9) in the uStars.cs script.

 

I used several time Usky in the past project... I updated to Unity 5.5 and this time I cannot figure out how to fix this:
I put prefab SkyPro and I can see correctly day sky in the scene view... In the game, however, I always see night, even if is day (the light work correctly, the sky is always black with stars, clouds are right). Cannot make it work... Help!

 

Upon updating Unity to 5.5, clouds appear in front of geometry and the stars are not visible in Game View. Changing Render queue values didn't solve the issue. Please advise.

 

@ guidoponzini and Karthik7Nike
As far as I tested the current uSkyPro version on 5.5, I can not find the issue that you guys reported.

Regarding the Unity 5.5 issue, Please send me your unity project via PM with uSkyPro installed and a simple scene file that has the issue with.
Please also give me some following info:
1) Which OS platform you are using? (Windows7, 10 or OSX )
2) Unity editor version? (assume released version 5.5.0f3)
3) Which target build platform of your project? (Standalone Windows, WebGL...?)
4) uSkyPro version? (1.4.2 assume you are using the latest version)

 

1) Windows 7
2) 5.5.0f3
3) Standalone Windows
4) Using non-Pro files: DistanceCloud, USkyManager, uSkyFog, uSkyLight

 

Currently only uSkyPro supports Unity 5.5.

 

I'm a little confused on your pricing - if we purchase the beta for $30 we will have to pay an additional $10 for the update to the full 2.0 (total of $40)? Thanks!

 

Yes, with $10 upgrade for current uSky user, so total is $40. The new release price $50 for new user later on.

 

Hello, I recently updated to the latest usky(1.4.2), and sadly its full of bugs. The most irritating one being the screen filter fliped. Check this image, my cars tail lights are where the sun is supposed to be. Its impossible to get the settings right
I took the prefab camera and sky component from "uSkyPro Atmospheric Scattering" scene.

Edit:
I managed to get somewhat working settings to the system. But the "fliped" issue remains and so does the dulling filter, which imo seems unrealistic. It comes to effect after the scattering is enabled.

Here is a small build to demonstrate the "fliped" bug. As soon as you hit brakes the brake light appears near the sun. You need a Xbox 36 gamepad.
https://www.sendspace.com/file/laz2h6

Input:
Gas - RT
Brake - LT
Steer - Left Stick
Handbrake - A
Shift Up - RB
Shift Down - LB

To show some telemetry data, press shift+"numbers"

Once you fix those 2 issues, this asset seems to be complete for my needs.
Happy holidays!

 

@Ravel, I don't have gamepad, so I only tested your demo from the startup scene.
As far as I know the flipped issue is from the new lightshaft image effect, i'm going to investigate it.
However I believe if you just turn off the anti-aliasing feature in quality setting, should fix the flipped issue.
If you are using deferred path rendering, recommend you use the image effect base anti-aliasing.

All the transparent material should be working as out the box from the unity standard material. Are you using custom shader? Make sure it is either using Cutout transparent, or enable Z-depth write for image effect.
Are your transparent materials work with unity GlobalFog image effect too?

 

Does the Usky pro support colored fog (that changes with ambient and camera position) in deferred rendering? I just purchased it but I can't seem to get fog to work.

 

I'm seeing an issue where skybox is no longer rendering correctly on the Wii U. It looks fine in the editor play mode, but on the Wii U I get a very strange issue where the entire sky is empty except I can see a seam from horizon to zenith and a kind of zig-zag pattern of cloud texturing up the seam. When I get a chance I'll grab a screen shot and post it, but I wanted to give you a heads up. This worked fine in previous versions.

 

Right now the day time atmospheric fog is based on physical skybox color, can't apply custom colour to it. I have been thinking that I may change feature of the color parameter in Precomputed Params, so it will simply multiply the color instead of shifting the wavelengths. However the night sky is more flexable to change the color, it is not physically based and just a color gradients.
I think at the moment there are only alternative is using the FogGradient component instead, that can change any color fog you want in the day/night cycle.

When you said last version work, do you mean 1.4.0? If so, I do not think I changed any codes related to the skybox.
Just wonder if the issue caused by the different unity version? like it was woking fine in 5.4.X, not in 5.5 for Wii U.
Other then mostly recently new feature I added in the version was LightShaft, not sure if that causes the issue.

If possible please lets me know some more detail what will work, such as which Unity Editor and uSkyPro version, and what is not working. Screenshot always helps too.
If you need the older version of uSkyPro for testing, just let me know I will send you that via PM.

 

By latest version I mean 1.4.2. I don't actually know which previous version worked. The last one for sure that I remember working was right before you removed the old 1.x uSky from the package. I'm using Unity 5.4.2f1. When I get a chance I can do some backwards version testing. If I need an older version I'll PM you.

 

And I am perfectly happy to use the Fog Gradient component but I need it to work in the deferred rendering path. Currently according to documentation it will only work in forward rendering. Any chance you could make a deferred rendering Fog Gradient component as well?

 

I see, I tracked down the ChangeLog that before I removed the uSky 1.X is version 1.3.0. I will investigate what I did between these two version, see if I can find some glue.

That is tricky part of the FogGradient thats using the unity built-in Fog feature (from the Lighting windows fog). It is not a post effects, for some reason unity fog does not support deferred path, so I can not do much about it.

I think if you know about basic shader coding you can just add a simple color multiply code to the AtmosphericScattering_Camera shader to achieve your purpose. If you need help for that coding I can help you out to make a custom shader.

Also if it is possible, can you post here some colored fog example image that you want to achieve, I can get better idea and may add that feature in future.

 

I think I will jump the requires unity version to 5.4 in next update. There are too many different graphics api and in some case the codes get automatically update by editor when import the asset. Also I just hate to keep using #if UNITY_VERSION >= 540 in the shader. Sometimes that makes it really hard to track the bugs. My current favorite version is 5.5 that supports native Visual Studio Code for Mac (and Windows).

 

I really don't need anything complicated, I just need the background objects/terrain to fade smoothly to the skycolor no matter where you look. A fog gradient that matched sky color would be perfectly fine, a single color that matched horizon (and changed with sky color) would be less accurate but still acceptable. In the end I just need fog to work in deferred and to match the sky color that is behind it.

Deferred is the issue of course, I am randomly generating all of my content (voxel terrain, prop placement, etc) so no baked lighting for me means I really need deferred to make things look great (with lots of dynamic lights). I think the issue may involve HDR on the camera (I really need to do more research in this area) as apparently unity fog may work in deferred if the camera is HDR.

Thanks for being so responsive. That gives me great confidence in my purchase of your asset and its future.

 

Here is a screenshot of the issue. The only thing I see of the sky aside from blue everywhere, is this striped zig-zag pattern.

 

- I have a noob question here, I never built anything on Wii U platform.
Is this screenshot from unity editor, right? ( or this issue occurs after built on Wii U dev console?)

- The Skybox color looks correct to me except this zig-zag pattern thing, I'm just guessing maybe it causes by Clouds 2D.
So can you confirm this issue is from the Skybox or the Clouds 2D? you can just disable the clouds see if it appears that problem.

 

It works fine in the editor. The image is from the Wii U build.

I'm sure it's the clouds because the entire sky is simply blue except for this white pattern, which seems to be the clouds.

For the moment I've gone back to Time of Day and it's working fine on Wii U so I may just stick with that.

 

Okay, I turned to defered rendering and it worked a while.
But for some reason I get errors now on a scene that was fine just a moment ago.

Code (CSharp):

1. MissingReferenceException: The object of type 'Transform' has been destroyed but you are still trying to access it.
2. Your script should either check if it is null or you should not destroy the object.
3. UnityEngine.Transform.get_rotation () (at C:/buildslave/unity/build/artifacts/generated/common/runtime/TransformBindings.gen.cs:85)
4. UnityEngine.Transform.get_forward () (at C:/buildslave/unity/build/artifacts/generated/common/runtime/TransformBindings.gen.cs:81)
5. usky.uSkyLightShafts.OnRenderImage (UnityEngine.RenderTexture source, UnityEngine.RenderTexture destination) (at Assets/uSky/uSkyPro Beta 2/Scripts/uSkyLightShafts.cs:134)
6. UnityEditor.DockArea:OnGUI()

It leads to this line:

Code (CSharp):

1.  
2.             float horizionFade = Mathf.Clamp01 ((-LightShaftsTransform.forward.y + 0.02f) * Mathf.PI * 4);

And the scene turns black.

The way I fix it, is that I remove your sky and camera component from the scene and undo, after that it works again

 

If it works in editor it is hard for me to trouble shoot it. Anyway I will focus investigation on the clouds, see what can cause the problem with the console built.

It seems the error are related to uSkyLightShafts. If you disable or remove uSkyLightShafts component, anything else working fine?
If anything works fine, you may just stop to use the LightShafts for now until I solve it.
Frankly I don't have much glue why this happen, I can not reproduce your problem. In general I just need more information. If possible you can provide your problem project via PM. You can remove most of your personal asset and just leave basic uSkyPro asset with the problem scene file.

 

Hi @Luckymouse

Just bought the asset and been trying it.

Quick question, If I enable HDR mode in uSkyPro, do I have to enable HDR also in my camera.

What about tone mapper image effect? Do I attach and enable that too on the camera? Or is this done already internally by uskyPro?

 

I think Luckymouse decided that the internal tone-mapping should simply be called HDR. No doubt this is done to make the world more exiting by adding intrigue and confusing mystery to our lives.

In reality there should not be any internal tonemapping since tonemapping is handled by camera Post-processing Stack image effects.

I actually have no idea what to enable or disable if we use the correct workflow.

 

Yeah, I think the documentation needs a bit more explanation.

 

I have noticed that the sun and the moon gets a bit distorted look when they are near the side edges of the screen. Perhaps it is a perspective distortion from 3d, but is there anyway we can get them to be rendered at a perfectly round at all times on the screen? Is this because of the limitation comes from using cubemap?

 

I have also noticed that there is cloud 2d plane which has no example of, how do we use this? Just place them in the scene?

-- Edit --

Just tried to put them in the scene and it seems to work ok except, while in change of the day, the lighting on it suddenly pops into opposite direction. This does not happen with the backdrop clouds.

Also the cloud 2d plane shader needs the same scatter multiplier options as with normal cloud 2d shader.

I tried to blend two together and they just doesn't look quite the same without the same options.

 

How can I really bleed light color from sky or sun onto the cloud? I want to try and make a real bloody sunset with clouds getting the same similar color, but no matter what I do , the clouds's color doesn't not really change much except they get brighter or darker.. I need more color saturation option for the clouds...

 

On high altitude, sun seems to disappear or appear to suddenly. It should show itself rising from the horizon, but for some reason it seems to pop in and out on altitude of about 16000 units. What's the most likely the limitation for the uSky pro to behave correctly? I perfectly understand the limitation so I just need to know how far I can practically go up without things looking wrong. (in unity unit)

 

I know it does not support 2d yet, but will it be supported eventually? I think the biggest problem is the sun and moon stretching because it is rendering on the cubemap but my initial impression is it can't be that difficult to make it work with 2d where we can control the rise and set of moon and sun using x y plain axis.

 

@castor76
Sorry for late reply. There are quite a lot of questions here. I'm going answer them here.
- HDR
The nature of physically based sky has more energy value than the color value, and that why HDR option is for different lighting situation. By default the HDR of uSkypro has been turn off (unchecked), which mean the sky get tonemap it-self, so it renders more like in a neutral state as human eye will see. (The image from human eye is different than the picture that capture from camera in real world.) With self tonemap by default that the brightness value clamped between around 0 to 1. In this this case the camera does not require to apply any tonemapping to filter the brightness.

If HDR is on (checked) mean the sky brightness does not get clamp (raw data). The sky will look brighter and It will preserve more enegy in the reflection cube map. In this case the camera should apply the the tomemap.
Regarding the camera HDR the theory is exactly the same. By enable the camera HDR to store the color value greater than 1, which it is 32bit per color channel. So that the tonemap filter are calculating the raw (un-clamped) rendered image from the camera.

In general if you enabled uSkypro HDR that you will need to enabled the camera HDR, which HDR requires by tonemapping effect (not requires by uSkypro).

Hopefully my explanation here also solves some of the confusion from StaffanEk.


- Documentation
I explain most of feature for which parameter are already in the uSkypro Tooltip. Or the tooltip is a simplified version of the documentation. I believe uSkypro is easy to use.


- Sun and Moon distortion
The distortion is normal that due to camera perspective field of view angle. The sun of unity default skybox renders the same distortion. Also you can simply test it by create a 3D sphere and move it to the corner edge, and you will see the rendered sphere will get distorted in perspective camera. Right now it has to no option to change that.


- Cloud 2d plane
Lately I don't get much feature request for the Cloud 2d plane material, so it has not been fully updated, and the sample scene was in the uSky 1.x, anyway you figured it out already. I will check the pops into opposite direction issue.
I will add the scatter option to it in future.

-
Cloud color
The current Color color is based on the Sun color and Ambient gradient color in uSkyLighting component. That is the color control option of the clouds available for now.


- Sun or Sky disappear in high altitude
For optimisation reason the precomputed data for uSkypro with limited altitude sample. With 4 altitude samples, ( Ground Offset = 0 and Altitude Scale = 1), your camera should be able go up to 40000 (unity unit) without problem.


- 2D support
Until I saw your last question here, I guess I understand that why the sun and moon distortion that bothering you.
In theory, the sun and moon distortion or stretch can be solve to support 2d or orthographic camera. However i have not been plan to work on it yet, not sure when will be done.

 

Hi. Thanks for the answers.

For sun disappearing issue, I think I am well within the range but the sun still pops to disappear down the horizon when say I am about 10000 high. It doesn't dim down as much and then just pops to disappear instead of getting dimmer to fade away down the horizon. I can still see more or less the same sun size going down the horizon and then just disappear without fading off. If it shouldn't fade off, then should it not get clipped by the horizon to disappear instead of just pops off to disappear?

 

@castor76
Ok, I figured out what happen with the sun disappeared at horizon when the camera at very high altitude. For optimisation reason I forced to disable the sun light in code when the sun is below the horizon level, so the scene will keep only one moon light at night time, instead of 2 (Sun + Moon light). However when the camera at very high altitude, the camera is still able to see sun even the it is below the horizon level from ground view.

Right now I don't have a perfect formula how to calculate the correct horizon with camera high, Alternative solution that you can just comment out the sun enable/disable code in the uSkyLighting script:
The code is inside the UpdateLighting () function, should be in line number 158.

Code (CSharp):

1. // sunLight.enabled = (normalizedTime > 0.48f /* || MoonIntensity < 0.01f */) ? true : false;

( Add two slashes in front of the code //)

It should fix the sun pops off issue.

 

Is this mean there will be 2 light sources affecting everything in the scene at all times? Will it not make the lighting weird?

 

2 directional lights will not get the "lighting weird", it depends really how you set up the lighting.
In general the intensity of moon light is very low, which mean you can still use the sun light as the main light source, or you can set the moon intensity to 0, that mean moon light will be disabled.

Because you want to have sun light to be seen when camera at over 10000 altitude high, I do not know how your scene setup, which I don't know what the camera will be rendered at 10000, an aircraft or floating city?
or if you want the camera go even higher altitude, I don't know.

When the skybox renders the sun spot, the sun light has to be active. There are another way to do this that you can change the "normalizedTime > 0.48f" to lower value, that will delay disable time of the sun light.

 

uSkyAtmosphericCamera.cs gets messed up when I use it with VR Single Pass Stereo Rendering. Is it possible to fix this?

 

It also behaves oddly when using forward mode and Multipass stereo rendering without VR.