TENKOKU - Dynamic Sky

@Radu392 you CAN adjust the point at which the light turns on/off which should prevent it from showing the bright specular on your water surface. You need to go to the color settings tab and switch the color 'gradient source' to 'custom gradient' and then adjust the ambient daylight slider (both the black and white tabs) a little to the right. this should adjust at what time the sun light turns on and off.

As to your first image with the stars on the horizon, I think you should be able to adjust this by going to the Tenkoku-->SkySphere-->Effects-->fxCloudSphere object and lowering the Y-position of this object from 0.0 to -2 or -3. This should drop the clouds just enough to cover the stars all the way to the horizon.

There is a new version of Tenkoku that's already been submitted to the store (and should be available soon), but I will consider adding these edits into the next update. Hope this helps!

 

Thanks @chingwa that worked! May I ask what this update you're pushing is about? (Strongly hoping it's advanced random weather )

 

Sorry @Radu392 it's just a maintenance update, bug fixes and such. Advanced Weather, and other goodies are in the works which will be in a more thorough 2.0 update/overhaul sometime later this year.

 

Hello All,

I'm happy to announce that Tenkoku version 1.1.9 is now ready for download...

Download Here: http://www.tanukidigital.com/download

Also available on the Asset Store here:
https://assetstore.unity.com/packages/tools/particles-effects/tenkoku-dynamic-sky-34435

This is a small maintenance update with some bug fixes and color fixes, particularly for those using Unity 2018.2. For those wondering about the long development between what may seem like small update releases this is due to most of my Tenkoku dev time being put into a forthcoming 2.0 version, to hopefully be released later this year. While I don't have full details about what will be new/improved in 2.0 quite yet, I can say that there will be better performance, more thorough customization options, improved weather automation including the conspicuously missing 'advanced weather' system (as well as a real-world weather option). I should have more info about this once it gets closer to release.

As always, let me know if you have problems/questions/feedback etc, either by email or on the forums!

All the best,
Justin Kellis
Tanuki Digital



-------------------------------------------------------------
A note about SRP (Scriptable Render Pipeline) in Unity 2018
-------------------------------------------------------------
(July 2018)
Many people have asked about the new SRP system in Unity 2018. Because Unity's new HDRP and LWRP Render Pipeline is still in Preview mode, and because of the massive differences between these and the current default rendering system, I've decided to take a "wait and see approach" to when/if Tenkoku will support these modes. Unfortunately the amount of work involved in upgrading to SRP is not trivial, and it's best to wait until these systems are at least no longer in "preview mode" as Unity describes them. Once SRP is more mature I will take another look and reconsider if I will rewrite Tenkoku to support them.


-------------------------------
RELEASE NOTES - Version 1.1.9
-------------------------------
CHANGES
- Increased sun shader brightness output.
- Adjusted sound fx to react to sun altitude instead of time (more accurate day/night audio switching).

BUG FIXES
- Fixed slow ambient update when first playing a scene.
- Fixed Sky color rendering issues in Unity 2018.2+.
- Fixed cloud color rendering / saturation issues in linear high-dynamic-range projects.
- Fixed issue with editor using wrong colored UI elements (dark/pro skin vs light skin).
(Note: there is a Unity bug that breaks UI colors in Unity 2018.1, it is fixed in 2018.2)

 

Hi, I apologize if this has already been addressed, but I have a strange issue I can't figure out. Essentially I set up my dynamic sky and it works great, except the sun sprite isn't rendered in my game view. It's there is the scene view, just not in the the render. I'm working on HTC vive, but even in a test scene without VR the issue still persists. Thank you!

 

@PVincenti That is strange. I wonder if editing your main camera 'far plane' setting to be larger makes any difference at all? Also in some cases the internal gradients can get corrupted and you may want to try switching the 'gradient source' to 'texture' (in the color settings section) just in case.

 

I found the issue, the problem is the sun moves depending on the camera's far plane. my scene is full of mountains which meant the cloud plane was too low for my needs, so I had scaled un the sky sphere. So what would be a clean solution to make the cloud plane higher without scaling the sky sphere? Thank you!

EDIT : So I figured out a solution to my problem. My problem wasn't really the height of the clouds per se, but the way they we interacting with the horizon. I am using legacy clouds because the current clouds are either too heavy or too fuzzy depending on the quality setting. I simply rotated the plane a bit in X so that it almost meets with the horizon. The way my scene is set up the horizon is only visible in one direciton, but if that wasn't the case I could've wrote a script to follow the camera's forward and tip the clouds according to it. Maybe that could be an interesting feature to add in future versions?

 

I tested the demo (version 1.1.6). I've reviewed a lot of weather assets, but this one seems the most realistic. To choose the best asset for yourself, I compile a table of pros and cons of each asset. I decided to publish on the forum those shortcomings that I found in the TENKOKU. I hope this helps make your asset even better! I will list the severity of the shortcomings, from the most important ones:

Drawback 1. The scattered light of the sun abruptly disappears at the moment of sunset. In the demo, this moment comes at 19:10, unless you touch other settings. It can be seen how the mountains are lit by light, and then the light disappears. This happens directly very sharply, in one frame.

Drawback 2. In reality, you can see how the night is advancing gradually and half the sky is dark, as at night, and the other half remains light, as in the evening. Only that part of the sky with which the sun rises (or sets) should shine, from the opposite side the sky should be dark. It seems that in the TENKOKU luminescence of the skybox is mirrored in two halves. In sunsets and sunrises, the sky shines from the side with which there is no sun, that is, the glow is duplicated on the two halves of the skybox

Drawback 3. There are no shadows from the clouds.

Drawback 4. There are no shadows from lightning.

Also the issue of SUIMONO 2.0 integration. In the manual to the TENKOKU it is written that compatibility is not yet realized by 100%, which is unfortunate. It would be convenient to use these assets as a single system.

 

Hi, I've used Tenkoku in my early access game: Survisland
And the reflection probe rendering is quite performance heavy, but disabling it will make the lighting of the scene to be very unrealistic and ugly.
Is there any way to optimize it to reduce the performance pike on reflection probe being updated?

 

@Harekelas You can either lower the Probe update FPS in the Tenkoku settings so it updates at a slower interval, or you can go to the probe objectunder Tenkoku-->SkySphere-->Tenkoku_ReflectionProbe and reduce some of the settings there... such as resolution and which game layers it renders. turning off all the render layers and just keeping the skybox fallback should reduce the overhead enough while still giving acceptable scene lighting.

Edit: Your game looks awesome by the way! Congrats, I hope Early Access goes well.

 

Thanks! I'll look into the reflection probe settings, I also own suimono from your studio, considering swap to it for the ocean solution I'm using now is deprecated, again, first Ceto, then playway, now UWS, but suimono always stays there, tho no new updates.
Would really like to see suimono update the wave calculations to a more realistic approch, I know you guys can be real geeks concerning realism.
I'll also add benchmarks of Tenkoku and Suimono(if I finally decided to swap to it) and the tanuki studio in my game's entry scene, as my game is not possible without your awesome assets!

 

I have a small Suimono update coming soon for some bugfixes etc, but a big Revamp is in the works for both Suimono and Tenkoku. It's crazy to see all these water systems come and go, hopefully upcoming Suimono improvements can fill that gap

 

Really looking forward to it!

 

Hey @chingwa , there's a little problem with saving the state of tenkoku. It works fine when random weather is not enabled, all the stats such as wind and humidity are saved and loaded correctly. But if random weather is enabled, everything starts at 0 on load except all the time related variables, like day/hour etc. So for example, humidity, temperature and wind amount start at 0 even on load, not just on start.

What's more is that on start, those variables start adjusting themselves from 0 to get to their right amount. But on load, those variables are locked at 0 until the next random weather pattern is called, at which point the system starts behaving normally again. It's weird because I can see the trees being affected by wind on load even though the weather_WindAmt variable is 0.

 

hey guys, i had this problem with tenkoku when i import volume fog 3,a grey line appears in the landscape, is tenkoku compatible with volume fog 3 ? do you know how to solve it ?

 

@Radu392 Thanks for the report. I will take a look and see what's happening here.

@Kimller I've not tried FogVolume3 on my end, but the line looks to be exactly at the horizon? You can try going to the Tenkoku-->SkySphere-->Effects-->fxCloudSphere object and lower the Y-transform position from 0 to -1 or -2? If that doesn't work does the line still appear if you have all the cloud settings off?

 

Any plans to integrate fog volume with Tenkoku as a true volumetric cloud option?

 

No plans to do volumetric rendering yet. While obviously a cool feature, it can also be expensive. I'm currently focused on getting all current functions up and running in my Tenkoku rebuild to be more efficient/faster than current versions. That being said if all goes well and performance can be protected I would love to do volume fog rendering as a Tenkoku feature.

Don't have any plans on integrating FogVolume3 though, I believe the level of integration required for believable rendering wouldn't be feasible between two separate products(?) Though again, I don't have any experience with the asset.

 

This is great! Optimization is always important! How the development going? When do you plan to release the new update

 

Speed going nuts all the time, it's getting really annoying.

I keep having to restart Unity, the speed goes nuts completely and it makes working with the plugin really terrible, is there something I am doing wrong, I am using 5.6 3f and the latest update of Tenkoku

 

I am trying to get on the forum and as a paid user the registration is pretty impossible, what should I answer for these questions, you got to be kidding a little bit with that. I have a severe bug and need answers.
Why is the speed going nuts all the time???/

 

This is so nasty, every time I save this stupid scene the speed goes nuts, paid a lot for something that doesn't work real well, sorry if I am ranting but there goes my entire morning.
I'd go to your forum but the registration is ridiculous

 

Hi Mike, Can you describe what you mean by the speed? Do you mean the length of day is too fast?

 

Everything looks great, then I save a scene and the speed goes insanely fast.

Turning off "auto advance timer" makes it go still, but then the time is frozen which I do not want

I get the settings working as I like, then I save, and the speed goes crazy.
Copied from your demo scene, dropped in a prefab, both having the same issues

 

Since there seems to be a problem somewhere I recommend to go ahead and un-check 'auto advance system timer'. Then go to the Time and Position tab and make sure 'advance time' is checked and set the 'X' number next to it to 1. Finally, click on the speed curve and make sure it is set to a straight line at 1.0.

I'm not aware of any reason these settings would change by themselves after saving, but just in case I also recommend to click on the 'TenkokuDynamicSky' object in your scene and then go up to the top Unity menu under GameObject--->BreakPrefabInstance... just to make sure it isn't somehow inheriting data from somewhere else.

this should give you a self contained Tenkoku object in your scene with timing set at 1.0 (which is equal to normal real-life time). If you need the time to be faster you would increase the x number next to 'advance time' as this acts as a time multiplier. (for example 2 would be twice as fast as real life time etc.)

I don't recommend copying anything out of the demo scene, it's best to just drag a new tenkoku prefab into your scene from the PREFABS folder.

After following the above if you still have trouble then perhaps there is something else in your scene that is influencing Unity time...? Let me know if this helps or not.

 

the clouds rip by at super speed.

 

Thanks for that, I am trying that now and it seems to work, this is a dragged in prefab I am using now, it is definitely more stable.

 

OK Good! For the clouds you have the choice to sync them to the system time which can be useful under certain circumstances BUT if you have a high time mult setting then clouds will go by really fast. If you want clouds speed to be consistent regardless of the system advance time then un-check the 'Link clouds to system' setting in the configuration tab.

This should all have been done by default in the prefab but I will double check the settings here on my end for future updates, sorry for the frustration! Let me know if you run into any further trouble.

 

I think it was the copy and pasting from the other scene, I'm an artist I think I have the hang of this now, just started using it.

 

I looked through the documentation but couldn't find it. Is there a way to ping pong the day light between say 9 AM to 7 PM and back?
Constantly go back and forth between these 2 times and never go to night?

 

BTW, Any Chance you can make this for Unreal?
really liking this system so far, this version is pretty sweet compared to when we first tested it. (We use a wierd assortment of plugins so it's challenging getting any sky system working in our dev environment).

 

@mike_kennedy989 There isn't a built-in way to ping pong time. However you can write a small script to access Tenkoku time variables and directly ping pong them that way. Something like this:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class Time_PingPong : MonoBehaviour {
5.  
6.     public Vector3 TimeA = new Vector3(7f, 30f, 0f);
7.     public Vector3 TimeB = new Vector3(19f, 30f, 0f);
8.     public float duration = 10f;
9.  
10.     private Tenkoku.Core.TenkokuModule tenkokuModule;
11.  
12.  
13.     void Start () {
14.  
15.         tenkokuModule = (Tenkoku.Core.TenkokuModule) FindObjectOfType(typeof(Tenkoku.Core.TenkokuModule));
16.    
17.     }
18.    
19.  
20.     void LateUpdate () {
21.         if (tenkokuModule){
22.  
23.             //Calculate PingPong
24.             float pingPong = Mathf.PingPong(Time.time, duration) / duration;
25.            
26.             //Calculate Start and End Times
27.             float startTime = (TimeA.x * 3600f) + (TimeA.y * 60f) + TimeA.z;
28.             float endTime = (TimeB.x * 3600f) + (TimeB.y * 60f) + TimeB.z;
29.  
30.             //Calculate Current Time
31.             float currentTime = Mathf.Lerp(startTime, endTime, pingPong);
32.  
33.             //Set Tenkoku Time Variables
34.             tenkokuModule.currentHour = (int)(currentTime / 3600f);
35.             tenkokuModule.currentMinute = (int)((currentTime - (tenkokuModule.currentHour * 3600f)) / 60f);
36.             tenkokuModule.currentSecond = (int)((currentTime - (tenkokuModule.currentHour * 3600f) - (tenkokuModule.currentMinute * 60f)));
37.  
38.         }
39.     }
40. }
41.  

The above code will ping-pong between 7:30 <--> 19:30 based on the duration time (in seconds). This should work very well as long as you're ping-ponging between times in the same 24 hour cycle. The default duration of 10 seconds is really quick, but you could increase this to whatever... 60 for one minute... 3600 for one hour etc.

As for Unreal Engine, no I don't have any plans to release on a different engine... I am already swamped as it is

 

Thanks! I'll pass that too my programmer

 

Hey chingwa,
Will the new Tenkoku update take advangate from the HD Render Pipeline? I just checked some of its features, absolutely amazing, tenkoku may be optimized further more with it, and more beautiful.

 

Do we put this script on the Tenkoku scene prefab?

 

Yeah on the prefab is best, but it should work on any scene object.

 

Thanks!

 

Hi there,

I want to sync the time and weather, etc. through the network. The time appears to sync but that seems to be about it. Is there something else I have to do besides tenkoku.Tenkoku_EncodeData() and tenkoku.Tenkoku_DecodeData(saveData)?

Thank you!

 

@MakeGames2 Encode/Decode should also affect all weather variables. Just to be sure I recommend to set the weather settings on the client version to "manual", while the keeping the server settings as however you have it now.

 

Thanks for the quick response! I tried setting weatherTypeIndex to 0 but it gets set back to 1 from the decode function. When I comment out that line

weatherTypeIndex = int.Parse(data[20]);

in the decode function it seems to do the trick. So I think I can just make my own similar encode/decode functions to sync the variables I want when I want. Now to figure out Suimono. Looking forward to seeing what you have in store next =) Thanks again!

 

Ah I see... Are you using auto/random weather on the server? I suppose it's possible there is a system bug here, but commenting out that decode line should work just fine!

 

Yes I'm using auto/random weather on the server.

I think I discovered what the issue was though. Before I was actually trying to set the weatherTypeIndex before I ran the decode function, right after I had retrieved the TenkokuModule object in Start, and since it was setting it back to 1 when syncing I tried setting it after the decode function each time and it seemed like that might have worked too. I wasn't sure if that might have some sort of effect on it momentarily or not by switching it like that since I'm only trying to sync every 5 seconds. It seems like all it does is pause the transition on the server when I test doing that.

Another issue I'm having is that since it's only trying to sync every 5 seconds, the server appears smooth like normal but the client is abruptly changing whenever it syncs. I suspect because of the transition time. Even though I've set the transition speed up it doesn't seem to fix it. This is why I thought I would have to do something manually to only change what's different instead of syncing every 5 seconds. I'm just not sure yet how I'm going to detect changes but I haven't dug in too much yet. I suppose it can still send the data every so often but I think it should somehow send and set what it should be after the transition rather than what the current transition makes it so that I can also start the transition at the same time on the client.

Another thing is that the currCoords variable was in the encode/decode functions but was private. It only seems to be used for legacy from what I can see though which I wasn't currently using.

The clouds seem to match up pretty close most of the time so I think it will be pretty neat once I figure it all out.

 

Hey @chingwa

I'm using

tenkokuDeltaTime = Time.deltaTime * tenkokuModule.useTimeCompression;

to link some of the times in my scripts to tenkoku time. However, it looks like the method Tenkoku_SetTransition is not updating the useTimeCompression variable, rather it manipulates the hours and seconds directly. Also this makes it so that clouds are pretty much static during the transition instead of speeding up as well. How would you modify the method to take into account scripts that depend on useTimeCompression and clouds?

 

@Radu392 have to take a look at the code and do some tests before answering you in this. I am unfortunately away at the moment, but I can look into this when I return.

 

@chingwa hi man,
Currently i work with boat and ocean project, can you suggest me the spec of system to deal with triple 4k monitors. Thanks for your help

 

Hi @chingwa
May I ask about the status of the new upgrade for Tenkoku?

 

@Dekata a system to run triple 4k? I think you might need a supercomputer... in any case the faster/bigger/more $$$ the better, but I am not the right person to ask about the state of today's computer hardware

 

@Harekelas I apologize for the delay in answering you (and I also see I missed your last question regarding hdrp) I have been away on a trip, but I am now BACK and can properly answer questions etc.

Tenkoku 2.0 is progressing well. Since this is a complete rewrite (I don't think there is a sizable piece of reproduced code anywhere in the asset) it is taking quite a bit of time though as all systems are being redesigned from scratch. All the basic features (sky/sun/star/ atmosphere/fog/ high-alt clouds) are finished and working well... and I am now progressing to the weather and complex cloud rendering systems.

There are a few additions that I can talk about that (imho) make this a better system.

1 - With the exception of fog (which is necessarily a camera effect) all of the rendering now takes place directly in the skybox, which gives better overall compatibility... uses fewer scene objects to calculate and track... improves multi-cam support (VR etc)... and allows for better blending without additional render passes such as happen in the current version. Note that complex clouds have yet to be implemented, and these may require additional rendering passes, it still remains to be seen.

2 - Cloud projection now occurs in world-space, rather than camera-space. This means that clouds are rendered at a specific altitude and can be flown through as one would expect in a plane or flight simulator. Currently this is only working for high altitude clouds, but having this work in some form for lower volumetric clouds is the goal.

3 - Custom lens flare. I've given up on Unity-supplied lens flare systems and ended up writing my own. It has the main advantage of not requiring a collider for obfuscating flare rendering, So tree leaves and grass and other small details will occlude the flare as expected. And it is fairly easy to customize or create your own lens shapes (I have 1 currently, but I'll probably ship with a few options).

4 - Improved sky rendering and customization. I really wanted to improve on the realism and customization of the sky from the current version. To that end many of the underlying sky attributes like tint, air density, pullution etc are editable and saveable using scriptable objects. Actually I'm using scriptable objects for many setting definitions which makes it much easier to keep your settings at hand or make variation sets. I have yet to work on Editor UI, so I'm not sure yet how this will affect the main look of the asset.

5 - Scriptable Render Pipelines... I don't yet have information on this, sorry. Ultimately I can say that 2.0 will in all likelihood be compatible with HDRP (and possibly LWRP??). I have still yet to do testing on this, but is probably something I will at least look at soon.

Hopefully I'll have more to share before too much time passes, but below is the 2.0 sky with high altitude clouds at various times of day.

 

Great looking! Fly through clouds are amazing!
And what about the optimization? Tenkoku runs pretty smooth when the reflection probe is not updating, but when updating, there is a performance peak, it can be a dozen ms or more depending on the CPU.
Is there any optimizations to lower the weight on CPU's side and push them into GPU?
I know that the reflection probe is updated by Unity internally, but is there any way to make it faster? Maybe multi-threading or something like that.

 

There are some optimizations that are done simply by the nature of the new system. Fewer scene objects = fewer per-frame calculations = better performance, I am also looking at different methods for precipitation rather than brute-force particle rendering, and will be looking at more specific optimizations once it gets closer to release.

Unfortunately I'm not sure what can be done about the reflection probe, as it is a necessary middleman in getting sky information into the environment in order to get a cohesive and believable scene. Certainly having it render fewer objects and layers is the main method of optimization, possibly only rendering the fallback to skybox and no scene layers would be OK, but this is rather dependent on the end user's needs in my opinion.

If you were building all these systems to work together in an isolated project then more could be done for optimization (writing your own render probe system, perhaps?) but because of this being an Asset Store product it of course needs to work well in a variety of projects, so we are kind of stuck with Unity standard reflection probes I'm afraid.