Time of Day - Dynamic Sky Dome

Been off for a few months but back now One thing that "always kinda bothered" me ever since you merged the "2 lights" into "1 global light" some time last year and is still present in the latest currently available version: the sun/moon lights now "switch on and off very sharply", I cannot figure out how to transition smoothly between them without going all pitch-black for a while. Sure their intensity decreases/increases a bit before/after the switch is made, but it's still sharply noticable. Imagine looking out at sea into the sunset with a lovely bright specular-reflection that all of a sudden just goes off --poof, god himself flicked a switch-- just as the moon light is switched on as well as its own specular-reflections of course. Just like *snap*? It's not a workable situation..

I haven't followed this forum while I was off so not sure if this was discussed.. btw. very glad to hear about the realistic "realistic moon-position" now possible! Now also possible to show it at day-time, I hope?

 

That is actually the reason the Unity water scripts allow you to set any transform as source of the specular highlight - can't you simply set the sun transform rather than the light transform? Here's the component of the Water4 prefab:

The moon can be visible in the late afternoon at times, but never at noon since the brightness of the sky is too high then. This could possibly be adjusted via scattering intensity though. You can provide feedback when the update is out and I'll look into it.

 

That's cool for me with the moon, no need for "noon moon" of course. I don't use Unity's water scripts but could do the same in my own water. Right now I fail to see how using the sun or moon instead of "the light" (for the specular-source transform) solves the drastic insta-switch that still happens, but yeah since I handcode my own shaders (except for the sky) throughout actually I have full control of all specular highlights and can come up with some smart trick before release time. So it's all good for me.

 

This sounds great!

Possibly at some point you might consider adding some Playmaker actions. That might help the people with minimal coding ability.

 

I think what people with minimal coding ability would help most is to learn coding. I usually don't look any further at assets when they have "playmaker compatible" in their description.

 

Well, you could render both sun and moon specular highlights, lerp between them or simply fade the specular highlight in and out by multiplying with the light source intensity.

I don't know what's required for Playmaker "actions", but Time of Day is pretty standard C# code. If Playmaker can access variables it should be able to access Time of Day parameters, no? I don't know anything about Playmaker, but I would assume accessing variables is something it should be able to do on its own.

 

Software that has Playmaker support includes: Final IK, Curvy, Daikon Forge, Master Audio, NGUI, Photon, PostFX Studio, uSequencer Cutscene Creator, Behavior Tree, and the "coming soon" list includes Mega-Fiers.

I don't see why Time of Day wouldn't want to be in a list with those assets. It might even be valuable as cross-marketing, for all I know.

I haven't used Playmaker, but I'm not biased against it. From what I've read in threads it seems those who use it love it.

Anyway, it was just a suggestion.

 

I personally feel like Playmaker should really be restricted to level designers for designing logic in a level (like buttons and switches and doors and such), but really IMHO should not be used much beyond that.
It's undoubtedly slower than actual compiled script, is more restrictive, and would probably be a nightmarish mess of spaghetti graphs for anything more complex than Pong.

 

As far as Playmaker actions for Time of Day would go, I imagine it would be of the "buttons and switches" variety, in that probably there would be a sensor for a "it's dark/light enough for streetlights to be on/off" type thing, and the rest would probably be extensions of the GUI in the demo, allowing the state machine to make it be clear, foggy, overcast or whatever.

 

Hi plzdiekthxbye,

I stumbled across this plugin while researching how to write an algorithm for detailed sun rotations for Unity - it appears that you have all this included and more! I apologise if these questions have been answered already, but there are a few things I need to know before I purchase:

1) Can you advise how accurate the sun location algorithms are? My Unity program is engineering focused and needs to include accurate shadow analysis so it is important that this is catered for.

2) I will probably link the lat/long/UTC to a dropdown GUI interface listing major capital cities. Would there be any issues with this that you could foresee?

3) Can you advise how the plugin handles multiple cameras? My typical scenes can have anywhere from 1 to 8 different cameras that are switched (dynamically enabled and disabled) through checkboxes on the GUI. If all cameras are tagged as Main Camera, will the sky show seamlessly on all cameras as I switch through them?

Alternatively, I could dynamically switch the tag on the camera to be Main Camera when it is enabled? Just thinking out loud here.

4) I will probably only need the sun options, not anything else (weather, moon etc). Can these all be disabled without any adverse affects?

Thanks for your time!

Michael

 

All orbital calculations are based on this article which claims its calculations are accurate within 1-2 arc minutes. I cannot guarantee that accuracy though since I didn't run any tests against real-life data.

You won't encounter any issues with setting lat/lon/UTC at runtime.

Multiple cameras are fully supported, if you run into any issues I'll make sure to address them.

Yes, as long as you make sure to disable the respective game objects and not just their renderer components since those are being set and therefore overriden by the scripts.

 

Hi,

I updated TOD to the new version and now I can't compile because the AmbientIntensity property for Day and Night is not available. Should I use the alpha value of the Ambient Color to have the same result?

Thanks.

 

Yes, sorry for not posting an official statement on this earlier.

 

Edit: resolved, my bad

 

I received a bug report today about an issue that caused the ambient light color to never fully lerp to the night value. I submitted update 2.0.7 as a hotfix for this and hope it will be reviewed before the weekend, but if that's not the case and you want to receive the update ahead of time, please feel free to contact me.

 

I'm having trouble getting the sun shafts working on my multiple camera setup. Here's what I've been using:

MainCamera - depth 0
ItemCamera - depth 1

I'd like to use the sun shafts component on my MainCamera so that they'll receive information from the depth buffer about where to cast. However when using the component on it nothing renders. If I use it on my ItemCamera then the shafts correctly render, but only use the buffer of that item camera. Any ideas?

 

I cannot really reproduce this issue. I added a second camera (depth 1) to the demo scene and was able to render some default cubes in it just fine without destroying the sun shafts.

However, I have an idea about what could cause this in your setup. Do you write something to the alpha channel of the color buffer in the second camera? Since the Time of Day sun shafts get blocked by the clouds by using the alpha channel as a sun shaft blocker, you could theoretically accidentally block them by writing to it in your second camera. To fix this you have to add ColorMask RGB to your custom shaders used in the second camera (most if not all default transparent shaders should already do this).

 

Technical question.. I realize why most shaders (sun, moon, clouds) need to be transparent but why does atmo itself need to be transparent?

Crazy as it may sound, I might have a good usecase for the atmo as an opaque shader, related to http://docs.unity3d.com/Documentation/ScriptReference/ImageEffectOpaque.html ..

 

The atmosphere has to be transparent for the stars to be visible at night. You could blend the star texture directly with the atmosphere in the atmosphere shader, (I used to do it that way) but then you cannot use Unity skyboxes with TOD anymore, which is why I won't force it on everybody.

 

Thanks for the nice Update Interval feature. I do have a suggestion for that:
Add the option (or make it default) for the SUN to move separately from the actual light source. This way, if you have the light position update once an "hour", it doesn't look weird to actually see the sun move from one place to the next. The sun could move smoothly along, while only the light/shadows make the transition from time to time.

 

What benefit does Unity sky boxes get you? If the sky box has clouds it seems like it would look off against any TOD clouds, since the TOD clouds move, but the others wouldn't. TOD skies are already very nice, so I'm confused by what a sky box would add...

 

actually, lightly blending tod sky with a skybox in the background might be interesting. Distant clouds and landscape, faintly visible.

 

That's a great idea.

People wanted to use the Unity skybox or their own custom skybox system at night. So the skybox would just hold the stars and TOD handles clouds and the atmosphere.

Also a nice idea, though that's not possible at the moment. For now it's really just meant to be used with a custom night skybox.

 

I'm doing all kinds of crazy experiments lately and since I already have full control over all my lighting shader-code in a (homemade "deferred") lighting pass, I was thinking I should be able to get cloud shadows without projectors.

Here's the idea: the fullscreen shader could get fed the same B&W cloud texture as the skydome, I can also get the current scales and animated UV offsets via script into the shader which also knows the sun/moon light direction. So determining per-pixel whether a cloud occludes the sun-light would be a single tex2D fetch once I figured out the tricky part of where to sample into the cloud texture, without replicating too large a part of ToD logic already existing somewhere. I figure to account for the dome-ness I would have to somehow sciencily-mathily warp the vector in some hemispheric or icospheric or other-spheric fashion..... Will get to play around with this idea in a while with some neat B&W debug texture for the clouds layer, but ANY helpful hints or pointers or warnings you as the well-experienced sky guy can give me already off the top of your head... just shoot

 

I'd recommend having a look at the cloud projector shader since it basically also simply projects the cloud texture on a surface. The calculations I added deal with the texture offset and all that stuff in order to correctly wrap the texture onto the world so that the shadows fit the clouds. One thing you might want to dig into is how the _Projector matrix is calculated internally since that basically contains everything a projector does.

 

Why am I unable to modify some values in the inspector, like the light intensity? It seems like at some point I was able to set that manually? Was this changed? I have run into others, but that is the value I keep needing to change?

Also, often the entire sky goes white in the inspector and I need to hit Play to refresh it. What causes that and how can I stop it? Please advise, thanks.

 

You can set the intensity, but you have to do so via the TOD_Sky script inspector variables and not directly on the light source, since you can set different intensities for day and night. The same is the case for shadow strength.

I noticed that as well, it seems to be some weirdness with when Unity calls scripts that are marked as ExecuteInEditMode. It was introduced from when I changed the way I modify materials. The point of that change was not to store the values set in the inspector in the material file itself to keep it from showing up in version control as "edited" all the time. If it bugs you that much I'll investigate this further as soon as I find the time to see if I can get rid of it. By the way, you can also simply select the camera in your scene to refresh everything since Unity seems to call all ExecuteInEditMode scripts again when you do that.

 

A quick survey: Is anybody still using multiple instances of the Time of Day prefab that are enabled at the same time for some reason? I'm tossing around the idea to replace the need to set the TOD_Sky references on the camera scripts manually by adding a static TOD_Sky.Instance accessor that can be used by other scripts to get the currently active Time of Day prefab in the scene.

 

I don't as of today, and I never might, or in some crazy context I might find a need for two different sky-domes running at the same time (who knows, anything is possible, perhaps the player sitting outside watching on a big screen a rendered-to-texture "live video" from the other side of the planet?!).. I would say it's "good component-oriented citizen behavior" to not be static and allow for many coexisting unique instances, even if only 1 instance is ever used in 99% of cases.

The script components that are attached to the game-object that has the todSky component shouldn't have any issues finding their todSky anyway on init... so as far as I can tell that only leaves todCamera for this minor "inconvenience", right? Don't think it's a big deal, although I'd design it to have todCamera components attach to todSky instead of Camera game-objects, then either specify/select one or more cams for this --- or allow multiple todCamera on the same sky game-obj with each letting us select a given camera.

Now about that good old "earth-shadow-in-atmosphere" idea....

 

True, I do hate that you have to set two references to the sky dome on the camera at the moment though. And forcing people to always use TOD_Camera with TOD_SunShafts to at least bring it down to a single refence might also not be the best solution.

I'd love this as well, but that doesn't really work since I have to use OnPreCull in TOD_Camera, which is only called on scripts attached to a camera.

Haha, yeah. Sorry about that, I just never seem to find time to dive into this.

 

Recently implemented ToD into our project and loving the results, I saw earlier that you mentioned a potential volumetric cloud package, I was wondering if there's any more news on this.
Cheers.

 

That roadmap was pretty much invalidated when I got hired by Facepunch. I still plan to add volumetric clouds one day, but if somebody else decides to put his implementation on the Asset Store (compatible to Time of Day, similar to the weather system that's already on there) I'd be more than thankful.

 

Woah, you were hired by Facepunch?
Nice one, man!

EDIT: Wish I were hired by Facepunch.... but then I'd have to move to the UK... :c

 

Doesn't seem to matter how I add this I always get that blue circle, unless the dome is really tiny but that defeats the purpose. Anyway yo fix this?

 

In scene view, this can easily happen even with the sky-dome scale set to 9999. In game mode, this shouldn't happen as long as you keep the skydome's position such that it is centered around the current camera position and its scale such that it matches or slightly undercuts the current camera's far-plane setting. You can attach the Tod_Camera component to the camera to effect this easily.

No matter how "tiny" you may feel your cam's far-plane is, by definition if the sky is the same scale or slightly smaller, it's big enough. Nothing outside the cam's frustum exists anyway as far as the viewer is concerned.

 

Skydome and camera are positioned exactly together and yet I still get that horrible blue circle. Doesn't matter where I place that dome I get that effect. I tried to reinstall it and I still get the same issue. This is so annoying.

 

It's because the sky dome is larger than the camera's frustum. Either increase the frustum or scale down your sky dome.

 

How do I change that?

 

Read https://docs.unity3d.com/Documentation/Manual/UnderstandingFrustum.html and then adjust your camera's "far plane" setting to the "scale" setting of the sky dome. Once this is grok'd, you can later also do the reverse. As I said, there's a helper component TOD_Camera that you can (and should, given your grasp on "the basics" so to speak) attach to your camera. Have you? ToD cannot do that automatically for you AFAIK.

 

Yes I dropped that in already, will read up, thank you.

 

Question about Audio/Render/Light at Night/Day.

"Night" seems to start at 20.7.
For audio, this isn't particularly ideal, as it gets dark long before sound switches in my scene.

Is it possible to change when "Night" starts somewhere? The fade doesn't really help, and the scripts don't seem to set the night time.

Cheers

 

Hi
Need your help. Guess I am just too blind to find it, but I can't find the right light source generating daylight and night light. I bought a new tree detail renderer from the store that allows me to generate all tree shadows of a terrain in one draw call. In order to use it, I need to determine the light source (by dragging and dropping it to a "public" field in the inspector). I tried a lot of objects, starting with the sun itself up to the object in the sky dome that is called "light". However, the new shadow renderer will always tell me that the determined object is no light source. So what IS the light source in the sky dome , then?

Thanks for your support!

 

What tree detail render was this please?

Here's the light source:

 

It's 100% the "Light" sub-object inside the Skydome game-object. Report a bug to the author of that tool, because this sub-object is a perfectly valid "Directional Light" component container.

 

Hey guys, thanks for the quick replies
It's the "Advanced Foliage Shader v.3 I am talking about.
Maybe you can recommend another shader that actually works
We need to reduce draw calls... badly!

 

Can i use this with Skyshop ?

 

The time that's being used depends on Light.Falloff. I could add an inspector variable to the scripts to modify the threshold value if you can't get the results you want by tweaking Light.Falloff?

As far as I know it works with Skyshop, though lighting differences at day and night is something Skyshop has to handle if you want to use the dynamic day / night cycle. That means you have to bake multiple cubemaps and switch (or blend, if Skyshop supports this by now) them depending on the time of day.

 

If you could that would be great, I wouldn't have a clue what to change here?:

Code (csharp):

1.  
2. float c = Mathf.Cos(Mathf.Pow(sun_theta/(2*pi), 2f - Light.Falloff) * 2*pi);
3. float m = Mathf.Sqrt(708f*708f*c*c + 2*708f + 1) - 708f*c;
4.  

 

I wouldn't edit that calculation. I would rather do it one of those two ways:

EITHER #1 AudioAtNight.cs, line 28 - modify it that instead of checking for sky.IsNight you check sky.LerpValue <= x, where x is in the range [0,1] - 0 being full night (the same as sky.IsNight). You might also want to edit AudioAtDay.cs accordingly.

OR #2 TOD_Sky_Variables.cs, line 93 - modify it so that instead of checking for LerpValue == 0 you check for LerpValue <= x, where x is the same as I described above. You might also want to adjust IsDay in the same file accordingly.

I'm not sure which way I'll do it, it seems like IsNight returns true slightly too late for most cases, so it could make sense for me to modify its calculation as described in #2.

 

Ah okay, I have no idea how to do that.