Time of Day - Dynamic Sky Dome

plzdiekthxbye, would you be able to add a Aurora Borealis that can be set by time and a event base trigger?

 

TOD_Rays uses the depth buffer and the alpha value of the color buffer to determine which objects should block the sun shafts. You have to disable those two things (see the "ZWrite Off" and "ColorMask rgb" shader features) on any objects that shouldn't block sun shafts. An alternative is to render those objects on a second camera or simply after the image effects are done. I reckon the objects you're talking about are part of some sort of overlay so you probably don't want other image effects to affect them as well.

I recommend using the cloud billboard shader that comes with Time of Day to do this. Support for custom cloud billboards / sprites will be extended in the next update, so you might want to wait for that to come out (planned for this month) before putting a ton of time into it now. The cloud billboard shader is available in the current version as well though, so in theory there's nothing keeping you from using it right now.

For TOD_Rays to recognize an object the shader either has to write to depth or the alpha value of the color buffer. Tree creator trees in Unity 5 appear to do neither. The only reason the standard image effect somewhat works is that it compares the pixel value to a sky-like color and adds blockers if they differ, which isn't a solid solution by any means. I'm not sure why Unity decided to no longer write the alpha value of the Unity Tree Creator trees (to me it's just another indicator that they don't care about that feature at all and feel like everybody should switch to SpeedTree), but you can manually fix it with a simple change in the tree billboard shader: Copy the tree billboard shader from the downloadable Unity shaders into your project and remove the line "ColorMask rgb" from it. You have to restart Unity for it to take effect. I attached the changed billboard shader (tested with Unity 5.1.0f3) because I had to do the change when verifying the fix anyhow, so feel free to use that.

I don't believe this is something every package on the Asset Store should solve in its own way because the best solution for this really depends on the way your project is structured. As I described in my last reply Unity offers a range of tools to do this, and the easiest one is literally calling a method on a game object and pretty much be done with it.

This is on my idea list, but it's not planned for the immediate future.

 

Thanks for your reply.

The shader in question is the FoggyLight shader in Foggy Lights.

"ZWrite Off" was already included in the shader, but adding "ColorMask rgb" seems to have resolved the issue!

Cheers!

 

I placed your shader in my project and restarted but nothing changed. Do I have to do anything else?

 

Which version of Unity are you on? It's possible that it has to be in a certain folder - I tried it right in the asset root folder (YourProjectName/Assets) and it's definitely loading for me. You can try whether or not the shader was loaded by deleting it - all tree billboards should disappear then because Unity can no longer locate the shader. If the billboards remain visible it's still using the built-in billboard shader.

EDIT: Also make sure you don't have a different custom tree billboard shader in your project - some third party assets come with one included.

 

Ups sorry, there´s a misunderstanding, it´s not about wrong lightshafts on billboarded trees but on 3d-trees.
So it´s not the billboard-shader but the "Nature/Tree Soft Occlusion Leaves" shader I use here.
I edited this one as you described but no result.

EDIT: Renamed Shader to "Carsten/Tree Soft Occlusion Leaves" and manually applied it to the trees. Works then - thanks very much!

 

Great to hear you fixed it. By the way the default Unity Tree Creator shaders ("Nature/Tree Creator Leaves Optimized" and "Nature/Tree Creator Bark Optimized") should work with TOD_Rays out of the box - no need for any modifications other than the billboard fix I posted.

 

Any news about 3.1 ? I am really interested in the new cloud shadows. The old ones looked extreme cool on terrain but as many stated here caused a lot of problems. However I am sure that they will have a huge impact on the overall visuals when working as expected.

 

ETA is still some time this month. The only thing left to do is to run some tests on mobile, which I hope I'll find some time for this week. I might also do a prerelease via the mailing list as I did for 3.0.0 - if you want access to that mailing list send me a PM or Email with your invoice #.

 

Hi, after playing certain games and looking at other competing sky solutions, I wish that Time of Day would allow for more vivid colours at sunrise and sunset, and more control over the colour transitions.

I've tried playing with the Day - Sky and Light Colors, but they don't seem to work as I think they would. The color transition goes from Day - Night, but there doesn't seem to be any way of determining when Day stops and Night begins.

For instance, I want to start tinting the sun orange / purple for artistic effect as it starts to drop low in the sky, but this isn't an option - the transition to night happens too late (when the sun has already dipped to the horizon) and the Day sunlight color can only be a single color, no transition, at the 1% end of the transition.

Ideally, the transition would be more like 00:00 at one end, to 23:59 at the other - a complete transition that doesn't decouple the concept of Day and Night. Obviously this would be more complicated to setup and refine, but offer far more control.

This might also remove the situation we currently have where there is a brief period of darkness at dusk and dawn when the sun has disappeared but the moon is not yet out - for some reason the ambient light at these times disappears, regardless of settings?

I just want to state that I absolutely love this plugin and it's a core part of every project we do, so think of this as a wishful idea. I see the colours of GTA5 and The Witcher 3 and I just want to re-create the artistic effect!

 

Hello,
I'm playing intensively with image effects now. I have created this order of image effects:
SSAO
Depth of Field
Deluxe Eye Adaptation
Bloom
Deluxe Tonemapper
Color grading
Vignette
Antialiasing

I'm not sure where to insert TOD_Rays and TOD_Scattering image effects?
From common sense I would insert TOD_Rays before or after bloom. And with scattering effect I'm not sure.
At first place? Or after SSAO. Or insert it to the end before antialiasing?

Sorry for beginner questions, but it's not easy to found recommended image effects ordering.

Regards
Peter

 

Hi, I have just purchased this asset and it looks awesome (currently tried on Mac, Android and WebPlayer).

But I can't see any star with default configuration (I have left it run for a day/night cycle and no starts).
Is there any parameter that must be set?

 

Also, what's TOD_Scattering for? It seems optional.

 

It's for atmospheric scattering effect:
https://www.google.sk/search?q=atmo...ved=0CAYQ_AUoAWoVChMI1-W1046UxgIVyJzbCh1fzwB4

 

Thank you! I see.

Now, do you see stars in your sky dome during night? I don't. Any idea?

 

Yeah I have seen them.

I'm really beginner but I would try to set clouds to None and Weather to Clear to be sure that stars will be visible.

 

I have the settings to custom, the default value. I have very few clouds on the sky and no stars in between.
Also tried your suggestion, with clouds to none and weather to clear and same results. Only the moon is seen over a pitch black sky during night.
I'm on unity 5.

 

In addition to the stars issue, do you have any recommendation regarding performance? I'm using it with and without Unity Pro advanced water (with reflection) and fps are very low on Android (S6).

 

Is there any way to put TOD into a mode where only the time is updating, but nothing else related to the visual simulation is? I.e. when running as a dedicated server, I would like to be able at run-time, to delete as much as I can from the TOD stuff while keeping the time progression still functional. For example, with a dedicated server you don't care about the sun position or the moon position (in most game scenarios at least), so all of the celestial body update code could be skipped.

 

Version 3.1.0 changes the behavior of the gradients and should solve most or all of the issues you're having, so let's talk about this again once the new version is out.

SSAO has to run before fog-like effects, but other than that the TOD effects should be very early in the image effect order. I'd start with SSAO, then TOD_Scattering and TOD_Rays followed by the rest of your image effects. TOD_Rays isn't absolutely required to be that early, so you can move it back if you prefer excluding it from the tonemapper or eye adaption - that's really up to you.

I reckon the biggest performance impact in your case is the Unity Pro advanced water. To verify this test a scene with just Time of Day on your phone - that's the worst-case for Time of Day since the entire screen has to be filled by the sky dome. I don't think the water is optimized for mobile at all, especially not when having planar reflections enabled on it, in which case it will render all objects that are included in the reflections twice.

Time of Day automatically disables everything that's only required for rendering when running in batch mode. The celestial computations are still executed because they are the foundation of quite a few properties that can be accessed via the API, some of which might be required on a server as well. However, those calculations are extremely fast to do and if you attach the Unity profiler to a development build of your server running with the "-batchmode" flag you should see extremely low overhead coming from the Time of Day scripts. Even in the editor without the batch mode optimizations the Time of Day scripts should be somewhere around the 0.0X ms mark.

 

Whoops, missed one question.

I take it you're the same person who sent me an email with the same question?

A few troubleshooting steps in addition to the full reimport I recommended in my email:
- TOD_Camera has to be on your camera (see the "Getting Started" section in the docs)
- Select the "Space" child object of the sky dome at night and make sure the renderer and the game object are enabled, also make sure the renderer has a material assigned to it (all of this should be the case out of the box)
- Make sure the stars aren't just too small or too dark to see by having a look at the "Stars" parameter section on the TOD_Sky script

You're using the default prefab, right? It also happens in a new project with just Time of Day in it?

 

Yes! It was me!

I've found the problem. The tile setting of 6 was causing the stars to appear too small as you commented. I have lower this value to 5 and I can see them. I will try different values and see. Thank you!

 

Awesome... so pumped for 3.1.0!

 

I have some 3rd party shaders that take a cubemap for reflections. Unfortunately they don't pick up on unity5s reflection probes or default sky reflection that ToD writes to.

Is there a way to access the reflection cubemap from ToD from script so I can pass it to materials using these shaders?

Thanks
Travis

 

You can either change the shaders to use unity_SpecCube0 as their reflection cubemap (this is automatically set to the closest reflection probe by Unity, I recommend doing it this way because it works with any reflection probe and and even if multiple reflection probes are in your scene) or manually set the cubemap reference in a script to TOD_Sky.Instance.Probe.bakedTexture (see the the Unity docs for more info on this).

 

Time of Day 3.1.0 has entered the testing phase. The submission to the Unity Asset Store is scheduled for the end of this week with a public release following early next week.

 

Thanks that will be useful!

 

Quick Question, we are developing a game where we have a top view of the map. We want the top view which takes a snapshot of the overhead view of the map to always be well lit even when the time is night time. I tried setting the TOD_Sky.Instance.Cycle.Hour to 12 prior to taking the snapshot but that does not appear to work. Any suggestions on how to always have a well lit overhead view. Thanks

 

I don't recommend lighting the overhead view with Time of Day in this case, for these reasons:

• The position of the directional light Time of Day manages doesn't just depend on the time but also on the date (which could be circumvented by setting the Cycle.DateTime struct instead of just the hour)
• You'd have to manually refresh the sky dome before and after rendering the overhead view to get the correct directional light position
• You'd also have to refresh the reflection probe and ambient light before and after rendering the overhead view, and I'm guessing you don't want to pay that overhead twice per frame

I reckon the proper way of doing this would be to render the scene for the map with a replacement shader that's simply always lit the same way. You can also do it a bit more hacky by adding a second directional light that's only enabled when rendering the overhead view, but in that case you'd still have to set the scene reflection probe and ambient light to get truly constant lighting.

 

I need to have 24-hour time advance, but date and month to be static, never changing (so it's always June 21). Is there a way to do that?

 

The problem is that the sun and moon use their real-life positions, so over the course of the day the position of sun and moon progress, and the position of the moon at mightnight on June 21 is not the same as the position of the moon at midnight on June 22. This means if you go from 23:59:59 to 00:00:00 without increasing the day, the moon will jump back a certain distance, since you basically revert the relative offset of its orbit that happened over the course of the day. The same thing is true for the stars.

There are settings that disable the real-life position calculations for the moon (Moon.Position set to OppositeToSun) and the stars (Stars.Position set to Static), but obviously this will also disable the moon phase and and the star rotation. With those settings the date would not have to progress, so I could either add a toggle to TOD_Time to prevent date progression or you can manually do it by overriding it.

I guess the real question to find out which solution might work for you is why do you want the date to be static in the first place?

 

That level of accuracy is super cool, but for this particular project I don't need it. I want to keep the date fixed so the sun's path is the same each day. (I've set the latitude for a particular sun-path and particular sunrise and sunset times. It's a fantasy world.)

It would be nice if the moon moved through its phases, but that's not necessary and I can see its probably impossible.

I don't mind editing the code, but can you tell me exactly what to do?

Thanks!
Dave

 

I have a very weird issue with performance and TOD. I have a scene in Unity 5.1 with real time GI set up with TOD (linear, deferred, DX11), and i get some very strange framerate dependent stuttering. If I set Day Length In Minutes to 10, it stutters. If i set it to 100, the same (framerate is at 80-100 fps). At 1-5 however, everything runs super smooth and the framerate tipples. Disabling TOD_Time brings the stutter back. And we're not talking a tiny bit of micro stuttering here!

I have tried going through the project, disabling components and GOs one by one, and it is clearly TOD that is causing, or at least triggering the stutter. I have checked the profiler, but nothing reported there to explain the occasional slow frames. I have also tried making a build, with the same result. I tried disabling ambient and reflection updates, but that didn't help either.

Any ideas as to why longer day length can introduce stuttering in my project?

 

Look for "UpdateCelestials" in TOD_Sky.cs - this is where the sun and moon positions are updated. The altitude and azimuth angles for sun and moon are what defines where the sun and moon are, and since those take the date into account their position changes when the date progresses.

You can replace those calculations with a basic position calculation that simply calculates those angles from the current hour (without taking the date into account) and would therefore yield the exact same position of the sun every day. However, if you decide to do this I would recommend to wait for the relese of 3.1.0 since otherwise you'll have to do those changes again after upgrading.

By the way, did you set the correct UTC time zone offset and what are the longitude and latitude coordinates you're using? Usually, at least around the equator, the differences in the sun's movement over the year shouldn't be too extreme. If your latitude is very high or very low you run into polar nights, but other than that the date progression shouldn't be a problem, even for a fantasy world.

My guess is this is caused by Unity's implementation of dynamic GI, which isn't really all that dynamic but instead just rebakes whenever the lighting in a scene changes. This means it has to refresh whenever the light position changes, so if you want to use it with a dynamic day / night cycle you shouldn't speed up the time progression too much to prevent it from constantly having to refresh the lighting of your entire scene. Generally speaking it's also a good idea to increase Light.UpdateInterval on TOD_Sky when using Unity's dynamic GI to reduce the amount of refreshes it has to go through. To verify that this is in fact the root of the problem, try disabling dynamic GI in the Unity lighting window and see if that fixes the issue.

 

So something like this? I'm not sure how much to remove from that equation:
float 9 + day - 730530 + hour / 24f;

I've got latitude set to -45, so the sunlight is angled in the desired direction. I think longitude is irrelevant. I might also remove the earth's tilt in that section of code to make it really consistent.

 

I could not find any other place to post this, so here goes.

I am using the beta version of the next release of ToD. I was disappointed to see that the sunsets did not get nicer and in fact, are even more dull than before.

The clouds are very nice though and I like how easy it is to modify them. The light also seems better from the ambient day and night settings.

Is there some setting I am missing that could increase the color of the sunsets? I already use Tonemapping and Amplify color and those are not useful for this as the sunset is a fleeting moment. Scattering doesn't really do anything now compared to before. It seems to be more about fog, which is good but doesn't affect the sun.

The lack of a nice sunset and sunrise is an issue with this asset and as much as I like it, I can't convince others to try it for that reason. Any way to improve it other than what I have already tried?

 

If you can, maybe it would be helpful to post a comparison ... a sunrise/set shot showing the qualities you don't like in ToD, followed by a shot showing some other product or real world photo that has what you are looking for.

 

I am with Teila on the sunsets although I am not using the new beta. In earlier releases there were settings files where you could change the overall look. I think the challenge is just settings based, and not a limitation of what is an otherwise awesome asset.

 

Just tried the June 29th pre-release. Thank you for making that available.

My question is about the new cloud system. Can they overlay on scene geometry? For example, can the far away mountains have clouds which go through them? I can only get them to show behind the mountains so far.

 

Sorry, forgot to mention: cloud shadows. I can't get them to do much more than darken the scene a touch. I was wondering what to expect from this feature.

Many thanks!

 

That's the issue, you cannot really mix & match those calculations as you want and expect them to work when the hour resets from 24 to 0 - you would have to replace them altogether with a much more basic equation. Something along the lines of calculating the sun altitude using just the latitude setting, then calculate the sun azimuth from the hour. I could certainly add support for something along those lines if there's interest in this sort of thing.

Those settings are still around - in a much more detailed fashion even. There are 3 factors that influence the sky color - Atmosphere.RayleighMultiplier, Atmosphere.MieMultiplier and the Day.SkyColor gradient. A simple way to tweak exactly what color you want the sky to have at sunset is to adjust the right end of the sky color gradient. For example, if you want it more orange you simply make that color more orange. If you want the orange to kick in sooner or later you adjust the position of the color node in the gradient. The value on the left end is used when the sun is at zenith, the value on the right end is used when the sun is at the horizon.

That is not supported right now. I recommend adding a cloud plane or a particle system to the mountains that is faded out when the player approaches. This is the way Far Cry 4 does it and it works pretty well.

Cloud shadows are only visible if the sun is near or behind a cloud. To test if they're working correctly, set cutoff to 0, fade to 0 and intensity to 1. Then increase the Clouds.Coverage parameter on the sky dome. You should see the scene getting darker. The same effect happens whenever the sun moves behind a cloud. If you fly high up into the air you can see cloud shadows of distant clouds projected onto your world even if the camera position is not shadowed.

 

Can I ask why this wasn't added to the new documentation? I spent days figuring out the last version, with kind help from people on this forum. But when I asked you, I was told to read the Unity doc. I do read the Unity docs but when something changes and is not written in the docs for the asset, then most folks, other than those who don't need documentation, are going to have problems.

I seem to recall above that you told us the sunsets would be addressed in the version that is now released. Add some documentation, please. I actually had to go back to a PM sent by someone on this thread to set things up properly because so much was left out of the documentation.

Support is a bear but you would cut in half the number of people with issues if you wrote decent docs for users, not for programmers only. Then I guess sales would increase and you would have to give more support. lol It is a catch 22.

 

If you search for "sky color" in the PDF docs of the 3.1.0 prerelease you find the gradient I was talking about and a short description. There's also a tooltip when you hover over the variable in the inspector. Both of those documentation elements are part of the standard documentation I do for every public variable and method, and they tend to be sufficient when new customers have a quick look at all the inspector variables after downloading Time of Day for the first time. I'm always open to suggestions for how to rephrase something in case someone didn't understand it from reading the tooltip or the variable description in the docs.

If the same questions to a certain topic are asked over and over again I take the next step and add some additional text to either the introductory section of the docs or the FAQs, but there's no point in adding ever more lines to the first page of the docs because at some point nobody is going to take the time to actually read through them. Something will always have to be hidden behind the search function.

I highly doubt I ever told you to look for how to adjust the sunset color in the Unity docs - that would be silly. I do occasionally send out links to the Unity docs, but only in cases where the question can be answered using the Unity docs.

As I said, Day.SkyColor is in the docs - but generally speaking if something isn't completely clear from reading the docs then please use this thread and ask away. If something isn't clear from the answer I give, ask again.

What I said was that the gradients will change in 3.1.0 from being restricted to the sunset / sunrise times to spanning the full day and night. The Day.SkyColor gradient itself has been around since the release of 3.0.0 and has always been the gradient to modify when customizing the sunset and sunrise colors, and whenever someone asks about adjusting the sunset color I mention the same 3 components from my reply above (Atmosphere.MieMultiplier, Atmosphere.RayleighMultiplier and Day.SkyColor).

EDIT: Rest assured, after dealing with this wall of text I'll make sure to add the sunset / sunrise color question to the FAQ section in the next patch release (3.1.1)

 

Do you realize how difficult it can be to find answers in 23 pages of a forum thread? Why not just put those answers in the documentation. Unity has done away with the individual thread search so now one must hunt meticulously through dozens and dozens of posts to find one little thing. Very likely I missed stuff.

But...this is not a free asset and decent thorough documentation is a must.

As for the Unity Manual, no, you were probably very justified in sending me there, but again, the Unity manual is not going to answer questions specific to one product. It is vague and general. The reason assets have documentation is to avoid lots of general questions...or answers.

I really like your product, honestly, but I figured out RTP and TC faster than this one. Only some of the settings have documentation, most of them just have tooltips. The docs are a quick guide and an API list for the most part. This okay for some, but not for everyone. The great thing about the Asset store is the ability to buy solutions to problems and my reason is so that I can free up my programmers' time by figuring things out myself...and I do pretty well with a little help.

On the other hand, maybe I have figured it out and just decided it doesn't do what I want it to do. I will never know though.

Thank goodness for this fantastic community.

 

Thank you for the fast response. I was able to see the effect of the shadows from the clouds by hacking the intensity value to be a max of 10.

(Bug?)Then, I noticed the shadows were traveling faster than the clouds.
And, when you change the cloud size, the speed changes.

(Question) How can I achieve puffy clouds (scientific term)? Can I create an animated cloud masks to simulate swirling clouds?

Thanks!

 

Hey guys, been using TOD for a while now but haven't had it in my project for about 2 months because I was rebuilding. Anywho, just imported the asset today fresh off the asset store and am having an issue.

For some reason, in my scenes with TOD, my reflections are pink, similar to the color of a shader that is having an error. :/ Not sure why this is happening but unless I put a reflection probe on the item in question, I get pink specular reflections. If I set the Color range off of HDR it fixes it, though I use HDR for all my settings on cameras and need it for some of my packages. :/ My project is in Linear color mode and Deferred Rendering mode. I'm setting this to Auto right now (which I think it then does LDR) so that I can move on, but am very interested in hearing if anyone else has seen this issue.

Ok so upon setting this up in a fresh scene that only had lighting settings and a camera, I now know this happens as soon as I switch the Skybox option in the Lighting tab from the Default Unity skybox to the Skybox in the Materials directory of TOD. When I do this my reflections go away and I get pink specular reflection all over stuff.

**Update** The Sun option in the new Lighting Unity tab will not keep the Light from the Skydome that I keep associating it to. I drag the Skydomes Light into the slot and hit save. Exit scene, come back and its empty again. I have tried this 3 times with the same result everytime. So..... what feature on Time of Day removes the light from the lighting tab Sun slot, or is this supposed to happen?

 

Which parameters / functionality specifically did you have trouble with? All of the tooltips are also in the documentation, so I'm trying to find out whether those short descriptions simply weren't doing a good enough job at explaining things, and if so which ones specifically.

Is your cloud opacity on TOD_Sky set to a very low value? The cloud shadow visibility scales with the cloud opacity as well as the multiplier on the image effect, but I can see how even at full opacity they might not be intense enough for some people. I'll have another look at it, thanks for your input.

You're correct, it does seem like the cloud shadows are ignoring the cloud size setting, so you see an offset in their movement as soon as the cloud size is something other than the default value of 2. Thanks for reporting, I'll see to fix this.

Since the cloud layers are doing a very optimized ray march in view direction with only 4 samples, there's only so much height they can achieve. So for perfectly puffy clouds in the cloud layer itself you'll have to wait for the fully volumetric cloud layers I have planned for the mid future.

That being said, Time of Day also allows you to use hand crafted cloud billboards (enable the "Billboards" child object to have a look) which can use any shape you like. The cloud billboards change their shape over time using the RGB channels of their texture, with the alpha channel specifying the density when marching in up direction. Check out the cloud_atlas texture for an example. This is very close to how the artists in GTA V created their puffy clouds and you can achieve some pretty nice results - the downside obviously being that they aren't fully dynamic.

The sun light variable in the lighting window being unset is intentional as the Time of Day light is used for both the sun and the moon. There are a few things you should check with regards to the issue of having pink reflection probes:

• Double-check that the TOD_Camera script is on your camera.
• If you didn't do a fresh import of Time of Day and instead copied it over the old version I recommend doing a full reimport, which should be done with every major release.
• Due to the pink reflections it could be that a shader failed to import, do right click -> reimport on the Time of Day/Assets/Shaders folder. If this doesn't work select the Time of Day/Assets/Materials/Skybox material and check if it's also pink in the asset preview. Should that be the case, select the Time of Day/Assets/Shaders/Skybox shader and make a screenshot of the errors that are displayed on it.

 

This is the second project where that would be helpful. (It wasn't so critical for the other one, but is for this one.) If you can give me the code change, I can apply it (rather than adding it to the product), or I can wait for an update...if that would come out in July...?

 

I've just updated to the latest TOD version and I noticed that TOD_Camera is now forcing the Camera's clear flags to Solid Color. Then I found this in the changelog for 3.1.0:

I didn't understand the reason for exactly forcing the clear flags to solid black. Why is that being done exactly?

The reason I ask is because we need our Camera's clear flags as Don't Clear because we're using a multi-Camera setup, so for the time being I had to comment out the code in TOD_Camera's Update() to not set the clear flags.

Thanks.

 

@plzdiekthxbye,
great asset, thanks!!!

I'm trying to replicate the visual effects of "Atmospheric Scattering" from Unity's "The Black Smith".




Working with your asset and with the environment (without any image effect) from "The Black Smith" this is what I achieved:


1) As you can see, in the last image there is a blue circle. It happens when I scale the sphere to cover the big terrain.
* Is there a way to scale the sphere to cover this particular big terrain?
* Can we use your asset in terrains with 32x32 kilometers?
SOLVED: Thanks to @hopeful. "TOD_Camera" solved my issue #1.

2) The shadows (please see the video below) flips/flashes/twinkle (turns on and off rapidly).
How can I fix the shadow flips/flashes/twinkle?

http://www86.zippyshare.com/v/pVLxFxWw/file.html


3) Could you replicate the visual effects of "The Black Smith" with just your asset?
Please, refer to: https://www.assetstore.unity3d.com/en/#!/content/39948

Thanks for your great work and help!