Graphics Azure[Sky] - Dynamic Skybox

Hi!

Transparent objects are difficult to handle because most of them do not draw their position to the depth buffer, so the fog can not detect that they exist in the scene. If there is any object behind the particles, the fog will use the distance of this object as a reference, but if there is nothing behind the particles, the fog will cover the particle completely because it thinks there is nothing there.

One workaround is to open the AzureSkyFogScattring.cs script and uncomment the line of code with the [ImageEffectOpaque] attribute. This will cause the fog scattering to be applied to the scene before the transparent objects are rendered and should fix the problem, but otherwise the fog will no longer affect transparent objects like Ultimate Water System.

 

Hmm. That's problematic, because we're using both azure sky and ultimate water system.

 

So you need to make your particles draw to the depth buffer using a custom shader. Here at this link is an example of a custom particle shader that you can try to use.

I'm studying a solution that the user will apply on each transparent shader to force it to draw to a custom depth texture used by fog scattering effect that will fix this problem, but this is still under study and will be delayed to be released.

 

If i'm not wrong, that example is a cutout shader though right? That won't really fit within our game

 

I'm sorry, seeing now with more attention, the link shader is nothing more than an alpha test shader.

I have not tried it yet, but maybe you can try creating a custom shader with two passes. The first pass to draw the information in the depth buffer with Alpha Test and the second pass to draw the soft edges with Alpha Blend.
Here at this link has an old discussion exactly about it.



One way to prevent fog from hitting the particles or any transparent object is by using two cameras. Then one camera renders the scene, and the other camera only renders the particles or transparent objects, so you attach the fog effect only to the camera that renders the scene and consequently the particles will not be hit by the fog. This way the fog will continue to work with Ultimate Water System and the particles will not be disturbed by the fog, without the need to uncomment the attribute [ImageEffectOpaque].
I tested it here and it seems to have worked without problems.



I'm finishing implementing a feature that allows you to choose the layers that you want to not be hit by the fog, it works almost the same way I mentioned above, but everything works automatically without you having to create a second camera. This is very useful and should fix the fog problem with the particles and transparent shaders without breaking the use of Azure[Sky] with Ultimate Water System.

In the image below you can see the fog disturbing the cube that has an alpha blend shader. Since this shader does not draw the position of the object to the depth buffer, the fog does not know that it exists. So if there is an object behind the cube that draws to the depth buffer (like the water and shoreline), the fog will be applied based on the distance of that object, if there is only the skybox behind the cube, the effect will return the original screen without fog. That is why the bottom half of the cube is being hit by the fog and the top half is not.


So what I did was set the cube to TransparentFX layer and set the fog to exclude the TransparentFX layer. And now the fog no longer affects the cube.

I have not done many tests, but it looks like it's running smoothly and if you want I'll send you the modified fog scattering script by private message.



In the future I plan to modify the transparent and particle shaders to calculate the fog scattering directly on each object, in the same way that the standard Unity fog works. The standard Unity fog is calculated on the vertex shader of each object in the scene, this technique is more expansive for performance, but it is so far the only way I know to apply fog to transparent objects.

 

Hello Denis! Azure Sky sure seems to be the best (and the best supported) sky system out there! I'm moments away from purchasing it but just like Mark_T I might need to hack it a bit.

I'm making a VR game that takes place on various planets and moons and here are my questions. I will be happy with a short yes/no/maybe reply to each question and I don't ask for any guarantees.

Background Info: The game takes place on the surface of the planet/moon only, and at a fix time of day. Being able to get nice visuals from higher altitudes would just be a bonus for me, not a requirement.

Q1. I take it that its possible to have both moon and sun affecting the atmosphere at the same time, only that it affects performance badly, yes?

Q2. Custom texture and scale of sun disc can be done to moon as well?

Q3. Is it possible to change the radius of the planets atmosphere (by modifying your code if needed), and does the answer to this differ depending on if I use pre calculated or real time models?

Q4. Are there means of giving the impression of different densities, thickness (height) and composition of the atmosphere?

I understand that the position (or rather direction) of the sun and moon depend on latitude and longitude on earth as well as date. This shouldn't be a problem for me as I do not need the time to change during gameplay, and I can just find a date and time that fits my needs (it's a racing game with short races, not le mans ). Also, my landscapes are quite barren, so I think I could get away with double render time caused by sun and moon being active simultaneously if that is possible.

Depending on answers I might just have to let the races take place on good old earth for the first version, because these skies look amazing!

 

Hi @StoneMayson !
First, welcome to the forum and thanks for your interest in Azure[Sky]!

I did not quite understand this question, but in realistic time mode depending on the date and location, sometimes both the sun and the moon are visible in the sky. As the moon's brightness is less intense than the brightness of the sun, the brightness of the moon scattered in the atmosphere will be overshadowed by the sunlight leaving only the moon's sphere visible.

A picture is worth a thousand words, so this is how the sky will look when the sun and moon are visible at the same time in the sky.

Obs: This screenshot is from the new standard sky model I'm developing, so the colors of the sky are more beautiful and realistic than the current version and the Inspector is also different.

But making the moon's brightness visible during the day is a user choice, as the sky's characteristics are controlled by curves and gradients, just set a lighter color and set the moon's emission during the day to make the brightness stronger and more visible. And this will not affect performance.

As most users use the sky system to simulate Earth's atmosphere, the moon will be set by default so it does not shine during the day.

The moon sphere is made using Ray Marching, so it has the actual moon scale and is positioned 384,000 km away, so the moon is rendered to the correct size as seen from here on Earth. In the Inspector has a slider that controls the distance to make the moon look larger or smaller.

To improve performance, the texture of the moon is just a grayscale channel, but I can convert to use rgb channels to work the same way as the texture of the sun. I'm going to do some testing here, if this works I'll advertise it in the next post about work in progress.

The Standard Sky Model is based on the Hoffman and Preetham's paper. This model has been used in Azure[Sky] since the beginning of asset development.

This sky model is the fastest I've ever tested and in my opinion is the one that delivers the most beautiful results. This sky model does not have altitude variation, but offers a lot of options for customization, you can confirm this by testing the demo with the seven different days that is available on the Asset Store page.

You can even change some scattering properties like Rayleigh and Kr(Rayleigh height) to give a higher altitude appearance, but this will not change automatically with the camera's position.


The Precomputed Sky Model is based on the Eric Bruneton and Fabrice Neyret paper, and is still in Beta. This sky model is one of the most realistic of today and has altitude variation, and therefore requires a lot more performance than the standard model, and as the equations that control the characteristics of the atmosphere are precomputed in tables, this sky model does not offer many customization options and it is not possible to change the atmospheric conditions.

This sky model is recommended for anyone who wants a more realistic effect of the atmosphere here from Earth and will not be useful to simulate the atmosphere of alien planets, unless those planets have an atmosphere similar to here on Earth.

The precomputed sky model also does not have a cloud system yet, because as this model has altitude variation, it will be necessary to implement a system of volumetric clouds that can fly through the clouds when the camera changes its altitude.

It is not possible to change the radius of the atmosphere, but with the precomputed sky model it is possible to change the minimum and maximum height that the camera will affect the sky. If you set the maximum height to 800m, when the camera reaches that altitude it will look like the camera is almost off the planet. And so it gives the impression that the atmosphere is quite small.

In the presentation video of the precomputed sky model, if I remember well the minimum and maximum height that the camera reached was between 50 and 1000 meters.

As you are working with VR device, I recommend you take into consideration only the features of the standard sky model, because this sky model is faster. Also I need to warn that I have no way to test Azure on VR devices and consoles like Xbox, Playstation and Nintendo, but many customers have already informed me that Azure works without problems on VR devices, but I can not confirm this information.

The standard sky model does not have altitude variation, but it is possible to change some properties that change atmospheric conditions.

You can switch between Simple and Realistic time mode. And if you set the day duration to zero, the time of day will not change.

In Realistic Time Mode the position of the moon and the sun is realistically set according to the time, date and location. This mode demands a little more performance.

In Simple Time Mode, the sun just rotates around the scene and latitude and longitude only change the direction and slope of the sun's trajectory. Since this mode is very simple, the performance is better. In this time mode the moon is automatically set by the script to always be on the opposite side of the sun, but simply remove that code snippet that you can place the moon anywhere in the sky by changing the rotation of the light Transform in the Inspector.


Ps: Note that some features shown in the screenshots have not yet been implemented in the current version of the package in the Asset Store as they are in development. Check out the demo scenes in the Asset Store description to see what features are currently available.

 

Thank you! happy to be here. Well, that was more than a simple yes/no/maybe!

Thanks, that was what I was wondering. I was wondering if maybe I could make the moon act as a second sun, or the sun as a second moon. I will try this and let both directional lights be active simultaneously.

Got it! I first thought the precomputed one was the faster one.

This would be awesome!

I see that you interpreted a lot of my questions to be about altitude variation, this however is not so important to me. When I asked about "thickness/height", "radius" and "composition" I was more wondering about changing these parameters to change the way scattering calculations are performed, like simulating a planet with a thicker atmosphere or different radius.

I am happy with your answers and will purchase the non-lite version now. If it doesn't work out as I hoped I still have a kick-ass earth sky! Thank you!

 

Alrighty! This will work out nicely for my project!

I noticed something though. When the lighting intensity curves are in elevation mode, it treats positive and negative elevations identically. So when for example the moon shines from directly below the scene, it has the same intensity as when it shines from directly above.

So... even if the purpose of the intensity curves is not to simulate self shadowing from the planet, but only to simulate light being absorbed by, and reflected off of the atmosphere, the sign of the angle should be taken into consideration I think.

As it is now it seems that -1 on the curves x-axis represents the elevation of 0 degrees at sunrise and 1 represents an elevation of 0 degrees at sunset. If you want to leave everything 100% customizable this could be extended so that -1 and 1 on the x-axis represents light from straight below, -0.5 = sunrise at elevation 0 degrees and 0.5 = sunset at elevation 0 degrees.. just an idea.

I will work around it and override intensity when camToSun/Moon.dot(up) is negative. Tell me if I have misunderstood it all .

 

The sky model of Hoffman and Preetham was proposed in the early 2000s and is based on earlier models of the 1990s. Hence the equations of that time were more simplified to simulate sky only at sea level.

The precomputed sky model is more recent and uses more complex calculations to simulate the atmosphere seen from any camera position. So even using precomputed data, the performance is worse than the standard sky model. In fact the precomputed sky model is originally used to simulate planetary atmosphere where the camera can go out into outer space, orbit the planet and re-enter the atmosphere like a spaceship.

Instead, in Azure[Sky] this sky model is used as a simple skybox with altitude variation option. I still want to try to make an interplanetary atmosphere system using the Precomputed Sky Model or the Sean O'Neil's Accurate Atmospheric Scattering sky model.

I'm glad to hear that the asset will be useful and thanks for supporting Azure[Sky]. I think the next big update will supply almost all of your needs.

I think you must have been confused a bit, and I think I know why. In fact when curve mode is set to "Elevation", the -1 on the curve represents the angle 270° below the horizon line, when the moon is at the lowest point of the scene. The value 1 will represent the angle 90° when the moon is at the top of the sky. The curve value 0.5 refers to the position of the moon when it is exactly on the horizon line at 0°.

If you look at how I set up the curves that control the moon's brightness in the sky and the intensity of the moon's directional light, you'll notice that the setting is inverted compared to the setting of the directional light intensity of the sun.

That has a good reason to be that way. Remember that what determines whether it is day or night, is the position of the "sun".

Therefore, most of the curves that control the characteristics of the moon are based on the elevation of the "sun". So you have to customize the curve in reverse so that the moon shines only when the sun is below the horizon line.

If I set the moon's brightness to be based on the elevation of the "moon" and set a high value on the curve for when the moon is high in the sky, this will produce unexpected results in Realistic time mode because the moon may be visible in the sky even at daytime depending on the date and location. And that will make the moon shine by day, which is not expected.

In the next big update, you'll be able to set for each curve and gradient whether it should be based on the timeline, the sun elevation, or the moon elevation.

 

Aaaaa.. that explains why I had troubles understanding it .

Oh... this was exactly what I was attempting to do. Wanted my rocky ice planet to be basked in the twilight of both my "far off red giant" star, with a dim red orange glow, and the relatively strong reflected blue-white light from my huge moon at the same time . So I set up Realistic time mode, found a date where the moon was close to full and then set each curve based on the elevation of corresponding celestial body. This was mostly an experiment though, and I managed to get the result I wanted at a fix time value, so all is good.

Yeah I saw that, I thought that was set up for the "Simple mode" where sun and moon are always on opposite sides.

Sweet!

Thanks for the fast and lengthy reply.

 

I also see that the time value is the local time at longitud 0. At longitude 180, "night hours" have day light and vice versa. This might perhaps be confusing to people who don't think to adjust for time zones.. ..or that believe the earth is flat XD.

 

Actually this has confused some users, so I already have this fixed in the version I am developing.

In this case you do not need to change the time zone because it is the longitude that is causing the problem, the default value of the longitude should be 0, but I switched to 180 to flip the east and west in the demo scene of "simple time mode" and I just forgot to reset it to 0 before creating the prefab. If you keep the latitude at 0 and the longitude at 180, this will reverse the day and night.

 

Thank you for the great advice and descriptions! It gave me a much better understanding! So if I understand correctly using different layers will solve the issue with having fog render ontop the particles but the particles will not be effected by the fog at all, correct?

It would be great if you could send me the modified script! Thanks!

And also: Do you mean the standard fog is more expensive than your fog script? Just curious

Thanks!

 

Exactly!

No, because Unity's standard fog calculations are very simple. But if I use the same technique as the standard fog is made to apply the Azure fog, it can become expansive.

The reason that the Unity fog works on transparent objects is because the calculations are made in the vertex shader of each object in the scene, so the fog does not need to use the depth buffer because the position information is already present at each vertex.

The Unity's standard fog calculations are made once for each vertex of each object in the scene, I do not know if I'm totally sure about it, but the more objects(and vertex) are in the scene, the more expansive the calculation of the Unity's fog will be. But as the calculations of the Unity's fog are very simple, the change in performance will not even be noticed.

Azure fog is a post-processing effect, so the performance will depend on the screen resolution because the calculations are done once for each pixel. Because it is a post-processing effect, the fog has no way of knowing what kind of object it is affecting or even the distance of the vertices of each object in the scene. This is why the depth buffer exists, the depth buffer is a grayscale texture with values between (0 - 1) that contains the position information of each object in the scene, as long as that object draws to the depth buffer.

The only problem of making fog as a post-processing effect is the transparent objects that do not draw to the depth buffer and the fog has no way of knowing they exist.

So if this modification in the fog script works and prevents the fog scattering from affecting the transparent objects, then I'll try to edit the transparent and particle shaders to apply the fog scattering using the same technique as the Unity's standard fog. As this will only be done for transparent shaders, I do not think there will be a performance risk.

This feature will be present in the new version, but I think it should work without problems in the current version, so I'll send you the new fog script by private message for you to take the test. Remember, I did not do many tests.

 

It seems to work! Thanks a bunch for the explanation and help! I'm considering making the particle shader control the opacity of the particle based on the distance of the camera to fake a fog effect, but I'm not sure how performance heavy that would be. Anyways, big props for the great support!

 

I want to make the moon bigger , how is that possible?

 

You can change the value of the "Disk Size" curve in the "Moon" subcategory of the Deep Space tab.

If you are using the Lite version, then the tab name is Night.

 

Good afternoon. When can we expect to receive Climate System/Weather Profiles?

 

Hi!
I'm working every day to be able to release until the end of this year, but I cannot guarantee with 100% certainty.

 

And I for one appreciate your above and beyond effort. You are doing an amazing and inspiring job, Denis. Thank you.

 

You can do it man.
I believe in you.
No pressure.

 

Reflection prob doesn't seems to be correct for realtime reflection, It doesn't reflect my ground or objects around.

 

For me the reflection probe is working without problems.

Maybe your reflection probe is not set up to render your ground and around objects. When you activate the reflections in the Lighting tab, the Culling Mask option appears to define the layers that will be rendered by reflection probe. By default the reflection probe is set to only render the skybox. Try setting the Culling Mask to Everything.

 

Weird it's not working for me! also I set culling mask to everything but a big reflection prob never can get me correct realtime reflection.

 

Hi, does Azure support VR single pass rendering ?

 

I do not have a VR device to do the test, so I'm not sure about this but I think Azure[Sky] will support sigle pass stereo rendering because I have correctly followed the Unity documentation instructions to make the fog scattering compatible with single pass.

The best way to figure this out is to expect some VR and Azure[Sky] users to see this question and have the kindness to take the test. Many users have reported to me that Azure[Sky] works with VR, but they did not specifically cite whether it supports single pass stereo rendering.

 

Working in progress...

Climate change has never been so easier. You can configure each profile to contain a totally different weather and lighting, and with a simple click you see the transition from one profile to another with a transition time pre-defined by you.

The climate system will work with all the changes you make in each profile, at absolutely all profile properties. This will give the user a huge power of customization. The climate system is almost complete, only need to add the particles effects of rain and snow.

I'd like to make a video demonstrating climate change in real time, but the quality of the video gets pretty bad. So I'll try to make a brief demonstration using only two images.

In this first screenshot, I created a custom profile to simulate a clear day without any cloud.

• The scattering setting is set with default values.
• The intensity of the sun directional light is set to a high value and the color is set to a light orange color.
• The height fog is set at 100 meters.

In this second screenshot, I created a custom profile to simulate a overcast day.

• To give a greyish appearance to the sky, the wavelength and air density were changed in the scattering settings.
• The intensity of the sun directional light has been set to zero, this prevents sunlight from going through the clouds and casting shadows on objects.
• The height fog is set at 1000 meters.
• A light gray color has been set to the ambient color because in this case the scene should be illuminated only by the ambient color and no longer by direct sunlight.
• The density of the dynamic clouds was set at maximum and the cloud colors were defined in shades of gray.

When the user changes the weather, Azure[Sky] will make a smooth transition from one profile to another with a user-predetermined transition time. "All I can say is that this feature is amazing!"



Also, as I had promised, I made some changes and now a custom moon texture is supported. It will work the same way as the texture of the sun, the only difference is that the background color of the texture instead of black, needs to be transparent.

 

You are awesome sir <3

 

I'll try

I have VR systems to try and am thinking of shifting to Azure-Sky. Let me know if you have a watermarked demo for me to try.

 

Hi!
Check your inbox.

 

I'm still waiting for precomputed sky cloud. This sky is really nice but needs cloud.

 

Azure[Sky] Dynamic Skybox and Azure[Sky] Lite are on Mega Sale for 30% off!

I agree, but this is very very hard to do!

The precomputed sky model requires 3D volumetric clouds and this feature is still a bit far from being implemented. The atmospheric data of this sky model are precomputed, so it will not be compatible with climate change because it is not possible to change the atmospheric conditions.

In most cases it is recommended to use the standard sky model, as this sky model is compatible with the current cloud system and the new climate system in development.

 

Still I prefer to use precomputed sky because it looks a lot better. Just I can't figure out how can I change sky color? I need to make it a bit more purple.

 

Working in progress...

With the new Output System you can directly set each element of the list to be based on the timeline, the sun elevation or the moon elevation.


To get access to each output, you only need to call the following methods:

• GetCurveOutput(int element)
• GetGradientOutput(int element)

As the name of this sky model already says, the equations that calculate the atmospheric conditions of the sky are precomputed and can not make changes. For the same reason, for now this sky model will not be fully compatible with the climate system. I'm planning a way to make this model compatible with climate change even without using clouds. Instead of using clouds to cover the sky, will be used a very dense fog, similar to the fog of the PlayerUnknown's Battlegrounds.

 

I'm trying to get the same fog/volumetric lighting effect as seen in your video:

But even with Post-Processing Stack I am not getting that thick atmospheric look. What settings/features did you use to achieve this look?

 

After adding the AzureSkyFog Scattering script to the camera and adjusting fog parameters, I'm getting more of the atmospheric look of the video. However, I see that the fog effect doesn't affect billboards on trees.



Is there some way to make this work?

[EDIT]
Seems to work fine for SpeedTree, but not for a free tree package I was using. Maybe that tree package is just bad.

 

Honestly I do not even remember the setup I did in the video, I just played with a few parameters.
I did some quick tests here and in a few minutes I got a result very similar to that of the video. I have just changed some properties of the following tabs:

• Scattering;
• Fog;
• Lighting;

Here is an screenshot with the exact configuration of each tab and the result that the sky should show without any post-processing effect. Note that I am using:

• Curve Mode as Elevation;
• Linear Color Space;
• Camera far clipping plane set at 10,000;

If the far clipping plane of your camera has a different value, you may need to change the value of the "Scale" property of the Fog tab.


What will make your fog prettier and brighter with a more lively look will be the post processing effect. More precisely the "Bloom" and "Color Grading". See the difference when using Unity Post Processing Stack with Antialiasing, Bloom and Color Grading enabled.

Bloom Settings:


Color Grading Settings:


Another Screenshot:


[Edited]: I quickly set the scene for sunset only, maybe the rest of the day and night are not in the best setting.

The problem here is not your tree package, but the shader you are using. Unity built in vegetation shaders do not draw the terrain's billboard trees to the depth buffer, unlike the SpeedTree shaders that draw the billboards to the depth buffer.

If you want your trees painted on the terrain and working in traditional Unity way, I recommend this foliage shaders. In my opinion this is the best Unity foliage shader, the video trees were using this asset and it correctly draws the billboard trees to the depth buffer. Here some screenshots using Advanced Foliage Shaders v.5.

 

Yeah, I have AFS 5 so I could give that a try as well.

Thanks for all the help with the settings. I'll give those a try as well.

 

WIP screenshot of my game using Azure Sky.



Also using RFPS, PRISM, Tropical Forest Pack, and more.

 

Hi,

I am sure this has already been asked somewhere but why is my main camera locked to the moons camera position in the sky? I need my maincamera to be on my FPS controller but I can't unfix it's position!



Any pointers would be much appreciated!!

I have created the relevant layers and assigned all objects but I think something else is going on here.

*If it helps I can move the MainCamera In the X and Z directions but not Y
** Also this only happens in the PrecomputeSky

Stephen.

 

Change the Altitude Mode property to Automatic on the Scattering tab. This is a exclusive feature of the precomputed sky model, if you leave in manual mode the camera's altitude will be controlled only by the "Altitude" slider based on the "Min Altitude" and "Max Altitude" parameters.

This feature is for you to quickly test the sky's altitude variation and see if the setting you made is ok.

 

@DenisLemos - Thank you for the reply that fixed it for me. I have decided to go with the Standard Sky for the clouds anyway so that is no longer causing me issues!

I am however having a different issue. If I set the day cycle property to anything over 0, the game stutters, very slightly but certainly noticeable, especially when looking at water in game. Is there a way to fix this? I need something in the region of 30 minutes for a cycle but I can't stop the stuttering.

Thanks,

Stephen.

 

How did you make the planetary terrain shown in the promotion video?

 

Hi,

Still cannot figure out the issue with stuttering? It goes completely once I set the Day Cycle Property to 0 and only happens if I set it to a specific time (for example 40 minutes).

I would really appreciate any support on this.

Thanks,

Stephen.

 

Hi!
Sorry for the long absence. Unfortunately, now I only have the weekends as free time to work on Azure. So I hope you understand if I delay in giving support and answering messages, I'm stuck in a lot of work.

In the video is not a planetary terrain, it's Horizon[ON].
I just set the "Max Altitude" of the precomputed sky model to the relatively small value between (600 - 800) meters. Then the fog scattering effect applied on a flat terrain gives the perception of the terrain being planetary and small.

I have planned a feature to be used in the precomputed sky model that will create a planet using the "Raymarching" technique. Then depending on the distance defined by the user and also the height of the camera, the flat terrain will be mixed smoothly by the planetary sphere until on the horizon only the planetary sphere appears, giving the impression that the terrain is spherical.

For now this is just theory, but I do not see why it would not work. I think this trick will make the precomputed sky model work very well with Unity's flat terrain, without forcing the user to reinvent the wheel by developing a new terrain system.

Hi!
I did some testing here and I noticed a behavior very similar to what you described happening to the my shadows.

I just imported the Azure[Sky] package into a new project and dragged the Standard Sky prefab to the empty scene, after deleting the default directional light from the scene.
I added a plane and a few cubes in the scene and just modified in Azure the "Day Cycles in Minutes" property to 30, activated Reflection Probe on the Lighting tab and activated the shadows on the directional lights.

After pressing Play to test several times I noticed a small stuttering in the shadows, it seems that the time back behind a fraction of milliseconds and then resumes to the correct position again. This may be related to the rotation application of the directional lights of the sun and the moon because I debugged the "timeline" variable and its value does not stutter.

I do not know exactly why this is happening, but when I switch to Realistic time mode, the problem goes away. But when I change the time mode back to Simple, the problem returns.

I think the problem is related to the rotation of the directional lights in simple time mode, especially when the lights spin exactly at 90 degrees and only the X axis changes. I noticed that if you change the Latitude to a value other than 0, the problem also goes away, even in Simple time mode.

 

Hey,
I'm thinking about buying Azure, but I got a few questions about a few things.

1)
What exactly is the difference between the standard and precomputed modes?
Can they be used at the same time? What are the advantages and disadvantages?

2)
Clouds.
What kinds of clouds are there?
Can they be changed dynamically?
Are they a texture or volumetric or something different?
Do standard and precomputed have different clouds or is that something different?
Can we easily swap out some textures to get different kinds of clouds?
Can that be blended at runtime as well?
What about animations? (instead of fully static clouds, like just a sprite)

3)
Stars at night.
How are they done?
What are the diffrences here between standard and precomputed?
Can users swap out the stars texture (?) easily? Or are they generated in a shader?
If so can we make our own "stars.mat"?
Is there anything that makes stars twinkle a little from atmospheric disturbances?

Thanks!

 

hi i went through the thread search to find a relevant issue regarding the black screen whenever i open a new scene.

the entire editor window is pitch black until i click on the azure game object or do some activity on any Gameobjct's component
this is not a big issue, but becomes so nerve recking when testing the scene for multiple time
i would appreciate a workaround

thanks

 

1) The two sky models are completely different.

• The standard sky model is based on the Hoffman & Preetham article. The physical calculations of this model were greatly simplified to run in games created around the 2000s, so it is possible to perform the equations in real time and change the values of the variables before each equation is calculated. This results in a lot of different sky customization options. The standard sky model is also very fast compared to the precomputed sky model and the other sky systems of the Asset Store.

• The precomputed sky model is based on the article by Eric Bruneton and Fabrice Neyret. This sky model is much more modern than the standard sky model and in my opinion it is the most realistic sky model that I know, it calculates the atmosphere from any point of view from ground level to outer space, this model is originally indicated to simulate planetary systems, but I made some modifications to work on the Unity skybox.
  
  I call this precomputed model because it uses data saved in precomputed tables. The good side of using precomputed tables is that it makes it possible to perform the effect in real time, the bad side is that it is not possible to change the atmospheric conditions in real time.

In the description of the package in the Asset Store you have the link to test each of the sky models. You will notice that the standard sky model has several different customizations, since the precomputed sky model is just what you see. But the precomputed sky model is more realistic and has altitude variation. So it will depend on the need of each user to choose which sky model to use.

Initially, the precomputed sky model will not be compatible with the climate system that is under development, but this will be done in the future.

As the precomputed sky model supports altitude variation, it is also not compatible with the current cloud system, but I think it should work with the asset "Fog Volume 3", I found by chance this animation of Azure[Sky](using Precomputed Sky Model) + Fog Volume 3.
https://twitter.com/VoxelKei/status/932778040098091009

Currently it is possible to switch between the two sky models and use the same Inspector to customize each one, but with all the changes to the next version this will make things confusing for users. So I'm analyzing the possibility of separating each sky model into a different system in the same package, since each sky model will have a different purpose and functionality.

Ps: It is not possible to use both sky models at the same time in the same scene.


2) Clouds are generated dynamically based on a Noise2D, they are non-volumetric, so you can not fly through. Who needs volumetric clouds, at the moment I can only indicate the asset "Fog Volume 3" that by the images of the Asset Store it is possible to create incredible volumetric clouds.

The next Azure version will come with the profile system, so you can dynamically control the properties of clouds and weather conditions in a very simple and intuitive way. You can see the clouds running by testing the demo of the standard sky model.
https://drive.google.com/file/d/0Bwu19sA7OALeMmc1ZkEwcndmdTQ/view


3) The night sky is the same in both sky models. Stars are a CubeMap texture that you can easily modify in Photoshop. If you understand astronomy, then you can even add the constellations to the texture. As I am not an astronomer, I have added stars randomly in texture.

The texture contains the information of the stars and also of the Milky Way. In the RGB channels are the color information of the Milky Way, and in the alpha channel is the brightness information and position of some stars more visible in the sky.

I do not know if you can see this in the demo scenes, maybe in the GI demo scene. It has a property in the inspector that controls the scintillation speed of stars(only scintillation of stars, not the Milky Way).

 

This is normal and occurs because the Editor is not constantly being updated and causes Azure shaders not to be updated either. When you click on any GameObject the Editor is updated and consequently the shaders are also updated.

If you activate the "Auto Generate" option in each of your scenes in the "Lighting" window, this will cause the Editor to update whenever you open your scene. You can keep this option enabled while working in the Editor and disable it before compiling the project if you do not need to use it.