Time of Day - Dynamic Sky Dome

Thanks lots! Um I don't wanna be a pain but you know what would be REAL cool? A similar func like FogColor() and AmbientColor() but one that approximates the current color in the "top pole of the sky hemisphere". Would be useful for various things! I know (well presume) the calculation is hidden somewhere in the atmo shader.. might be tricky to extract from shader-side to script-side (unless it's already there) but if it's not too much trouble, it would be VASTLY better than having to do a texture read-back from screen (or rendertex) down to the CPU side..

 

Wouldn't be too hard actually, I will need something like this to disable the space object anyhow. For all of those values - would some properties also suffice? Because I have to calculate the results of those functions once per frame anyhow, no need for the user to recalculate them a second time just to get the fog, ambient or sky color.

 

Do you recalculate fogColor every frame even when SetFogColor is off? AmbientColor() doesn't seem like much computation but yeah if this is calculated every frame, then indeed a cached property for this should be good. Same for fog, if it is computed regardless of "SetFogColor"..

 

I only calculate it if SetFogColor is set to true. I could make it in a way that in the property the result of this calculation is returned or, if SetFogColor is set to false, the result will be calculated when the property is being accessed. This would maintain the fact that the calculation is being done once a frame at max but not if neither SetFogColor is being used nor the property is being accessed.

 

That sounds pretty good! Still might wanna expose the core recalculation function as internal method though ... depending on how much crazier stuff gets regarding performance over here, I might have to grab tod_sky color functions only every 2nd or 4th or 8th frame. With a slow "day length" such as 24 or 48 or some such, and for the use-cases I foresee, computing fogColor only every other second and lerping between the old and new value should be just fine. Again, ambient is trivial computation-wise but fog looks a bit heavy, seeing how my current mobile devices already heat up massively with the stuff I'm doing. (They don't reduce the framerate at all though, they just get worse and worse at precision somehow, pretty odd. )

So yeah, your approach sounds perfect for "an easier one-click quickstarter to new ToD users" but just have the core computation funcs as internal or public because folks might have to time things differently. My fog for once will definitely be some lerp between the current FogColor() [[which seems like "just" the horizon color but this is totally fine and definitely good to have]] and the upcoming SkyTopColor(), plus more contributing factors way later on.

 

You could actually also do this with properties. They would only recalculate their values if you access them or if their results are required to update the fog color. So if you read from the property every 30 frames the color will be calculated eactly that often. Now that you're talking about it - it might be feasible to expose a fog color bias value that would mix the fog color between the horizon and zenith color? Just as another parameter in addition to SetFogColor.

 

True about the property, strange it didn't occur to me

The bias sounds like a really cool idea too, as long as it's still easy to access/compute the separate color (either zenith or horizon aka "fog") unmixed with the other, should the need arise. (As in, not using a bias of 0 or 1 but have ToD still calculate both -- just keep exposing the raw unmixed source colors too).

Woohoo, I'm so glad we're getting a ZenithColor() soon

 

Now that we're geeking out here, there's another thing I was wondering.. Right now the fogColor is essentially the horizon color, but that itself is viewer-orientation dependent. Are you grabbing camera-lookat for fogColor? I mean in some instances at dusk/dawn the horizon is red in one direction but black in another at the same time. Ever considered taking this into account for the "fogColor" approximation? Or maybe it's already happening, haven't fully tested the scenario, just something that just occurred to me..

 

Yep, sounds like this would fit in just nicely. I will provide properties for horizon, zenith and ambient colors. The fog will then be set using a lerp between horizon and ambient if SetFogColor is true, depending on the bias.

From my experience those kinds of things will look really awkward when you move the mouse around as the field of view of the human eye is generally too high for things like this. However, I don't want to exclude this without testing it first, so I guess I'll add a sun color sample property as well and give this a shot.

 

In terms of "geeking out", what may be desirable would access to the core constants of all these calculations - the atmospheric density and amount of moisture/ice in the air. If I'm correct, those two values can be used to set up the bulk of the scenarios color-wise, the rest needing solar color and perhaps light intensity.

Having a "thin" sky like on Mars would certainly affect the appearance compared to Earth. No doubt an atmosphere denser than Earth's would lead to it's own effects. Imagine Titan, perhaps on the rare case where it's "smog" is not totally obscuring the view.

 

So, I just implemented a method to sample the sky using any view direction in world space (e.g. Vector3.up or Camera.main.forward) and made the fog use the camera vector projected onto the horizon (y=0) as the fog color. Looks surprisingly good, almost completely fixes the issue with the fog being off when looking directly into the sun!

Given that I will probably expose this method to you guys I guess I can cut back on the properties as you can just sample whatever direction you want using it. This and a way to directly access the ambient color should cover all your needs. I also just implemented the fog bias to influence its automatic calculation (horizon vs. zenith).

I'll reevaluate which parameters can be exposed in a useful manner and report back on this.

 

zOMG is christmas early this year!? plz-pushtoassetstore-asap-kthx-omg

 

Hi, did some testing an the error persists in the windows standalone build as well. Building a scene (within the same project) using only TOD (standalone and editor) do show up the same behavior as well.
Creating a complete new project with only TOD does not show this behavior. Completely in the dark where to look for pinpointing the source as it can't be the scene as a new scene within the project is having the same problem but starting a project from scratch with only TOD doesn't.

 

Well, it's certainly good to hear that it's not a hardware issue, that would have been extremely painful to pinpoint. Let's try and find the cause.

In the new project, please make sure that all of those player settings work:
- forward deferred rendering
- linear gamma color space
- static dynamic batching

I assume that you tried the unedited demo scene or at least the demo scene with the same changes (you had to add an object to test with as you stated earlier) in both projects?

From that point on we can start comparing your "Edit -> Render Settings" and "Edit -> Project Settings -> Quality" - you can just make screenshots of those for both projects and send them to me. I can then try to reproduce the error in my project.

 

Did sync all settings in the new project but no luck so I played around in the actual game scenes and noted that when I set the quality back to Fast iso Fantastic the issue is gone.
So I investigated further and the issue disappears between the qualities Simple and Fast, so I checked all the settings on Simple until the issue was gone. The source seems to be the Shadows setting. When I activate them from Disabled to any other setting the issue pops up.

 

Try setting up your shadows as "Hard and Soft Shadows", "High Resolution", "Stable Fit", "Four Cascades" and "Shadow Distance 100" - those are my settings with which I don't seem to be able to reproduce the issue. I added a default block to the terrain demo scene as a testing object and no matter how often I play the sunset / sunrise I cannot see it flicker in any way. What object are you using to see this happen?

 

I'm using the standard cube (size 3x3x3) on the terrain demo scene. I'm trying to reduce my project down to the essential assets so I can provide you with a testcase.
First attempt failed as I removed the Standard Unity assets as well and after reimporting them the issue was gone

Edit: a second attempt revealed there must be a non unity asset involved that triggers this behavior. Trying to pinpoint it by removing folders until I can put a finger on it (this is a real hell as my project folder is 13Gb and consists out of hundred of folders).

 

Thank you very much for doing this.

I think I can update you on the release schedule now. I plan to release 1.8 in the early days or weeks of November. In 1.8 I want to move the API documentation over to Doxygen. This means it will contain a PDF documentation file of all classes, methods and variables. I will also host a HTML click-through documentation on my website. Furthermore, 1.8 will contain all tweaks and fixes you guys reported and some fairly major new additions, most of which were discussed here.

 

After a long search I found out that the TriPlanarTerrainScript.js provided by the Medieval Environment asset (Michael O.) is triggering the flickering. Unfortunatly we use that shader for our terrain rendering

 

Hi plzdiekthxbye,

Did you ever test your asset with any of the advanced terrain shaders? I replaced the TriPlanarShader with the ats colormap ultra terrain shader but I'm having again issues whe the sun is setting, the objects are now not flickering but at the time the sun sets the water planes are drawn on top of the screen for a little instand. May I suggest you test your system with such terrain assets as I did a lot of changes just to see the problem is only shifted to another one. So I must pinpoint your asset as beeing the source of the problem iso the Triplanar or ats colormap shader.

 

Well I'm myself a ShaderLab noob but my guess (for ModMonkeys) regarding the flickering is -- "Transparent" RenderQueue ordering.. always a pain to make this work with other external 3rd-party shaders, but doable..

 

Are you using the Unity water shader? It sounds to me like as soon as you have two directional lights that switch their active states your scenes break. Please try disabling the following sky dome child game objects: "Atmosphere", "Clouds" and "Space". This will not draw the sky dome - if the error persists it's clear that those thrid party shaders break as soon as you disable / enable a directional light, which would mean you could work around it by leaving both directional lights active at all times (which will double your draw calls though IIRC).

However, I could then work around this by only using a single directional light and attaching it to either the moon position or the sun position instead of two directional lights that are being enabled and disabled as needed. All this would require would be another child game object with just the directional light attached to it, which I could easily implement and include in the next update.

I don't think this is the issue as everything works just fine as long as the active states of the directional lights remain unchanged.

 

Uh-oh I sense breaking changes incoming keep in mind I currently do automatic brightness adjustments based on the states of both lights and their intensity. I essentially up the overall image brightness / exposure in post-process whenever we're between dusk and dawn. This works well.. I guess I can do the same just fine when we only have one directional light, but will the fading be just as smooth when the "two" lights (now just one) have substantially different colors assigned? Well, guess we'll find out

 

I also monitored solar/lunar brightness, when I did my own ambient light controls. Now would only be interested in light levels for clouds - used to adjust tint of smoke, etc. on the ground.

Right now, there is no shader in the stock Unity bundle that can automatically tint smoke or mist according to local light conditions. Having one would be a huge improvement to our ability to create realistic scenarios.

 

Yes I'm using the Unity water shader. However leaving both directional lights active and so doubling the draw calls don't seem a good idea. I'm in the progress of converting to RTP3 (removing ATS again) to see if the issue persists. I'll keep you updated on the progress and will post my findings.

 

Both colors will still be exposed as properties, just the directional light will only store one (interpolated) color. As you talked about this earlier: 1.8 will add a horizon height offset parameter to handle different viewer heights and a contrast parameter to adjust the contrast of the sky (no need for you to use LDR + linear lighting as a workaround anymore), both of which come at no performance cost. I also improved the cloud shading on all quality levels and saved one draw call at day (space) and one draw call at night (moon halo) - the sky dome now stays between 2 and 4 draw calls at all times. Oh and by the way the changes to the moon shader you requested were also implemented as I added color and contrast shader parameters. Oh and also the weather visuals were completely reworked and... ah well, I don't want to spoil all the surprises just yet!

1.8 will bring some nice additions in this direction, I reworked a lot of how this was handled as I'm now using the physical scattering system for both the nighttime sky as well as the daytime sky and I disliked the way I had to work around a couple of things (this simplifies things and is actually faster than handling two separate cases). I might be able to send you a beta version for testing purposes soon so that you can have a look at the scene you talked about in your last mail. I will be at university the next two days though, so the earliest date you can expect this will probably be the upcoming weekend.

As I said 1.8 should work around it by simply using a single directional light instead of disabling / enabling two directional lights as needed, leaving both directional lights active was just a suggestion for a temporary solution.

 

I too have the flickering as described above (at sunset / sun up) in a very simple test project. It consists of:
- Mesh tree from the (free) Unity Terrain Assets
- a couple of primitives (cube + sphere)
- Unity Tree Creator Tree with a "Nature / Tree Creator Leaves Fast" shader

It occurs when I have the rendering path set to deferred. Using forward rendering eliminates the flicker.

Edit: Eliminating the Tree Creator tree eliminates the problem even with deferred rendering. So something is going awry with certain combinations of shaders + rendering paths + Time of Day.
I do not want to be harsh, but from my limited research into this problem it does seem that ToD is the common denominator.

Besides this problem (which I am sure can be solved or worked around) the system seems great! Keep up the good work!

PS. If you would like to have my test project for your own testing, please just let me know.

 

I sent you a PM with my email so that I can test if the changes I made in 1.8 fix the issue in your scene.

 

Thanks for the test project. I was able to reproduce the bug and simplified the project as far as possible. However, I could remove all Time of Day assets and reproduce the bug using only the following setup:

• Deferred lighting + shadows enabled
• Transparent/Diffuse material on default plane in background (any other alpha blending material also seems to cause the bug)
• Diffuse material on default cube and/or sphere in foreground (any other material also seems to cause the bug)
• Directional light with shadows enabled and a light intensity less than 0.01 (e.g. 0.001)
• Tree made with the Unity tree creator visible on screen, receive shadows enabled

Result: The shader TreeCreatorLeavesFastOptimized causes the transparent plane in the background to be rendered over the opaque objects in the foreground. If I change any of the components on the list above the bug disappears, even if I just toggle receive shadows in the renderer component of the tree made with tree creator.

I think I should submit the scene as a Unity bug. If it is in fact a bug (rather than intended behaviour due to some optimization in the leaves shader) they should fix it, but until then I will try to find the best way to work around this. So far a decent solution appears to be disabling "receive shadows" for trees made with the Unity tree creator if you cannot switch to forward rendering in your project.

I could also try to work around it in the next update for Time of Day, but the only thing on the list above I can actually control is the directional light intensity. If I never let it fall below 0.01 I could work around the bug, but this might be too bright to switch the directional light direction from sun to moon. I will investigate this further in the upcoming days, if anyone of you has some thoughts on this please let me know. I can send the test scene to anyone who wants to observe this for themselves.

 

Wow this all sounds like a massive upgrade, now I'm incredibly excited really lookin forward to it..

 

Am also looking forward to this upgrade.

About the thought of just keeping the light level above 0.01 to avoid the problem... I do need situations where we have totally dark darkness, having some residual light would spoil the scene. It is better in the long run to have Unity correct their bug and allow for inky black nights.

 

Black screen overlay as a temporary workaround then

 

Seriously, I need to make my scene totally without external illumination. No overlay will do, since players can use illumination shells, flares, glowsticks, etc. to change the lighting level.

 

Not sure if OP has seen this:

http://dmg3d.blogspot.com.es/2013/11/atmospheric-rendering-for-dynamic-light.html?m=1

But if not, might provide some pointers or fresh ideas on the whole atmo/fog color and earth-shadow-in-atmo topics

All looks a bit too computationally-intensive for us mobile-first speed-freaks, one of many areas where ToD truly shines.

So if useless/not-needed, then simply discard

 

Pretty much the only things left to do for 1.8 are the light source intensities (I'm still thinking about this in order to make it suitably customizable) and some performance testing. The overall visual quality also improved a lot and I'll have to make new screenshots to demonstrate this in the store. All in all I'd say a release some time next week or the week after that is realistic.

 

Sounds very good! I have so many "Baustellen" open right now, another week or 3 doesn't phase me too much -- though I'm still excited about the coming update ^_^

I noticed mobile hardware is developing much more rapidly than my own sorry project ever will as such, I'm no longer concerned with triangle counts etc. Will probably upgrade from the low to the medium prefab.

As for the light intensities, all I require is that it doesn't go to almost zero during "empty moon"..

 

How do I change the color of the light? I can't for the life of me figure this out. I'm not to happy with the standard white, I want a bit of orange in there. How d I do this?

 

"Sun -> Light Color" defines the light emitted by the star itself, this light travels through the atmosphere and is being increasingly modified the higher "Sun -> Coloring" is, which is especially visible at dusk and dawn (reddening of the light).

 

Looks like the bug has been fixed in Unity 4.3! If anyone still experiences this issue even after updating to 4.3 please contact me. I myself am no longer able to reproduce it.

 

Issue seems to be fixed after upgrading to Unity 4.3.

 

For the next update: entering a light intensity higher than 1 for sunlight seems "forbidden" right now, due to Mathf.Clamp01 in TOD_Sky.cs line #785.

Possible to give us more freedom there? Even if it's just the freedom to screw things up doing some experiments with "high-intensity-lights + low-intensity-albedos" setups..

I commented the Mathf.Clamp for now and with a sun intensity of 1.5 so far I don't notice any ill-effects --- lemme know if there's any dangers in proceeding further down this part =)

 

+5 to this idea. There are definite cases for brighter sunlight levels in some situations.

 

And here's another little request

So I needed the _SunColor in a custom shader of my own that takes into account some atmospheric coloring. Specifically not the default "sunlight color" that I specify for the ToD main object, but the dynamically changing _SunColor you're computing once when sending to the atmo shader (and again when FogColor() is called).

So right now I changed this from a function-local variable to an internal field (and then reuse this in FogColor() instead of re-RgbPow()-ing it in there) so that I can later in a custom script send it to my shader as well --- could something like this make it into the next update so that I don't need to patch my copy every update? I'm rather confident that this would neither break anything for anyone, nor otherwise interfere with or confuse anyone's normal usage.

Alternatively, and this would be even cooler, you could change this from a shader-specific uniform into a "Shader global vector" (Shader.SetGlobalVector()) -- either still called _SunColor or namespaced such as _ToD_SunColor or something. This way I wouldn't even have to send it to my shader; instead it could simply declare the uniform as well and thus pick up that global vector automagically. Neat for reuse, also saves a GL call afaik.

So either one of those two approaches would be much appreciated

(Side-node --- might I also enquire whether it would be at all feasible to change your "private members" (nah, not those ) to internals? Makes all kinds of hacky hacks easier and doesn't really impair overall usability or stability or normal use-cases..)

 

Seems like metaleap and I are leading the requests for changes at this time. Perhaps the three of us should get together and define some form of API that would be useful for all of us.

My interest is in exo-solar scenarios - so ability to feed data into ToD about the orbit of the planet and star size/color are important. I too desire access to filtered light in order to tint smoke and other effects appropriately - but realize this may be complicated by light angles changing the color. If so, at least the color from current minimum path through the atmosphere.

In my library I have simplified many aspects of creating realistic explosions by adding a front end interface that allows the user to use chemical composition, mass, and geometry of the charge. Perhaps ToD might do something similar - allowing user to set atmospheric density and dust/fog levels in convenient form then using those data to do the internal Rayleigh/Mie settings. Any thoughts or opinions??

 

Earlier in this thread somebody already requested this, it's in the 1.8 changes.

I thought about this as well and I'm not quite sure yet if global shader parameters would be a good idea for this. I'll see to address this one way or the other though.

I assume you're talking about betaMie, betaRayleight, etc.? While those could be exposed to the user I would highly discourage using them as there are some freaky things being multiplied into those variables to save instructions in the shader. Regarding color values I completely agree with you, but I think some values really shouldn't be touched by the user.

All color values will be accessible in 1.8 - for the underlying atmosphere paraemters the main issue is in fact the integral that has to be calculated for light rays traveling through the atmosphere. 1.8 overhauls this as I found some further information on the approximation I'm using, leading to increased visual quality and physical accuracy.

 

Dev update: 1.8 (I might call it 2.0 when I actually upload it to make clear that iot contains some fairly major API changes) is now in beta testing. The first results look promosing, but I don't want to haste the release and give me and the testers some time with it to find and flatten out any minor or major issues.

 

can i set custom skybox like stars ?

and can you take some screenshots of the editor ?

 

Using a custom skybox is possible, you can even use the Unity skybox system if you like.

I will update the screenshots (and add some of the editor) when I release 2.0, which will be ready for submission later this week.

 

I just submitted version 2.0.0 for review. It will be a major release with quite a few API changes, so make sure to backup 1.7.3 in case you run into any issues. Please do a full update by deleting all old Time of Day assets and then importing the new version as both the folder structure and the prefabs changed. The changelog is available here, as is the new online documentation and manual. The updated web player can be found here.

I'm also pleased to announce that, in order to increase its user base, Time of Day will be 50% off as soon as the update was processed by the Asset Store staff. This price drop might only last for a limited time if I decide to slowly ramp the price back up at some point in the future. You can see it as an experiment to evaluate in how far this has a positive influence on sales. My primary goal is not to make a lot of money with Time of Day but rather to be able to sustain its development for years to come while helping out as many people as possible in making their games. I hope that the price drop will increase sales enough for the income to stay on approximately the same level as it is currently at, with the added bonus of having a bigger user base to get feedback from.

Thank you to the beta testers who took time out of their own schedule to make sure that 2.0.0 will be the best release of Time of Day to date.

 

Well ToD was already way underpriced for what it does ... lowering the price is fine for a while and it will certainly give you a wider user-base, but a word of warning, cheaper users on average usually have also a tendency of throwing way more, and way crazier requests at you, plus will require a lot more handholding. but this is just anecdotal from other packages I've seen go down this route, "this time might be different" and you're of course welcome to do your own pricing/exposure experiments on your product just wanna caution you.. don't lose hope when the looney stampede arrives. Already excited (well) to see SOULSSAGA's insane antics pour over our charming quiet little corner of Unity dev

BUT I'm here with a question regarding the new SampleAtmosphere() API function. Per frame I need to do exactly three samples.

- The 1st one is fairly easy: the "north-pole" / top corner / zenith of the skydome. I use Vector3.up for that and I'm golden. This always takes the additive color into account right? So at night I'm not getting pure black unless my additive color is 0,0,0?

- The 2nd and 3rd ones are a bit trickier. Essentially I need the 2nd sample to always peek right in the middle of the "brightest corner" of the horizon, bright defined as any glowing aurora or afterglow or preglow of sunlight, "if any". In other words, unless the horizon is uniformly the same color (might be the case at night or noon in some locales), some parts of the horizon will be brighter than the rest and I need to sample right into the brightest direction then: so vec3.y would be 0 as I'm hitting the horizon directly, but I have no clue how to really always poke right into the middle of the "glowing aurora" (no matter how strong or small it is) of the sunlight, if present at all. Of course it's very easy to do during daytime, I just go by the LightDirection:

Code (csharp):

1.  
2. mySky.SampleAtmosphere(new Vector3(-mySky.SunDirection.x, 0, -mySky.SunDirection.z).normalized)
3.  

This works perfectly fine at day, but breaks as soon as the moon is taking over, then it seems like SunDirection is actually "CurrentDirLight_Direction"? Also as long as there's still some portion of the horizon lighter than the rest of it (only if-caused-by-sun is of interest here, even if the sun is inactive, as in post-dusk-glow or pre-dawn-glow), I'd need to really just figure out the xz-direction of the middle of that light aurora, regardless which light is really active..

- The 3rd would be easy again, just the opposite of 2nd --- once I have a good heuristic for the above, I can neg that beast and good to go.