Graphics Azure[Sky] - Dynamic Skybox

Working in progress...

I changed in the Options tab the default profile to a list. Now the user will be able to add as many profiles as he wants in this list and when starts a day that does not have a day profile attached to the calendar, a random profile from this list will be used.

​

 

Okay, I'll figure out a way to do this.

I'm still working on profiles system, but it's good to think ahead to have everything planned. Disabling the Azure climate will not be a problem, you only need to configure the day profiles to not rain or snow for example, the weather option will be there, just choose not to use.

The Output System is a good option to control weather on third-party assets when the game climate is linear like Stardew Valley style games, where rain for example has a set time and date to start and end. So with the Output System it is easy to control this type of climate using a curve to control the rain during the day.

But to control sudden climate changes in third-party assets, the Output System is not as efficient, so I'll need to figure out a way to do it without "jerry-rig".

 

I have a strange issue I've been seeing for last couple of versions. I haven't used Azure Sky much yet so this issue may have been there for a while. If I drag the Standard Sky prefab to the scene then it works perfectly. But if I drag the Precomputed Sky to the scene then it seems to take over my camera when the game is run and I get a strange view from above the terrain. When I pause the game to see where the camera is, I find it in the moon.



Any ideas what's going on?

 

I see now it's doing the same thing with the Standard Sky prefab, but the moon just happens to be about where my camera was so it all appears more correct. If I change the time of day then the moon rotates around and the camera seems affixed to it and also rotates.

 

@magique
I think you're confusing the cameras, the camera that is turning around the moon when it changes the time of day is the camera from within the Azure prefab called "MoonCamera", this camera is child of MoonSphere and rotates around the moon to always be pointed to the same moon face and capture the correct phase of the moon. This camera generates a RenderTexture that is later drawn in the skybox.

The gizmo of your camera is showing in the same position as the moon sphere, so there is no way your camera is rotating around the moon, select your camera in the scene to see. Actually it's not your camera that goes to the position of the Azure prefab, but Azure prefab that goes to the camera position. Uncheck the "Follow active MainCamera" option in the Options tab if you do not want the prefab to switch to the camera position, but I recommend leaving it on because effects like sun shafts require the directional lights to be centered with the camera to work properly.

The reason your camera moved to a high position in the sky when you used the pre-computed prefab is probably because the "Altitude Mode" property was set to "Manual" on the Scattering tab.


In manual mode, you control the height of your camera through the slider. This option is for you to be able to take quick tests to see how the altitude change is influencing the sky. After you set the sky, you should switch to automatic mode and reposition your camera to the source location.

 

This was the whole issue. Thanks for the help. It's working fine now. Except there are no clouds in Precomputed sky prefab. Is that correct?

[EDIT]
Nevermind. I see it says "Working in Progress"

 

Working in progress...
Another feature that is being implemented is the option to set the curve mode individually for each property in the Inspector.


In the current version of Azure, the curve mode is defined once for all properties. Now with this new feature, the user can set individually for each property whether it will be based on the timeline, the sun elevation or the moon elevation.
​

To be easier to visually identify which curve mode each property is using, the color of the curve will be:
Green when curve mode is based on the timeline.


Yellow when curve mode is based on sun elevation.


Cyan when curve mode is based on moon elevation.



For those who do not know what the curve modes are. In Azure, each property is a curve field or a color gradient, so you can set a different value for each time of the day, and as the hours go by, the property values change smoothly to the value you set at that time of the day. "So this is the curve mode based on the timeline".

But on certain occasions, when the time mode is set to "Realistic" depending on the date and location, it may be day or night and the property values that were set based on the timeline will not match the time of day in different dates and locations. In this case the curve mode based on timeline is not the best choice because you would have to customize a different day for each date and location.

The best thing to do in this case is to use the curve mode based on the elevation of the sun, so no matter the date or location, because the values set in the curves and gradients always will match with the sun elevation in the sky. Then as the sun moves up or moves down in the sky, the values of the properties will change smoothly to the values set for when the sun is at that elevation in the sky.

You also have the option to base a curve on the elevation where the moon is in the sky.

​

 

Just wanted to report some quick compatibility testing results. On the Wii U with Unity 5.6.3p4 the Standard Sky prefab works perfectly. At least with the default settings anyway. However, the Precomputed Sky prefab only shows a sky with continuous bands of solid colors. Standard Sky would probably be sufficient for my Wii U needs, but it would be nice to compare to the other option at some point.

 

Thanks for the feedback.
I do not know what may be causing the precomputed sky problem on Wii U. As I do not have this console it gets very difficult for me to figure out and solve these types of problems.

The difference between the two sky models is that the precomputed sky uses 2 tables with precomputed values stored in a texture2D and texture3D. I do not know much about developing games with Wii U, so maybe this platform does not support 3D table, or just does not support the 3D table settings.

The precomputed sky is very strict about the settings of the tables. The tables must be configured as follows:

• Wrap Mode: Clamp
• Filter Mode: Bilinear/Trilinear

If you select the precomputed Inscatter table in the Editor and change the "Filter Mode" to "Point", the sky will look with solid colors similar to "rings".
If that is the problem, then there is not much I can do because it is a limitation of the precomputed sky that needs to use 3D tables and also the platform that does not support 3D tables.



I do not know if you remember, but a few months ago you tested on your Wii U an old version of Azure, in that test, Azure did not work correctly.
I replied that it could have been the syntax of some function in the shader written in an unacceptable way on the Wii U platform, well, when I did the new Azure version from scratch, I took care to correctly write the syntax of each function in the shader. Since you said that the default sky is working, then just fixing the syntax of some functions and calculations was enough to solve the problem.

Maybe now it's the same case! As I'm doing Azure again from scratch, I'm going to rewrite all the codes and check if the syntax of some function or calculation in the shader is wrong, maybe I missed something in the precomputed sky shader. Although I'm more likely to believe that the cause of the problem is the platform incompatibility with the 3D tables.

 

Yes, that's exactly how it looks if I'm reading your description correctly. I'll do this test at home when I get a chance and see if changing to Point mode is indeed the same look as I'm seeing, but it sure sounds like it.

 

So, I tried your test of switching to Point mode and that's not at all what I'm seeing. Here is a screenshot of what it looks like on Wii U.

 

Ok, this is the texture format that is not supported. The Wii U must be changing something in the texture that makes it lose precision, I've seen this same type of behavior while trying to create the precomputed tables.

Initially I tried to save the textures in .png format using the EncodeToPNG, but when I tested the textures it showed the same image that you are getting. The precomputed sky only worked correctly if I sent the texture in the same format as it was computed using the Texture2D and Texture3D class. That's why the precomputed tables are saved as .asset, this is to keep the textures data in the same format(Texture2D/Texture3D) and precision as they were created.

 

Working in progress...​

I've already implemented a profile blending system based on weights that will be used to control sudden weather changes. The user will be able to add in the "Weather Profiles" list as many different day profiles as he wants.

Unlike other sky systems where the climate system controls only certain parameters such as cloud coverage, rain intensity and snow intensity. In Azure[Sky], each day profile will be used as a different weather. This means that any modifications you make to the Azure[Sky] parameters will change smoothly with each type of weather, even the lighting and ambient colors will be based on weights of each profile.

The user will be able to add or remove day profiles from the Weather Profiles list and create as many different weather variations as they want. Next to each profile in the list, there is a field to set the time in seconds that the transition to that weather will last. And next to the field, there's a button to change the weather for that profile in the list.

So to change the weather to another, all you have to do is push a button while using the Unity Editor, or call this method anytime of the game:​

Code (CSharp):

1. SetNewWeatherProfile(int target)//Set in target the profile number in the Weather Profiles list.

When the user calls the "Default" day profile by clicking in the button or calling the method SetNewWeatherProfile(0), will return to the day profile attached in the current day of the calendar, which in the image above is "Day Profile 1" attached to January 1, 2018. This is the only day profile in the "Weather Profiles" list which can not be removed for obvious reasons.

Special thanks to the @ftejada that proposed this idea in this topic.

The system is already working, I will not show any video because I still have to redo the shaders and create the particles, also it is necessary to do the custom profiles Inspector. But the hard part has already been done that is to blend the profiles to make the smooth transition from one to another. So it's likely I will not bring anything new in the next few days, because these are time-consuming tasks to do.​

 

Looks good! It means I just have to click on the "GO" button in Inspector to test in editor any of the preset I choose? Of course by setting the desired transition time (1s or more).

One feature request: would it be possible to integrate the new Azure Climate feature with Playmaker? My point is that it would be really useful to have a couple of Playmaker actions to send and receive events and have this way the option to change the weather/sky and lighting conditions at runtime without any scripting knowledge.
Thanks!

 

Exactly!
You can even set a transition time equal to 0s for the transition to be instantaneous.

I can try! Although I do not have PlayMaker, I believe it has a way to run a method in another script.

To change the weather by code, you will only need to call this public method of AzureSkyController script. It is not necessary to pass a transition time parameter because the method automatically takes the value set in the Inspector.

Code (CSharp):

1.  
2. SetNewWeatherProfile(int target)//Set in target parameter, the profile (int)number of the 'Weather Profiles' list.
3.  

Is there no available node in PlayMaker to do this?
[Edited]
It is written in Playmaker's description in the Asset Store:
"Access scripts and third party plugins."

 

Hi, yes you can use the Call Method action in Playmaker.
If that's the only method needed you may not need custom actions.
Custom actions can give the user a nicer UI (specific action name, tooltips etc.), and if you're calling every frame can be faster.

Azure[Sky] looks great BTW

 

Hi!

I have a question.

I want to use Linear color mode in my project (Since im using other plugins that use linear mode, steam vr reccomends it, and since its the modern way of working with color in games, from what i have heard)

But when i use linear with the Azure-sky i get these horrible banding artifacts. Is there anyway of getting rid of these with inlinear mode enabled. I tried all settings i could think of, something i missed?.

 

I'm slowly coming back to my first love, Playmaker!
And I have a lot of catch-up to do!
Thank you so much for your help, Alex!

 

Thank you for the explanation!
I'm going to check out Playmaker when the new version of Azure[Sky] is ready, I want to make the new Azure[Sky] version compatible with as many assets as possible.

Hi!
Azure works in both color spaces.

Maybe you're using some kind of post processing image effect? I believe this may be related to the setting of your color grading.

 

Hello! I would like to ask a question.

My current project is an airplane flying game. To avoid z-fighting between the water and shorelines (and for some other reasons), my solution so far has been to use multiple cameras for each player, each rendering the scene for different distances (so, let's say, camera 1 renders from 3m to 300m and camera 2 from 300m to 30000m).

My question is, since many effects I've seen before rely on basically having a single camera, would this multiple camera solution be compatible with AzureSky? Would I lose out on some (or all) effects?

Thanks!

 

Hi!
I did not quite understand your question, but it is possible to use Azure[Sky] on multiple cameras at the same time on the screen. The "Sky Mode" in Options tab need to be set as skybox, then the sky will be visible to all the cameras. For the fog scattering to work properly, it will be necessary to add the image effect to each of the cameras.

Here a screenshot with two cameras running at the same time on the screen at different positions in the scene.


I think the only feature that will not work correctly is the altitude variation of the precomputed sky model. This sky model uses the position of the last active camera that contains the MainCamera tag to apply the altitude effect to the sky. As this precomputed sky model is still in beta, this is a good question for me to solve in the next update because I had not thought about the possibility of multiple cameras.



But if you have two cameras in the same position and want to render different distances from the scene, it's also possible. Again the "Sky Mode" should be set as skybox in the Options tab so that all the cameras can render the sky. The fog effect should also be set on each camera.

Here an image with only the Camera 1 activated and rendering the scene between 3 to 3000 meters (I increased the distance to 3000 to be easier to visualize). Note that in Clear Flags it is set to "Depth Only", this is to prevent it from rendering the skybox twice consuming more performance.


Here an image with only the Camera 2 activated and rendering the scene between 3000 and 30000 meters. Note that in Clear Flags is set to "Skybox", now the background sky is rendered.


Here is the final image with both cameras activated!


In this case, the precomputed sky fog is also not working properly because the fog distance is based on each camera Clipping Planes values. This is another bug to be fixed in the precomputed sky model.


I hope I have clarified your question.
Regards

 

Hello _7stars!

You absolutely clarified my question, very thorough response, I appreciate it! Although I was very interested in the altitude variation of the precomputed sky, even if only the standard sky works with multiple cameras it is already fantastic, so I believe I will be buying your asset.

Regards!

 

Hi!
It was a post process that created the banding
Its "Ultimate water", the new version of "Playway water" (although i got the banding with playway as well).

When you enabled and disabled the "water camera" script you could see it clearly
The banding is mostly visible at night when you turn the gamma slider up (make it darker)

I have seen that you used the asset in a demo so i ask you first.

How can i get rid of it, i think i tried all the settings in the water asset?

 

I already suspected it was some post-processing effect because that had happened to me before. In very dark scenes, which is the case at night, Unity's post-processing stack seemed to limit the color amount of the image. But this never happened again, I think it must have been fixed in some update because I tried here with several different post processing settings and it is working without problems.

You can try to reconfigure your post-processing effect, and make sure you are using the latest version of Azure[Sky] and Unity's Post Processing Stack. I'm here using the latest versions of plugins in linear color space with no problem.

 

The precomputed sky model is very difficult to implement and as discussed in some of the above topics, the precomputed tables do not work on Wii U and may not work on some other console like PS4 and XBox One, as I have no way to test it.

As I'm practically redoing Azure[Sky] from scratch, I'm looking at Sean O'Neil's Accurate Atmospheric Scattering sky model. This sky model is single scattering, so it does not use precomputed tables and therefore is faster than the precomputed sky model and also has altitude variation. I think it's worth trying to add a new sky model in Azure[Sky] based on Sean O'Neil sky model.

So keep an eye on the upcoming Azure[Sky] versions!

 

Hi!
I think you misunderstood me its, not unitys post processing stack that created the banding, it is "Ultimate water" the new version of playway water (i got it in playway water to). Any tips on how too fix, too use it together with azure, since i have seen you use the same water.

Can you use "Ultimate water" azure sky and linear lighting wothout banding at night. If so, how do you do it?

 

I've done a lot of testing here and everything seems to be working fine with Azure[Sky] and UWS in linear color space. I just tested the UWS demo scenes, I have not changed any water or Azure[Sky] settings.


I remember this problem happening on PlayWay on the island scene when the camera was underwater. But in UWS so far I have not encountered any problems.
A underwater screenshot.


I'm using in these tests Unity 2017.1.1f1 and DirectX 11!

 

Are there any plans for integrating with the WorldManagerAPI?

 

I finally purchased your asset today and I just have to say how amazing it is so far. I really like the results I'm getting. Good job on this asset

On your roadmap I read you planned a feature for volumetric clouds. Is this something that will come anytime soon? My game will really gain a lot from this feature as I have floating islands and it would be cool if I can jump from the island through the clouds. Of course I could implement another cloud system but I'd rather have a perfect integration with Azure Dynamic Sky instead. So any info on that feature?

Thank you for all your efforts so far and keep up the good work

Regards,
Wurlox

 

I can not confirm this because I do not know this asset and its purpose.

Hi!
Thanks for supporting Azure[Sky].

Volumetric clouds and sun/moon volumetric lights are on the roadmap. But this is something that will not be implemented so soon because these are the most complex features for me to do due to the fact that I do not yet have all the knowledge on the subject. These two features are still in the study phase, the volumetric clouds that I have running so far require a lot of performance and it is not possible to fly through the clouds and I do not want to deliver an asset that is useful just to make beautiful screenshots.

I am currently giving priority to climate system, as this is a more important feature for the sky system. I believe that after releasing this big update and fixing the bugs in the precomputed sky or maybe implementing the Sean O'Neil sky model, there will not be other features for me to add in Azure[Sky] other than volumetric clouds and sun/moon volumetric lights. So I'll focus all my efforts on those features.

I know there are other third party assets that you can try to use with Azure[Sky] for now and they are free. I've never done the test, but I see no reason for them not to work well with Azure[Sky].

• Free volumetric clouds.
• Free volumetric lights.

 

Here you go:
https://github.com/adamgoodrich/WorldManager

 

I already tried kode80 clouds and it is a great asset. However I will still wait until you integrate the volumetric clouds with Azure Sky. Maybe I will use kode80 as an alternative until Azure gets updated. I'm also looking forward to the upcoming features regarding the climate system. You are doing a great job so keep it up.

If I finish implementing Azure Sky I will post some screenshots.

 

Hi!

I did some new tests myself. The reason why it works for you is beacause i you use a normal camera and i have a vr project (VIVE Steam vr). The banding only appears in the vive camera.

The banding is also linked to the Underwater IME script, No underwater script no banding artifact.

So with vive camera, Ultimate water with the Underwater IME script you get the banding.

I dont know what in the Vive camera that would be different from a normal camera. I tried both single and multipass rendering but still get the banding.

Maybe i should contact the water people at this point...

 

Hey @_7stars !
I love that you are working on profiles and being able to switch between them. Me and my team are working on our game and we are about to releases in a couple of months, do you have any estimated time arrival for this profile patch?
We would love to implement it before release.
Thanks!

 

@_7stars If you haven't already reached out to him, @AdamGoodrich told me he'd be happy to Skype with you on helping you to integrate WAPI into Azure. Just send him a message and he'll be happy to help.

 

Hi!
I plan to release the new version as soon as possible, my intention is to finish before the end of this year, because I'm going to start a big project early next year and I also do not want to delay my schedule.

But I can not stipulate deadlines with such certainty, because many features that I'm implementing, I'm doing for the first time, and this makes it almost impossible to know how long it takes to do.

There are also other features that I have not been able to implement in previous versions, which now with more knowledge, I'm trying to implement again and this consumes a lot of time of studies, tests and research.

For those who are working on a game or team with a set deadline to release the game and will choose to buy Azure[Sky], I recommend that you take into account the features that the tool currently offers or wait until the release that contains the desired feature to find out if still remains enough time for development.

First I need to finish the new version to see if it will be necessary or possible to integrate Azure[Sky] with WorldManager. I want to make Azure[sky] compatible with other environment assets, and when the new version is ready, I'm going to study the best way to do this. Thanks for pointing me out to this tool!

Ps: It's currently impractical for me to use Skype because I do not speak English and even to write a sentence I need to do it several times until the translation makes sense. I am studying English on my own and so far I can only read without having to use google translator.
So I apologize if I write something that sounds meaningless or rude.

 

How about clouds？Do you like to generate paticle cloud like ue4？I think it would be awsome.

 

I mean the precompute sky.

 

@clagrens
I'm not sure if particle clouds are the best choice for performance, there are some games that use particle clouds, but generally in these types of games the weather does not change in real time. The volumetric clouds of NextGen games are usually made using Ray Marching. This technique allows us to have more control of the clouds and dynamically change the coverage, density, etc...

 

Working in progress...

New moon system!

Looking at the moon in the sky in the image below you may not realize the difference between the new method and the old one. Visually it does not have much difference, because what has changed was the way to generate the moon. Now the moon is procedurally generated in the shader using Ray Marching, excluding the need to use a 3D sphere in the scene to render the moon's texture.


The gain in performance with this new system will be another key factor. See below for the steps required to make the old system work.

• Calculate and render the mesh of a 3D sphere in the scene.
• Apply to this 3d sphere a custom shader to calculate the lighting and set the moon texture map.
• Add in the scene a camera that always points to the 3D sphere that will correctly capture the phases of the moon according to the sphere lighting. This camera generates a RenderTexture of the moon and sends it to the shader. This is very expansive for performance.
• And finally, with the texture of the moon generated and sent to the shader, the texture is applied to the skybox and receives the final polish.

Now in the new system, the moon sphere is created and receives texturing and lighting with simple calculations done directly in the shader using Ray Marching. This avoids all the complicated and low performance process explained above and everything is done in a single simple and fast step.

With this new method, the moon's sphere is realistically positioned at 384,000km away from the Earth and with a radius of 1,737km. This makes the moon size look more realistic in the sky and makes it possible in the future to create a method that automatically applies the size of the moon based on the seasons.

For now to change the size of the moon, simply change its distance from the Earth through a slider in the Inspector.

Another improvement I made and that I forgot to mention in previous posts is that now the undo function works correctly in the curves editor. In the current version of Azure[sky], it is very frustrating to try to undo a change in the curves editor without further messing up the edit.

 

Hi @_7stars

I'm trying the latest version of Azure [SKY] and I want to be able to change the "Fix Black Screen" parameter throughout the day. I understand that I can do it with the OUTPUTS system, but I think it would be good to have a curve in the inspector to change this parameter, for greater convenience and speed of configuration.

Do you plan to include the fog distance for Precomputed sky model?

regards

 

This parameter is there temporarily until I find out what is darkening the screen where there is no fog. And yes, I plan to find a way to make the precomputed fog be based on distance rather than density because it is better to customize and also fixes the problem with multiple cameras discussed a few posts above.

 

Working in progress...

New Standard Sky Model!

After years of development, I finally got the equations of the standard sky model working correctly. This results in more realistic sky with an incredible sunset and several customization options.


For those who like the current standard sky model because it is possible to set different colors and customization for the sunset, it will still be possible to switch between Realistic and Stylized sunset mode. The stylized mode will work exactly as it is in the current version of the plugin. This will greatly expand the ability of the standard sky model to adapt and work with several different game styles.


The improvements do not stop here. With a new sky model, comes a new fog scattering effect.

In the current version, the fog has the Projected and the Realistic mode. The projected mode has the most beautiful effect, but as skybox is projected over the scene it is possible to see the mark of the horizon line over the objects in scene when the camera is close to the ground. To fix this problem, there is the option to change the fog to realistic mode, but this mode is not 100% accurate.
Screen shot showing the effect of the horizon line over the objects in scene when using the projected fog mode.


The new fog scattering effect now works as it should and although the fog is no longer projected over the scene, it obtains the same amazing results, but without the horizon mark over the objects in the scene. Now the scenes will look more realistic than ever.


Also some improvements have been made in calculating of the fog distance and I am finishing implementing a height fog, soon I bring more news.

Thank you!

 

Very nice. It always looked good, but somehow it's becoming better and better.
And two questions, if you don't mind:
1. What about speed with the new model? I'm quite happy with the actual version.
2. I asked long time ago about multiple suns and moons. At the time it wasn't possible. With the new re-writing you're doing, will it be possible? If not now, maybe sometime in the future?
Thanks!

 

Performance should be about the same or even better than the current version. The equations of the standard sky model were already being made, but not in the right way. If we join the new moon system with the improvements made to the standard sky model, a few lines of code have been added to the shaders, but all that slow process of generating the texture of the moon from a 3D sphere using RenderTexture has been removed. So the performance gain is still positive.

But on the other hand, some features that do not exist in the current version and are being implemented will require a little more performance. As is the case with the climate system, blend profiles by weights, height fog and the cloud system that will be improved to work properly with the climate system.

Adding multiple suns and moons to Azure[Sky] is a big problem. This becomes unworkable if you just multiply the performance expense for each additional sun and moon.

Another big problem is to integrate multiple suns and moons with the calendar system, latitude and longitude, timeline, curves and gradients system, etc...

To be feasible to have a sky with multiple suns and moons, a new package would have to be made exclusively for this purpose and with a limit of features to not burst the performance.

At the moment I'm in a lot of work to do, but the Sean O'Neil's Accurate Atmospheric Scattering sky model would be the ideal way to achieve this. When I have more time, I'll try to get something like this video that was made using Sean O'Neil's sky model. But this would have to be done in a separate package or something, because it works for a different purpose than the Azure[Sky] system.

 

Working in progress...

Height Fog and Sun Texture!

I just implemented the height fog and the result was amazing. The new fog scattering effect was already amazing, now with the height fog it got even better. This is another great feature that will be available for free in the next big update.

Screenshot without the height fog.


Screenshot with height fog at 100 meters high from the ground.


Now the solar disk is no longer generated procedurally in the shader, instead a texture is used. The user can then create their own texture to customize the sun disk as desired.

 

Thanks for the detailed answer. I understand the lighting is the main difficult issue here.
Even though I know how important lighting it is, I,m totally opened to hack and workaround solutions. What would be your best advice to face huge planet in the background, behind the horizon, on a side, but somehow to have the sun visible (except a plane/3d mesh un 3D space). That will put the sun behind the planet and the shadow on the planet, more or less, towards the camera.

The height fog looks cool. Definitely, very happy I jumped in Azure`s boat.
Cool to have a custom texture on the sun too. Would it be possible to have a giant red sun (half screen even) with a less intense lighting in the middle of the day?

 

I would say the best way to make other planets is by using a 3D sphere away from the camera. But as you want the sun to cross in front of the planet, this makes the task even more complicated.

Maybe make the sun also being a plane or a 3D sphere with a custom shader? So just put the mesh of the sun closer to the camera, and consequently it would cross in front of the planet.

But the best way I think it would be to make a system exclusively for that purpose, so you would create your own mini solar system by applying a simple translatory movement to the planets around the sun. Something very similar to the video I mentioned in the last post. But this is even more complicated to do!

Yes, it is possible to define almost any texture for the sun. It is only necessary that the texture background is black and the texture import setting is with the "Wrap Mode" set to "Clamp".

See below the effect with two different textures that I got on Google Images. It is possible to decrease or increase the size even more and make the sun cover the entire screen.

 

Apparently a 3D hack solution is the only way to go. I'll wait to get my hands on the new version.
Hopefully a Playmaker integration would make things easier providing access to the sun movement variables/coordinates. I'm hoping this way to link the second sun (a 3D object) together with a fake sun light in the 3D scene/space and tweak/corroborate them with the movement of the main sun.

Sir, I'm very impressed. Very nice. This opens loads of possibilities.
Many thanks for your work!

 

Hey! I have a problem using particles together with the azure sky fog. The fog seems to be rendered in front of the particles. This is happening both with the standard particles/additive and with a custom particle shader made in Amplify Shader Editor.

Does anyone know about a solution to this? Thanks in advance!