Time of Day - Dynamic Sky Dome

I realize this, but even the best package is pointless if only a fraction of users actually know about it and use it. I feel like I can deal with crazy requests as I always first evaluate the options proposed by the community and see if it would actually make sense (also known as putting things on "the list"). I stated over and over that the target of Time of Day is to be the best dynamic sky dome on the Asset Store, no more and no less. To achieve this a certain amount of feedback is required. I also had a very positive experience with the summer sale.

A note for the other users reading this: metaleap is a beta tester and is already talking about the 2.0.0 update.

Correct. Additive color and night sky multiplier have to be 0 for this to return black (the multiplier clears the scattering, additivie color is the artsy customization parameter).

I just double checked this and SunDirection correctly returns the sun transform forward direction in world space, so your example code should sample the horizon at nearest point to the sun (or as you called it the brightest point). I threw the code into my testing environment and the logs seem to verify this. With the default sky dome parameters it sampled RGBA(0.938, 0.994, 0.970, 1.000) at noon, RGBA(1.243, 0.894, 0.696, 1.000) at 18 o'clock and RGBA(0.208, 0.243, 0.277, 0.594) at midnight. The only special thing to note here is that values greater than 1 can occur (in the shader those are only output if HDR is enabled and can be used for HDR bloom or tone mapping, otherwise they are automatically clamped).

 

Just received the mail that 2.0.0 was processed and is now online. Looking forward to what you guys think!

 

Awesome, upgrading right now!

 

You're right, guess I was a bit tainted overall yesterday should be good for more exposure broader userbase ^_^

 

congrats on new release!

happy holidays!

 

Good to hear! Let me know what you think.

You brought up some valid points, but the advantage of more users and therefore more feedback outweighs those disadvantages. I appreciate any kind of feedback, even feedback on pricing, so I'm thankful you brought it up.

Thanks, happy holidays to you too.

For those of you who have twitter, please retweet my release tweet to spread the word. Also feel free to follow me on twitter - I don't tweet a lot, but if I do it's worth reading.

 

From a first look, the upgrade is very very interesting and the overall quality is definitely better, but I've seen some issues:

1. the moon has no more halo. How to get it back?
2. the clouds projected shadows are completely out of sync with the clouds passing in front of the sun or the moon
3. having only one light source now, I can't disable the shadows only in the night (for performance reasons I'm projecting shadows only from some lights near the camera disabling the moon shadows).

Thanks,
Maurizio

 

You could copy the material and shader from the last version, I'll add a new and more optimized halo in the next update.

For night the shadows are in fact incorrect and I'll see to fix it, for day I'm not so sure but I'll investigate and test.

You could easily write a script that disables and enables shadows at day or night. Have a look at the "Examples" folder, there is a script that enables and disables renderer components according to day or night. It essentially only involves checking for IsDay and then enabling or disabling the shadow property of the light. I could provide an example script to do this in the next release.

 

Ok, I can wait for the next update

I was just running your example test and I had the sun in front of the camera, with no clouds in front of it, but all around there were projected clouds. Could it be a problem of scaling? because you are projecting the whole sky on the ground, but if the ground is only 10 km of radius, than all the clouds of the sky (that should be huge, as the planet) are projected inside a small area.

Yes I can code it, no problem. But could be easier to have just two checkbox in the Dome settings (sun shadows on/off, moon shadows on/off)

 

Yep, found an issue in the calculation. Thanks for reporting it!

I think I will make it that the shadow type of the light will set to "No Shadows" if the strength is 0. This way you can set Night.ShadowStrength to 0 and automatically get the performance optimization boost at night. I will also change the cloud shadows to behave this way.

 

It's always a pleasure to report issues and suggestions to you. Your support is really great! Thank you!

 

Howdy,

There seems to a problem with what I think is the Projector or cloud shadow shader. It's drawing an outline of the trees, which does not bend with the trees. It goes away when I disable or change the shader on the Projector gameobject. With depth of field enabled on the main camera, it's blurry like it is in the screenshot, but when it's disabled it's very sharp and pixely.

I skimmed the thread and didn't see anybody mention this, so my bad if it's already been addressed.

Overall it's great, though.

 

The cloud shadows are essentially the normal Unity projector, so this might be an issue of your tree shader related to projectors in general. Try adding the IgnoreProjector tag to your tree shader.

 

I keep running into bad lighting at dusk. Observed this in various locales but here's my most recent setup I encountered this, though it happens pretty much across the board.

lat=11.5 lon=104.9 date=345 time=18 and utc=7 (same thing with time 19 and utc 8 of course) sunIntensity=3 moonIntensity=2

Moon is still totally invisible and the sun has just passed underneath the horizon (so invisible too) but there's still a huge pretty sunset glow (falloff 0.5, colorings 1) which is fine.

Light color is essentially still the yellow-orangey sun hue, not the blueish moon hue or the nice intermediate pink hue that it lerps over into a little bit later.

And this is the main problem.. perhaps lerping should start earlier, when the sun is gone instead when the moon is starting to show? Right now geometry gets lit from the moon direction but with the sun light color, when the big sunset glow is still fully in-place in the complete opposite direction. This is visually really odd and quite a glitch. (Made even more noticable on anisotropic specular surfaces such as ocean water --- there's a really pretty specular highlighting going on underneath -- nothing. Not under the nice sunset glow but instead underneath a completely invisible moon, yet with sun light colors.......)

Generally speaking, there's a million (not in ToD just generally) "unrealistic" game gfx glitches that we can totally get away with simply because it's a game, not a sim. But this one is just a tad too distracting / noticable...

Any ideas?

 

Setting the falloff to 0.75 should work around this. However, the fact that smaller falloffs don't modify the point where the sun and moon light sources swap is in fact a bug and I'll see to adjust this in the first 2.x fix. For now all falloff values significantly smaller than 0.75 should be avoided. As always, thanks for reporting this.

 

OK will wait for the next update regarding this.. related but different question -- does the moon mesh render (A) always as soon as it's above horizon or (B) only if the sun disk is gone?

Observed a case today in real life at (roughly) the above lat-lon coords at 16:nn PM where the sun was already fairly low (1.n hours before sunset) and the half-moon was visible fairly high, almost at the zenith / "north pole" of the sky ("noon position") -- which would be nice to reproduce in ToD but I couldn't seem to wouldn't mind the extra draw call as it's really pretty visually!

 

First - thank you for an amazing product - it has done wonders for the look for my game.

However, changing latitude / longitude does not offset skies. When walking on foot, this is not visible, but when you are flying an airplane or moving your camera fast across a playing field it looks kind of odd - scrolling across an entire nation, without changing the skies one bit. Is there currently a way to achieve such an effect?

 

Has anyone else had a go with the latest Time of Day update and iOS?

I'm just running a new build and the sky dome is not rendering correctly, like the exposure is set far too high. The rest of my scene is fine. Trying to figure out if something else is causing the issue but so far no joy.

 

It renders if it's above the horizon and fades out below, the additional draw call is only being made if it's actually on screen. The effect you're talking about happens quite a lot in real life actually, and I'll see if I can come up with a way nice to support it out of the box. It's not that easy to make this adjustable in a way everybody would understand. I could calculate the moon position accurately from the year and day, but this would mean someone would have to find out the date this effect happens and enter the data.

Not sure I understand what you mean by "offset the sky". Are you talking about moving the cloud layers?

I just tried the "Empty" demo scene on my iPhone 4 (the lowest end device I own) and it worked just fine. I could imagine that this has to do with linear / gamma space and the automatic detection of the color space. I don't know how Unity handles this on devices that don't support the linear color space, it might be that the class I get the color space from (QualitySettings.activeColorSpace) always says it's linear if the project is set to linear, no matter whether or not the device actually supports it. If that's the case explicitly setting the project to gamma or forcing TOD to use gamma (UnityColorSpace inspector enum) should fix it. This is just a guess though, as I said I cannot reproduce it on my device with the demo scene.

General remark: I haven't received any new reviews on the Asset Store in a while, so if you like the package and want to support me in its development please take the time to write a short review or simply rate it on the Asset Store if you haven't done so already. I think most potential customers will make their decision based on those reviews, and the Asset Store team might even take them as a way of chosing which packages are being featured on the front page.

 

I narrowed the error down to one of the post effects I was using. Still haven't worked out why the issue happened, but I believe it was to do with the tonemapper and HDR. Either way Time of Day works perfectly again and everyone can take a sigh of relief

 

Looks great, one question - You say it has full long/lat and time zone support. Does this mean you can specify anywhere in the world? I'm trying to get an idea of how accurate this plugin is.

Which year/month/day is it set up for, or can you specify this?

Could I, for example, set the ToD system to be Brisbane, Australia, on the 1st of January, 2014? If not, can the code be edited to allow manual entry of sun rotations for times of the year?

Thanks!

 

You can specify all locations and days of the year on earth and I calculate the sun position from there. However, at the moment the year is not supported (it's assumed to be 2000). That being said, the underlying equations can incorporate the year and I plan to include it in the next update. I originally left it out as I thought there's not much interest in it, but as it turns out people would like to see the moon position being calculated from the year as well to allow for intersting "moon visible at early evening" constellations.

So to state this in terms of your example: You could set it to Brisbane, Australia for the 1st of January, 2000. If you want to specify the year as well you can either add it as an offset to a constant in one of the methods (if you want to do this I can send you detailed instructions, it's not hard) or wait for the next content update.

 

Yes

 

Okay, to be honest I never thought about applications on such a massive scale (moving across whole nations). It should be rather easy to add an offset based on the sky dome world position though, so I'll see what I can do.

 

Nice product. I bought today and its easy to use and kind in price. Everything is ok but glow and sun shafts are missing. I hope you add them soon.

 

Both are part of Unity Pro and HDR + bloom / light shafts work rather nicely with TOD. Though I don't like the default Unity light shafts and I might decide to implement my own solution at some point in the future.

 

Lovely plugin!
Bought it and love it

Although, I'm having some issues.
The trees I have don't work nicely together with your sky, as you can see here:
http://gyazo.com/9afc44419b1c9d749f7e218e6afb6894.png
http://gyazo.com/332c1a343e40fb89bb2a504a47ad1c59.png

These are the tree assets I bought:
https://www.assetstore.unity3d.com/#/content/1021

While I don't expect you to instantly know what the problem is, I was hoping you could help though.
Is this something you've seen before?
Any suggestions for what might be causing it?
What information do you need to be able to help me resolve this?

Thank you in advance.

 

I haven't seen this exact issue. However, we can try to pinpoint the part of TOD or the tree pack that's causing this issue. First of all, try disabling cloud shadows and see if the issue persists. Which shader are those trees using - a default Unity shader or a custom shader that came with the package? Are you using lightmapping? I'm guessing the leaves shader doesn't handle projectors quite right, in which case the cloud shadows are causing the issue and we can easily fix it by telling the shader to ignore projectors or by disabling the cloud shadows if you don't need them anyhow. The second issue I could imagine would be that the leaves write to the depth buffer in a way that interferes with TOD, in which case I would need some additional information regarding the leaves shader.

 

I suppose there's no way to have the Atmosphere enabled, and still have the skybox visible? I've got some distant terrain in the skybox and really need it. Could that be done by somehow making the Atmosphere effects fade in above a certain point in the ToD dome?

 

Disabling cloud shadows seem to help, indeed.
However, the issue still partly remains:
This is with the projector on:
http://gyazo.com/47464c529e5cad1262fa77e079df1320.png
And this is with the projector off:
http://gyazo.com/b36db172ea4a2b463cd4257e8812392b.png

If you compare those side-by-side, you can see that it helped, however, a small outline still remains.

Regarding the shader the trees are using, I think it's a default Unity shader, seeing as I can't modify or change it.
Take a look!

http://gyazo.com/e764ef84d5d62ed09cc1b0f8ee8df784.png
As you see in the lower left, I have the tree selected. It's Material is attached to the prefab. At the top right you can see the shader.
It's called "Hidden/Nature/Tree Creator Bark Optimized". I think this is a Unity shader, I can't tell though.

Just for reference, this is the tree prefab:
http://gyazo.com/9d228c019a269ade51d8f56437f10cfc.png
And also the leaf shader:
http://gyazo.com/9fbcaebf1877289016053126516496a4.png
Why I can't change any of the settings for the shaders, I don't know. They're grayed out.

Light-mapping, nope. Not using any of it.

Thank you for trying to help, I greatly appreciate it!


EDIT;
I've also noticed it happens on the standard Unity terrain too!
http://gyazo.com/c7e244c52f3810202be2e2914039eab8.png
That's using the "Nature/Terrain/Bumped Specular" shader.

EDIT 2;
Hey! I found the issue.
However, it's still not really resolved.

The cause of the problem is Unity's SSAO image-effect.
Disabling this resolved the problem!
However, SSAO is quite vital for me. It's such huge improvement on how the game looks.

EDIT 3;
It's a Christmas miracle!
I managed to fix it on my own, the problem's all gone now!

I made an unlisted video on YouTube on how I fixed it, in case you want to know.
It's like a minute long:
http://youtu.be/OVn3DROUgz8

In case you couldn't tell, what I did, is that I changed the Main Camera's "Clear Flags" to "Depth Only".
Simple as that. SSAO works well and everything.

Anywho, thank you for an amazing plugin!

 

Sorry for being unavailable for the last two days. Was kind of busy with this whole Christmas event!

I would recommend drawing things like that on a separate sphere that's being rendered after the atmosphere. All you would have to do is modify the skybox shader's position in the render queue and, if not already supported, add alpha blending. I don't know in how far you are able to write shaders on your own, but the changes should be fairly easy, so I can assist you in the process if you like.

Great to hear you solved it on your own. I'll note the solution in case someone else runs into this issue.

 

Fantastic!
I really need this feature

Ps.
I am thinking about adding the ProFlares - anyone having tested this package with Time of Day...?

 

That's fine, I was kinda busy as well!
Hope you had a great time!

 

Hi, do you any deadline for the new update?

I also wanted to ask you if there is a way to have a red sun on sunset and sunrise that affect also the color of the light? I'm doing a Grand Canyon environment and as you can see on these picture the color of the mountains change a lot based on time of the day (you can use the projected shadows to determine the time:

http://www.f21.org.au/wp-content/uploads/2012/06/2DayTrekInGrandCanyonRimToRiverAndBack.jpg
http://www.agenciaseven.com.br/blog/wp-content/uploads/2013/07/10281733-grand-canyon-sunrise.jpg

Thanks,
Maurizio

 

I plan to release a small fix next week and the next feature release late January or early Feburary.

The "Light" parameter category manages all of those kinds of things. For now "Sky Coloring" will both affect the light and atmosphere color at low sun angles (we can talk about splitting those to be able to modify sun and atmosphere influence separately if you are interested), "Falloff" adjusts how quickly the sunlight falls off (slight changes coming to this in the fix, right now you shouldn't modify it all too much) and "Cloud Coloring" affects the clouds.

 

thanks

Thank you I found a nice combination. The main problem was the Moon Light Color that was affecting also the sunset and sunrise color. When I was trying to get a red light I got purple, because it was adding the blue of the moon.
But anyway to get a good red terrain the sky became too red. So splitting those two could help

Thanks you

 

Hello plzdiekthxbye,

I'm having an issue with seams in the sky. Any tips please

 

i read in your first post that this TOD works with virtual reality hardware? im assuming the Rift? so no doubled, blurred skydome images due to the image effects the rift uses? also, does this system rely on a second camera or only one? i tried a different TOD system that used 2 cameras and it caused me many problems.

 

Greetings plzdiekthxbye.

We really like your plugin, and like many here have looked at all the options on the asset store and this seems to be the most lightweight, efficient and good looking day/night system out there. Before we can proceed though we had an issue with out game that we wanted to ask you about.

We are making AstralTerra, which uses similar technology as Minecraft. The voxel terrain is generated at run time, procedural, and is infinite. Because the player can journey very far, we have concerns with them eventually running into the skydome. Will this system work for us the way it comes or will we need to customize it? I currently am using a script on a second camera for an old school skybox trick (the environment is surrounded by mountains) so using a second camera on a static skydome area certainly can be an option. Still a little new to this area of development so please forgive my newbness or ignorant question. Thanks for your time and awesome product, good job!

 

I cannot help you without further information, the first thing you should try is a complete reimport of the package, the issue you describe shouldn't happen out of the box. If it does, please see if the demo scenes are working correctly.

TOD does not use two cameras, I describe in the documentation how to set up the scene for the Oculus Rift in order to get a nice sky dome. The basic idea is to attach the script that moves the sky dome to only one of the two eyes. While I haven't tested on the device myself, I received reports from users that it does in fact work.

No need for a second camera. TOD has a script that centers the sky dome around the camera before rendering the scene, you will therefore never run into the edge of the sky dome if set up correctly.

By the way good luck with your game, keep me posted on the progress - if you end up using Time of Day for your sky I'd love to link to some gameplay videos of yours as an example for a nicely looking game project.

 

Thanks for the quick response, will keep you posted for sure! Going to pick this up today and give it a spin.

 

Does this skydome support water4 asset? At night the water is bright. During the day, I see the skydome reflected in the water. However the reflection of the sun(specular) is not picked up by water4. Is there certain parameters I need to set to get water4 to work?

 

The documentation of water4 states there is "an optional lighting script for specular effects", so I would assume you have to tell water4 which light source to use in this script. I'm at university right now, so I'll look into this when I get home. Sounds like it's just a matter of setting things up correctly though.

 

Sorry! problem wasn't to do with your asset. All sorted

 

I just got a slightly modified version of the Unity sun shaft image effect working (including correct handling of the clouds) and I might be able to include this in the 2.0.1 update.

Just had a look at this - it works correctly if you simply set the "Specular light" inspector variable of the "Specular Lighting" script component of the water4 instance to the sky dome sun game object. No further adjustments required.

Alright, no need to shout! Good to hear you fixed it.

 

Great news thanks for your time!

 

A quick status update regarding the 2.0.1 update: I finished up the code today and all that's left to do is testing and updating the screenshots. I updated the web player so that you guys can have an early look at the new stuff. While it is mainly a tweak fix update, it's a farily major one at that. Sun shafts finally work perfectly together with the clouds, full Gregorian calendar support, the moon halo is back (this time without causing an extra draw call at night) and all the minor issues of 2.0.0 you guys reported in here have been addressed.

I plan to submit 2.0.1 this weekend, which should make it available early next week.

 

Will have to pick this up.
On a side note, I heard you were messing with ray-marched clouds. I swear to god I am currently rubbing money on my screen in the hopes it produces something useful... I've been struggling with implementing something similar (from a GPG5 article), and I just can't seem to get the damn thing working right. Having a third party, good solution would certainly do something to ease my blood pressure I think

 

Thanks mate, I hope you'll like it.

I got the fragment shader for ray marched clouds to work about 3/4 of a year ago but TOD took up pretty much all of my free time in the meantime (also I'm still in university and I since my sales were rather low in the early months after the release of TOD I also had to work part time for some other companies and at my university). Now that my sales on the Asset Store reached a decent level I hope to be able to put more time into the cloud package to be able to finish it up for release in the upcoming months.

It also looks like there's no longer the need for me to create a package with rain / snow particle effects since there are already some great packages on the Asset Store, most of which should work rather nicely with TOD since it contains example scripts to manage third party particle effects based on the selected weather type or daytime.

 

YAY! ---did you? checked out your latest web-player a day or 3 back and it was awesome, clouds looked so much better too!