Time of Day - Dynamic Sky Dome

The preliminary changelog of 2.1.0 is now online: http://modmonkeys.net/dat/doc/timeofday/#changelog

I will submit 2.1.0 next week if everything goes according to plan. Changes of 2.1.0 that could break compilation in your project on updating are the moved sun and moon parameters, see the last two points of the changelog.

The next big feature that's on the roadmap for Time of Day 2.2.0 is to improve cloud quality for higher end devices. I still have various articles to read and evaluate, so I cannot say which direction I'll take just yet.

 

ToD atmosphere as an image effect

Hey plzdiekthxbye, everyone,

Previously I had integrated the ToD atmospheric scattering into my terrain shaders (see my earlier post in this thread). However, it was becoming too much of a pain to add scattering to all my other shaders, so instead I have now implemented the atmosphere as a full screen image effect in my game. It reconstructs world position from the depth buffer (just like Unity's GlobalFog image effect), and uses that to compute the scattering. It works on the whole screen, so I set my camera to clear the screen to black and disable the ToD Atmosphere sky dome.

Atmosphere image effect enabled:-



Atmosphere image effect disabled:-



Pros:-

• Atmospheric scattering gets applied appropriately to the whole scene, with no modifications in other shaders needed.
• Atmosphere can be applied after other image effects such as SSAO.
• No longer have to render the sky dome mesh.

Cons:-

• Atmospheric scattering computed per-pixel, so performance cost may be prohibitive on mobile, seems to be no problem on PC though.
• Rendering order changed slightly: atmosphere is now applied on top of the sun and clouds (IIRC with the standard ToD setup, they are drawn after atmosphere), still looks fine to me though!

This might not be suitable for every application, due to the aforementioned per-pixel costs, but I thought you guys might be interested. I've attached the code to this post, feel free to use if you want.

Cheers,
Sam

 

I love the work you're doing, Sam. Did you test it with transparent objects that don't write to the depth buffer? Because it should break with those, which is another con of this technique. It can work for some people though.

My wish would still be for Unity to add a way to overwrite the fog function globally for all shaders - it would be the perfect way of adding custom physically-based fog.

 

I've sometimes wondered about this, way back before I switched to an "all shaders except ToD are within my own 100% handcoded shading framework" approach: we know that Unity patches Surface Shaders with fog logic (on mobile it seems to be per-vertex at least last year, not sure about today and/or other platforms). We also know any & all out-of-box shader logic is released as source code by Unity. So it's gotta be in some cginc (but I've never come across it), which would mean overriding it should be slightly easier than instructing users to turn off global fog and add their own finalColor modifier to all their Surface Shaders.

Any project that cares seriously about AA+ graphic fidelity will already have at least one (or multiple) custom post-processes that use the depth buffer, so they should really do per-pixel fogging in post, as long as you're already binding the depth texture anyway for other postfx purposes, that additional exp2 won't be a big deal. Gotta be smart about ordering of post-fx as usual. Users of postfx-studio might bug @echologin to add this, too..

Btw what is "physically-based" fog? Do you mean the atmospheric scattering in the distance that standard fog only approximates very gimmickily/superficially? Height-based fog? Both and more?

 

Both, possibly more. The most important thing would be a custom per-pixel or per-vertex fog color, for example calculated using the same scattering equations TOD uses to calculate the sky color. With very few adjustments to the equations it's possible to add height based fog density as well.

It would be extremely easy to do this if Unity provided means to globally override the fog color. A fog image effect only works as long as everything in your scene writes correct depth values - which is a big if.

 

I think ToD could still even now provide the logic "using the same scattering equations [..] with very few adjustments" in a cginc? Would still help greatly users who have their own depth-reading postfx or know how to add finalColor to their Surface Shaders. Sure it would be nice if Unity behaved like you're wishing, but as long as it doesn't, that fact still doesn't prevent ToD "in principle" from providing such --- and would add much value indeed!

 

This will be part of 2.1.0 (Scattering.cginc) - I can post an example of how to use it here as well once it's out. The basic code to replicate the Unity fog types with a per-vertex or per-pixel color calculation looks like this:

Code (CSharp):

1. #include "Time of Day/Assets/Shaders/Scattering.cginc"
2.  
3. half unity_FogDensity;
4. half unity_FogStart;
5. half unity_FogEnd;
6.  
7. inline float4 DirectionalFogColor(float3 dir, float dist)
8. {
9.     float4 fog = ScatteringColor(dir);
10.  
11.     fog.rgb *= fog.a;
12.  
13.     #ifdef _FOG_OFF
14.     fog.a = 1;
15.     #endif
16.  
17.     #ifdef _FOG_LINEAR
18.     fog.a = saturate((unity_FogEnd - dist) / (unity_FogEnd - unity_FogStart));
19.     #endif
20.  
21.     #ifdef _FOG_EXP
22.     float e = dist * unity_FogDensity;
23.     fog.a = 1 / exp(e);
24.     #endif
25.  
26.     #ifdef _FOG_EXP2
27.     float e = dist * unity_FogDensity;
28.     fog.a = 1 / exp(e * e);
29.     #endif
30.  
31.     return fog;
32. }

Where the _FOG_XXX defines have to be set via the multicompile directive in the shader you use this snippet in. Adding height based density is as easy as multiplying the result of DirectionalFogColor(...) with a scaled and saturated vertex world Y position.

 

Oh that's great news then! Good stuff. Suppose this will work easily for Surface Shaders with custom finalColor func, but if calling this from a post-process shader (with current depth value and view-direction known) were supported too, that'd be Just Marvellous!

 

Should work pretty much the same in image effects, shouldn't it? First you reconstruct the world position from the depth buffer - from this it's trivial to get the view direction and atmosphere color. You can probably re-use most of the stuff danger726 posted and just replace the color calls he does in his "Atmosphere.cginc"

 

Awesome

 

Yeah, I should have mentioned about transparent objects! For those, you have to apply the atmosphere in their shaders (e.g. in the finalcol modifier). Also, you ideally want to draw them after the atmosphere image effect has been applied, I do this by using a second camera. I did a brief write up on this here: http://dangersam.tumblr.com/post/93995840624/playable-build-updated.

 

2.1.0 is out (ish?) - I can download it from the Asset Store and see it as the latest version online, but I haven't received the email that it's been approved by the Asset Store team so far.

 

Hi I tested 2.1 and it improve a lot the stars, but there are some issues

The first one is with the moon.
This is a comparison between the previous and new version. I'm on mobile project (No Emulation), in forward, gamma color, fastest cloud quality:


Also when the Sky Multiplier is not 0 the moon become more and more invisible. IMO it's correct for the stars, but not for the moon:


The second problem is with clouds in the night. In the following images the clouds are in the same position. As you can see in the night they are barely visible only around the moon (an only because of the halo). Also the stars are always visible.


(A note here. The cloud texture is a jpg in grayscale. I changed the shader to use the red channel instead of the alpha. It allows a much better compression in ETC for mobile platform)

Please let me know if it's on my side that I'm using wrong settings.

 

I double checked with the clouds and it was my texture that was not bright enough.

 

Thanks for reporting this. You can work around the moon issue to a certain degree by adjusting the Moon.MeshBrightness and Moon.MeshContrast values, but I agree that it shouldn't look like this out of the box for your project setup. I'll investigate and fix this / make its behaviour more intuitive in the first hotfix release for 2.1.

 

I tried to use the new Time Curve but however I set it I don't get the result I need. How to slowdown the day and speed up the night?

 

After many trial and error I probably found how it works (did I miss the documentation of this? I can't find it).
The Y of the graph is the time that you will get, and the X is that real time in which you should normally be.
So to speed up the night you need to to anticipate the morning and postpone the evening. As this:

In this case the Sky Dome time will be already at 5 instead of 2. And will be still at 20 instead of 22.
Is it correct?

 

Yep, that's correct - sorry for the missing docs on that new feature.

 

I plan to release 2.1.1 rather soon to fix the minor issues people encountered so far. I recommend upgrading to 2.1.0 this week and report any issues you may find so that I can fix them over the upcoming weekend.

So far 2.1.1 includes documentation updates to describe some features that were previously missing from the docs and extend the FAQ section. Furthermore it fixes various issues that could occur in gamma color space (certain cloud quality settings looking unintentionally awkward, the moon being fairly screwed up by default).

I haven't received any bug reports for 2.1.0 except for mcmorry's posts in here. If you see something that could be a bug please make sure to report this week so that a potential fix can be included in 2.1.1.

 

I tested the Sunshaft on android device Samsung S4, and, after the last release of Unity 4.5.3 that fixes multithreading rendering, the ToD Sunshafts doesn't work properly, while the standard unity does. Disabling the multithreading rendering it works again. Unlikely the only way to test it is on the device.
Here some screenshot from the device to show what I get.

Unity Sunshafts

ToD (also a little bit slower). It's barely visible and also it show a large moving layer (more visible on the second screenshot).

 

What performance loss can be expected when adding ToD to an Android project (free license), using the correct optimizations in ToD? (compared to using a simple skybox and one directional light).
Thanks in advance

 

I'll check out what changed in the new sun shafts and bring the TOD sun shafts up to date. Should be able to get the fix in the 2.1.1 update.

This greatly depends on the devices you want to target. That being said, I optimized Time of Day a lot to squeeze every last frame out of the slowest mobile device I tested with, which was an iPhone 4. It's capable of running at 30-60 FPS on the iPhone 4, depending on how much of the screen has to be filled with the sky dome. Newer mobile devices (tested on my iPad 3 and iPhone 5) shouldn't have any performance issues with Time of Day.

 

I've recently purchased this and I'm very impressed! thankyou for this wonderful asset package!. One question, reading through this thread i saw a comment that you may be working on volumetric clouds (possibly for a separate asset pack) for greater realism and perfect for flight games. Have you had any time to progress this new asset pack as I would be very interested in volumetric clouds.

Cheers

 

Hey, I've just upgraded to 2.1.0, a big improvement! It's allowed me to get rid of (almost) all of my duplicated custom modified ToD code which is great.

I say almost because there's one bit left that I still had to modify, the T() function from TOD_Scattering.cginc (to allow the scattering to take distance into account when I apply it to terrain and other objects). I added an additional param - dist, which is a linear 0 to 1 distance value.

inline float3 T(float height, float dist = 1.0) {
float3 res;

.
.
.

// Rayleigh and mie scattering factors
// See [3] page 2 equation (1) and (2)
float3 beta = TOD_BetaRayleigh * sr
+ TOD_BetaMie * sm;

beta *= dist; <--- Inserted this line here

// Scattering solution
// See [5] page 11
res = exp(-beta);

return res;
}

If you feel the extra multiply isn't a big deal, and could add this, that would be sweet!

A couple of other minor things I found:-

• When including TOD_Scattering.cginc in my shaders (which live in a different folder than the ToD shaders), I had to modify the #include to TOD_Base.cginc in TOD_Scattering.cginc to use the full explicit path (i.e. #include "Assets/Time of Day/Assets/Shaders/TOD_Base.cginc") otherwise the compiler wouldn't find it. Perhaps there's a way around this I'm not aware of, curious if anyone else had this problem?
• With Progress Date enabled the time seems to stop advancing, unless the day length is set very short (10 mins or so). Not sure if this is a new issue or not, it's the first time I tried it.

Cheers,
Sam

 

I plan to do something with the clouds in 2.2!

I'll add a way to take the distance into account, ideally without doing the multiply for the default case.

Ah, that was a stupid mistake on my end. I can't hardcode the absolute path to TOD_Base in case someone moves TOD to a different folder, so I think it's best if I just don't include it in TOD_Scattering at all and leave including both cginc files to the user.

I'll check it out. I had some issues in the past with DateTime.Add not being accurate enough to properly increment the time for some frame rate / time progression speed configurations.

 

Quick question: Is anyone still using Unity 3 and doesn't plan to upgrade to Unity 5? Also, is anyone who's currently using Unity 4 not planning to upgrade to Unity 5?

Don't worry, I'm not asking those questions because I plan to immediately drop support for Unity 3 and Unity 4 as soon as Unity 5 comes out. However, I'd like to know if I could drop support if it makes sense to do so in the future.

 

We are on Unity 4 for our first game currently under development. We don't know if it will worth it to move it to Unity 5. It will depends on stability and compatibility issues that could arise.

 

So I've been using TOD for about a month, and I'm absolutely delighted with it- it looks great, and it's done everything I've asked of it. Given that though, I have one potentially obscure question- I've been using TOD's clock to drive my in-game time, so that the game clock matches up with the outside lighting. Specifically, I'm doing the following in Update:

TOD_Sky sky = GameObject.FindGameObjectWithTag("Sky").GetComponent<TOD_Sky>();
DateTime time = sky.Cycle.DateTime;
hours.localRotation = Quaternion.Euler(0f, 0f, time.Hour * -hoursToDegrees);
minutes.localRotation = Quaternion.Euler(0f, 0f, time.Minute * -minutesToDegrees);

This works mostly-okay, but I've noticed that the clock will tick inconsistently- each movement of the minute hand should come at even intervals, but it's been varying by upwards of a second between each tick, which is slightly disorienting and pretty easy to notice. I'm wondering if there is something about the way TOD_Sky calculates time that would cause this, and if so if there's a way I can sync up my game clock with TOD's without the inconsistency?

 

You're using 2.1.0, right? Do you have "progress date" enabled in TOD_Time?

I think this is related to the same issue mcmorry posted about which is caused by the fairly inaccurate time increment using DateTime and TimeSpan. This will be fixed in 2.1.1. If you're not on 2.1.0 then make sure to update since older versions used to update the time values in "one second in ingame time" increments, which could also cause the issue you're having.

 

Holy cow, thank you for the nearly-instantaneous response! I was indeed one version behind on 2.0.9, updating made the clock much snappier- after watching it for six minutes I think there might be the tiniest variability, maybe 1-3 seconds every 60, but that's too small to notice and poses absolutely no problem for gameplay. Thank you so much for the quick reply!

 

Regarding 2.1.1 release date: The changes are done, but I plan to test it a little more since we found and fixed two bugs yesterday that only appeared in-editor and only on Windows. My plan is to submit it this weekend so that it will be available to everyone next week.

 

Hi!
Thanl You for great pack!

I have one problem.
My trees on unity terrain engine look double.

How can i fix it?

 

This is a known issue of the Unity tree creator shaders in combination with Unity projectors. The workaround is to either use different shaders for your trees or disable cloud shadows in Time of Day.

 

Hi! The Skydome looks great, thanks!

One question: I've set wind speed to 0 and activated Dome pos to camera and Dome Scale To Far Clip (Dome Scale Factor = 0.95). Now when I move the camera in positive z, sky.Components.DomeTransform.position is automatically updated in TOD_Camera.cs, so the Skydome is moving with the camera. My Problem: The clouds are moving slightly (in positive z). They're moving faster, when I decrease the Dome Scale Factor. Why is this? (it would look plausible, if the clouds were moving in negative z, to have the effect of moving under the clouds, or I would expect, that they don't move at all, when the Skydome moves with the camera, so what makes them move?)

Best regards,
Chris

 

This sounds like it could be a bug - they're in fact supposed to move towards negative z if you move the sky dome in positive z. Is your sky dome rotated by any chance?

I'll analyze it this weekend and include a fix in 2.1.1 if it turns out to be a bug. I'll also add a checkbox to toggle this behaviour completely.

 

The sky dome was rotated! (I was a bit confused, that the clouds were moving at all, so an option to toggle this would make it clearer)

Looks much better now, thanks for your prompt help!

 

I analyzed the issue and it was in fact a bug that occured for certain sky dome rotations. The fix will be part of 2.1.1, which is still scheduled for Asset Store submission this weekend.

 

I just submitted 2.1.1 for review. It should go online within 2-3 business days.

 

I'd like to use a 2D (cubemap) skybox or 3D (second camera) skybox in addition to this great package but unfortunately the 3D skybox is proving a challenge due to some of the necessary image effects we are using and how they're implemented. Do you have any suggestions on how to use a 2D cubemap skybox with your skydome? I think it would just need to be rendered between Sun/Moon/Stars and Clouds, with atmospheric shading coming later as well?

Would love to hear suggestions. I am happy to tweak shaders, I've already familiarized myself with your system a bit.

 

A normal skybox can be used via the Unity skybox system by disabling the space layer of TOD.

A second camera can be used as a skybox by rendering space + any objects in the second camera and render the rest of the sky dome (i.e. in your example the clouds if I understood correctly) on the main camera afterwards. You can disable parts of the sky dome by disabling their game objects. You'll either have to use two sky dome instances or enable / disable the game objects in OnPreCull on the cameras. (I'd recommend the latter)

 

Hi,
Thanks for an excellent system!
We are having problems with TOD combined with rendered reflections. The approach we are taking is similar to the mirror reflections script on the wiki (http://wiki.unity3d.com/index.php/MirrorReflection3), but whenever we attempt to render both the skydome and terrain, the skydome ends up blocking the reflection of the terrain. I suspect this has to do with the code flipping normals for the rendering camera, but not sure.
We use the latest version, and as soon as I disable the skydome, reflections work as expected. Any ideas what might be going on? Thanks in advance!

 

A screenshot of the problem would be good. I have successfully used TOD together with the planar mirror reflections of the Unity water, so it cannot be a general problem and probably has to do with your shader or script.

 

It is hard to provide a screenshot that would be of help. When the skydome is enabled, all other reflections are not visible.
I understand the problem is probably related to the shader / scripts we use. Do you have any advice regarding specifics to look for?

 

I quickly recreated Aras's mirror setup and it worked fine with TOD. It is the reflection render script of ours (a modified version of the mirror) which has some weird problem... I am (not) looking forward to an evening of trouble shooting....
Thanks for the feedback.

 

Thank you for the reply. I think if I use the first technique you describe to draw a skybox I will have incorrect results for my desire. Primarily, I want to render some distant geometry (mountains), the sky generated by the skydome layers itself are great as is, I don't need to augment them with any additional skybox for effecting the sky.

So if I were to place a mountain skybox where you've suggested, wouldn't the sun and moon render on top of it? Maybe that will be ok...

 

sgoodrow: So all you want to do is render some mountains the the far distance? Because in that case you could just render the sky dome in the same camera your mountains render. Either that or render the mountains in the background camera and not clear depth before rendering your main camera, that way you can continue to render the sky in your main camera. You'll probably have to add some nice thick fog for the mountains for them to appear really distant. May I ask why you're even rendering 3D objects in that scenario, wouldn't it be easier and cheaper to just add some quads with high-res 2D textures of mountains on them?

Foxxis: Make sure your reflection camera renders depth, it's required for the sky dome to know where not to render.

 

I really appreciate how fast you're responding, thank you.

You're correct. That's all I want to do.

And you're correct that I would rather render some quads with high-res 2D textures (a cubemap) than 3D objects themselves. In fact I need to because of our constraints by our rendering pipeline.

So that specifically is my question. What is the best way to integrate a series of quads/cubemap which depicts some mountains into the TOD system? Use a transparent/cutout cubemap of the mountains and draw them before the clouds of the skydome (Transparent-451), placed on some geometry that fits within the skydome?

As usual, the skydome and backdrop geometry should be anchored to the camera.

 

What we did in Rust Experimental for our additional cloud and aurora borealis planes is create our own sky dome prefab (a copy of the sky dome prefab that comes with TOD) and attach some inwards-facing quads as child objects. That way they are automatically scaled and moved with the sky dome and we can render any custom shader we like on that geometry. I don't see any reason why this shouldn't work for mountains as well.

 

For those who haven't noticed yet: 2.1.1 is out!

I'm already working on 2.1.2 with full Unity 5 support, including support for some of the new ambient light settings - tricolor and hemisphere.

As always, please report any bugs you may find - 2.1.1 should fix everything that was reported up to this point.

 

This seems to be working well enough for us, but I am running into a clipping plane issue. I am rendering a cubemap, like a skybox, within the skydome. Since the skydome is matching the farclip plane, and the cubemap is rendering within it, it unfortunately can clip with some of the geometry in the scene. On the flip side, if the cubemap is rendered at the same distance as the skydome, then the corners are clipped by the far clip distance. The cubemap is moving with the camera, as the skybox does, to give the illusion of very large distances.

I think one solution is to render the cubemap onto the skydome itself, but I don't know the maths to do that... Any advice or resources are appreciated.