TENKOKU - Dynamic Sky

@Teila Not sure if there would be a conflict with Distingo or RTP... but I really wouldn't think so... Tenkoku is just using normal Unity lights. For the dark shadows you can adjust the 'Ambient Tint' color under configuration tab to be a lighter grey (instead of black), or even shift the hue if you prefer. If this isn't adequate then send me an email and I'll send you back the latest patch fix which will allow you to manually adjust the lights shadow intensity and a few other fixes

For the washed out light... you can adjust the light intensity using the Sun 'Light Amount' under celestial settings. This will give you an overboost/underboost depending on the setting.

If you need to adjust the tint of the sun lighting this needs to be done in the 'Color Texture', which provides gradient lighting control based on time.

Let me know if the above helps or if you still have issues getting the lighting you want. If you can send me (PM or email) a screenshot showing your scene lighting before and after it might help narrow down what specific settings need to be adjusted.

 

Thanks!! I did sign up for the beta's.

 

Ah yes, I see you have The patch I spoke of hasn't even been released on my site yet though... I've been sending out only to those who've told me of problems. Honestly I think you can get what you're looking for just by adjusting some settings though, there isn't anything about the new patch specific to lighting, other than unclamping the lights shadow intensity setting.

 

Will try!!

 

Hello all!

Between Distingo and Tenkoku I get some weird colors happening:



I don't know which one it is. Are there some settings I have wrong? Seems to be from my textures, they're just too dark I guess.

I have other textures too but they all have this brown to them, this is just my worse for showing it. I'd like to use these textures as I paid for them at GamesTextures.com

Thanks for any help.

Edit: Ignore that shader error I reimported the shaders to fix that. Got corrupted somehow.

Edit 2: Nvm Distingo did it again so just got rid of it for now.

New SS!



Same textures.

 

@jessejarvis Are your Normal textures marked as "Normal" in the texture importer? If you remove the normal textures from your terrain/material do you still have lighting issues?

 

I think I love you. Haha yeah that was it, forgot I had to mark normal maps.



Now there's just that organe/yellow tint.

 

The light tint varies over the course of the day... morning/evening will have a warmer tint. If you don't like the tint (or think it's just too much) you can edit the color texture in the configuration settings... this texture supplies atime-based color gradient for various system attributes, adjusting the colors in the "sun" gradient will change the default light tinting according to time of day.

 

Okay thanks very much!

 

How would I configure this to say how long I want a day to be in game, and a ratio of day/night? As an example, let's say I want 24 hours in game to take 60 minutes, and to be 60% day, 40% night?

Preferably, in code. I need to be able to configure this at run-time.

Also, Tenkoku_DecodeData and Tenkoku_SetTransition is marked as private in C#. Is that intended? I changed it to public so I can sync the time over the network.

Is it possible to have Tenkoku in a scene without a camera? I delete the camera in my scene when it's the server running to improve performance. Tenkoku gives errors though with that.

 

@emrys90 In order to change the speed of time you can change the "x" multiplier next to "Advance Time" setting. This is a time multiplier... so a value of 1 will be normal real-life time... whereas 10 will be 10 times faster. if you want a gameday to take 60 real life minutes you would set this to be 24.

If you want to change the ratio of day-speed and night-speed, you can change the "Speed Curve". By default this is set to a linear line at 1.0. The X-axis is time (0.0-1.0... where 0.0 is midnight, 0.5 is noon, and 1.0 is midnight again), and the Y-axis is a speed multiplier. by default the night and day are of equal length, but you can change the curve so night is sped up (i.e. higher on the Y-axis) than day is... similar to this...



The above curve gradually sets nighttime to be 2x faster than daytime. This curve is based off the time multiplier as well... so if you're time multipler is already set to 24, then by setting the night section of the curve to "2" the actual multiplier will be 48 for the night section.

If you want to do this from code, it should be possible, but you'll need to create an AnimationCurve through code first (see here: https://docs.unity3d.com/ScriptReference/AnimationCurve.html) and then assign it to the "timeCurves" variable on the TenkokuModule.

Now all that being said, the current version has a bug with the speed curve section which prevents it from working properly. I have a patch which fixes this, and it will be uploaded to the store soon, but if you'd like to get the patch ahead of time just send me an email at konnichiwa[at]tanukidigital.com and I'll email it back to you.

The Tenkoku_DecodeData() and Tenkoku_SetTransition() functions should be set to public, so this is an oversight. Feel free to make them public on your end, this will be fixed in the next update.

As for running Tenkoku without a camera, I hadn't considered this would ever be the case though there is no reason this shouldn't be doable. I'll review the code and write a workaround for the errors that popup. Thanks for the suggestion!

 

Thanks! I look forward to the next version then.

 

If the game is run in the editor, material files are modified. This becomes an issue with a team of people working on a project causing merge conflicts in git if they forget to revert the files. Can you look into fixing this?

I am not sure if this is caused by your asset or not, but I've only seen this happen since I've started to use it I think. I save the scene, the asterisk for changes goes away, and then comes right back. I have to save it twice. Is this a known bug of your asset, or unrelated?

 

I haven't noticed this on my end. Have you tried temporarily removing the Tenkoku objects from your scene just to make sure it's indeed an issue with Tenkoku?

 

I'll try that some time and find out. The materials being modified is definitely Tenkoku though since it's material files in the Tenkoku directory.

How is weather networked? I'm using the Encode/DecodeData methods to sync between the server to clients, but it seems to be different on separate clients. I had lightning strike on my copy, but it didn't for someone else at the same time.

Can you provide any info on the advanced automatic weather? What it'll do, when it might be available, etc.

 

I'll take a look at this... I think lightning hasn't been incorporated into the encode/decode system. Have you noticed any other issues between client/server?

The advanced weather system will give much more control over the probability of weather systems and individual effects (as opposed to being just completely random). It will also include other weather states (temperature etc) that will will be adjustable based on season. I don't want to give a complete list of features yet though as it's still not 100% locked in.

I'll be putting out a bug-fix update (version 1.1.1) soon, and then the new weather system will be coming in the next version after that, later this summer.

 

Yay!

 

The lightning really needs to be done outside of the encode/decode. There is no reason to send the whole group of weather data when all you really need is a distance/bearing from player and a strength. We wired in a single RPC to do the strikes all controlled from a single server version of the weather.

 

The clouds don't always appear to be the same between different clients. I haven't noticed anything else yet, but it seems like weather isn't networked too well, mainly just the randomness is different between clients. My goal is for everything in the weather to be identical between clients. Position of clouds, lightning strikes, etc.

I don't know if this matters, but I am currently doing an Encode/Decode sync once a second. Wasn't sure what an optimal interval for updating is. It would be nice to have some info about that in the documentation.

Thanks for the quick replies.

 

@emrys90 I agree with @CaptainMurphy that it's probably best to isolate individual weather elements and sync them only when needed. However the Encode/Decode system should provide an overall "snapshot" of the whole system for syncing... if you're not seeing any negative effect on your end then I see no real issue with syncing once per second.

The lightning data was running off of it's own random generator, which is likely why the strikes were not matching between server and client. I've matched the lightning random to the master Tenkoku random generator so that it's sync-able across the network now... I'll also take a look at the cloud positioning as well. Next update should be submitted to the asset store in the next day or so.

 

As for networking, I would recommend against doing a timed sync of something that doesn't constantly change. I wrote a weather class that uses properties to manage the changeable items like cloud coverage, precipitation, fog, etc and syncs up any particles or other effects that are outside of Tenkoku like the snow coverage of UBER materials. When one of the values is changed it will fire off the RPC if it is the server and send those changes out to the clients. A timed sync itself isn't really a problem but it can lead to a few issues with overloading the packet buffer if it happens to occur at a time that has a lot of activity so putting it on-demand only will limit the possibility of a buffer overload and stacking up of packets across frames which induces some lag.

For our lightning we took the normal random function from inside tenkoku and made a version that runs in our weather class that has isServer/isClient lock outs to keep the clients from making their own random lightning on top of the server sending it out.

Having clouds exactly the same has never been an issue for us since that doesn't actually affect the gameplay of our games, but it would be nice to have them the exact same. Our focus is making sure the fog and particles render at the same strengths since that can have an effect on visibility and thus affect the gameplay. I wonder if the cloud positions could be tied into the network time since that is already getting synced on games. Saves from sending yet another packet for the sync of weather.

 

Clouds could possibly be linked to Network time, but this may be a different process depending on what network solution you're using. Alternatively I've thought of building an internal Tenkoku time variable that could be shared sporadically to keep timed elements like clouds synced together... the main problem with this type of solution is the possibility of visual stuttering if the clouds are hard-linked and there is some kind of network desync.

 

Most networking systems have a time variable that does predictive syncing, so the client will be constantly progressing regardless of server sync so that when the server catches back up it doesn't cause a massive jump. An example of time variable usage is with Ceto where there is a simple class that does internal time that is overridden if you are doing networking and it replaces the internal timing with whatever solution you are currently using. When the client connects to the server you just create a new timekeeper class and then tell Ceto to use it instead of the internal one. Makes for a quick way to keep it in sync without needing to send something special other than the settings of the asset itself when something changes. If it can keep waves in sync I don't think weather effects and settings can be too hard.

 

Hello All,

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

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

This version is mostly a maintenance update that addresses a number of issues and bugs. Many have been asking me about the upcoming Advanced Weather automation system... this is in the works and should be released in the next update later this summer, but there were a few serious bugs that were brought to my attention and I thought it necessary to go ahead and release this update as soon as possible.

There are also a few requested additions, such as being able to link sound fx to your project timescale, as well as some color and system tweaks. A full list of changes is attached below.

Finally note that with this release Tenkoku has moved over exclusively to C# and there will no longer be a matching .JS 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



----------------------------------------------
RELEASE NOTES - Version 1.1.1
----------------------------------------------

WHAT'S NEW
- Added Public variable moonPhase that calculates current phase of moon (0.0f - 1.0f), where 0.5 = full moon.
- Added Public variable moonLightAmt that calculates current light reflectance factor of the moon (0.0f - 1.0f)
- Added Sound effect "Adjust via timescale" option which will morph sound based on scene Timescale settings (on by default).
- Improved ambient rendering with sky color weighting (using Trilight ambient mode).

CHANGES
- Lowered default light bias to 0.05. This should fix 'unattached' shadows rendering error.
- Adjusted default sun color balance to be less warm during midday hours.
- Adjusted default ambient light color balance.

BUG FIXES
- Fixed Build namespace error, which had prevented build compilation.
- Fixed Error with Speed Curve not affecting timescale properly.
- Fixed issue with sun light disengaging too early when multi-lighting is turned off.
- Fixed issue with multi-lighting not turning moon lighting on correctly in some instances.
- Overcast setting no longer effects light shadow setting, and instead adjusts diffuse lighting amounts.
- Tenkoku_EncodeData() and Tenkoku_DecodeData() function set to be publicly accessable.
- Fixed Tenkoku_SetTransition() function to be publicly accessable.
- Fixed issue where transitions would not stop at various target times.
- Slight tweak to Galaxy texture positioning for better alignment.
- Added more blur to Galaxy texture, to remove pixelization.
- Fixed Unity 5.4 (beta) bug relating to editor loading, causing error message spam.
- Fixed error message spam when no camera is active in the scene.
- Included Temperature, rainbow, and lightning data into Encode()/Decode() server functions
- Fixed error with encoding/decoding cloud position data.
- Fixed problem with saving setting changes in Unity 5.3+

 

Congrats!

Any update on the fix for moon and sun shafts?

 

Sorry @Pyroman311 this didn't make it into this update. It's still on my to-do list though and moon-shafts should be added back in with the next one.

 

With this newest version, will lightning and cloud positions be synced correctly if I do it once a second, besides the obvious detriment of increased bandwidth usage? What's the longest interval that is safe to sync at? At some point I'd probably look into changing to only sync as needed, but at the moment Encode/Decode seems to be the easier option and trying to make quick progress.

When I tried to download using the link you provided, I got the following error:
file ID: mode: downloadthat file does not exist... !!!

 

@emrys90 In order to download from my website you need to have registered your purchase, and then login using the provided serial number. You can do so here: http://www.tanukidigital.com/tenkoku/index.php?register=1

Or, you can wait for it to be approved on the asset store. It was submitted yesterday and usually takes a few days for them to approve and post it. I'll leave a note here once it's updated on the store.

This latest version should now sync lightning random key, so they should be identical from server-->client. The cloud positions also are now being synced (they weren't before... just the cloud state, not the position) so they should be matching much better. But definitely let me know if you still see trouble. Thanks for your help!

 

Okay thanks. How often does this data change? Just trying to determine the interval that I should sync it at, to save bandwidth.

 

I think the interval can remain unaffected. The main problem with the lightning was that it was being run with a different random seed, so once they are synced once it should be fine. The beginning offset of the clouds was also not synced, so that should be fixed with this update.

 

I'm mainly wondering if I can increase it to something longer than a second, to save bandwidth if nothing changes over a one second interval.

 

Yes I think so. The main thing to consider is how often your weather states (cloud coverage, precipitation) and time settings will be changing in your scene. If you set up the system and it runs the way you want it for a while you can spread out the encode/decode functions quite a bit I think. But you'll want to do faster updates anytime you adjust a weather or time variable... For example if you increase/decrease the advance time factor, or if you manually adjust the cloud/weather amounts then you should do a sync update.

 

If I don't manually change the weather settings, only using the automatic random setting, is that deterministic? It will generate the same random results on the server and clients?

 

Yes, in the 1.1.1 update, the random results should be the same across both client/server... as long as you initiate at least one encode/decode sync session.

 

Is that only if they are started at the same time? I haven't looked through the code, but if there is an in-progress client connection will it sync the current time point in the encode/decode to get them at the right point?

 

It syncs on every encode/decode... though I haven't directly tested if having a delayed startup would have a negative effect. I'll have to investigate this a little more in depth.

 

And the latest update is now available on the Asset Store here: https://www.assetstore.unity3d.com/en/#!/content/34435

 

Thanks for the moon phase update. I have my moon UI on the upper right.

 

Very Cool! Thanks for sharing

 

So I updated to your newest version, and clouds are still not in sync for me on different clients. When one client joins the game, there's no clouds on the screen at all, even though there's clouds on another client. All I have to do is an Encode/Decode, right? I know that portion of my code is working correctly because the time in the game is the same on both clients. Also, does weather sync correctly? I've yet to see it rain in the game.

How do I get stars to show up? All I ever see is the moon.

The fix for not having a camera in the scene seems to be working good, thanks!

I don't know how much this matters, but while running a profiler I see that tenkoku allocates several KB of garbage per frame. My understanding is it's best to try and not allocate things every frame if you can. Is there anything you can do about that?

 

Hey @chingwa
Tenkoku's performance costs are pretty extreme. Admittedly, I am both targeting and using low end hardware, but still, the performance numbers are a little unnecessary.

There is some pretty crazy stuff in there. Including doing string parsing to send messages to sun shafts in lateupdate. The cloud shader is 1500 lines, it runs 56 passes. In terms of performance, it costs more than DoF and SSAO combined!

Between all the methods it has gotta be allocating somewhere between 10-20k per frame.

There's a lot of stuff in there that isn't rocket science to fix, like the string passing. The cloud shader is intimidating for me since I'm a shader noob, but there's a lot of low hanging fruit in terms of optimizing the code.

I'm wondering if you have any plans to really focus on performance any time soon?

 

@emrys and @frosted I'm always interested in improving performance. Some of the issues you mentioned are holdovers from early days and can certainly be improved now that all components are in C#. I'll definitely get those string conversions and SendMessages fixed and will take another look at other optimizations as well. All your suggestions are appreciated and welcome!

 

So far I've replaced the send message calls (there was obviously a very old hold over to the sky blur - as the method doesn't exist anymore).

I also replaced the skyblur with an implementation of the optimized blur instead of the normal blur - as this also allocated per frame (and cost about 10x more time).

The cloud shader is really the biggest cost, he's pretty huge. I'm absolutely sure there are ways to cut down the number of passes, but it's just such a daunting file.

If you want the source changes I'll email them. I've got almost all the per frame allocations out which is cool, the sky blur costs are now trivial (the results are slightly different, but very very close)... but the cloud plane layer. That's the big one.

 

Sure, anything you'd like to send can be directed to konnichiwa[at]tanukidigital.com
The cloud shader is a beast for sure. I have plans to replace the whole cloud system at some point in the future, but in the meantime I'll look at doing some better optimizations on this sucker, and make it a point that these make it into the next release.

 

@chingwa Will you be looking into why the clouds are not getting synced? Am I doing something wrong, since it said it was fixed in the last release?

 

@emrys90 yes, sorry I missed your post. I'll take another look at the cloud sync issue soon.

 

@chingwa, would it be possible to set up a private git repository for us to start sending pull requests to? It might be easier in the long run if we could submit the changes and see upcoming code changes in a private repo.

 

@chingwa
I'm not going to send my changes, honestly I've started to just kind of customize tenkoku and my changes may break things for other people.

The vast majority of the memory allocs involved the strings and sendmessage, these are very, very easy to replace.

The sky blur was using the exact approach from unity's blur effect, if you replace this implementation with the one from 'blur optimized' it will also cut down significantly on the overhead from this (as well as remove the allocations).

Code (csharp):

1.  
2.             //set project layer masks
3.             tenLayerMasks = new List<string>();
4.             for (i = 0; i < 32; i++){
5.                 layerName = LayerMask.LayerToName(i);
6.                 tenLayerMasks.Add(layerName);
7.             }
8.  

You are doing this in late update at runtime. Rebuilding the list allocates. I just check if it exists to avoid the allocation - but this may break editor usage for people (but you also do it in update when not in playmode - so I think this would keep the editor working).

I've experimented with various texture resolutions and found that surprisingly they had very little effect on the cloud shader's performance costs.

 

Alright, so I sat down with the cloud shader a little bit and I see what you're doing here.

I think that you can get very similar results with way, way cost by just doing something like the following:

Code (csharp):

1.  
2.  
3.         void surf (Input IN, inout SurfaceOutput o) {
4.             half c1 = tex2D(_MainTex, IN.uv_MainTex * 1.4 + (windCoords.xy*_cloudSpd.y)).g;
5.        
6.             o.Albedo = fixed3(1,1,1);
7.             o.Alpha = c1 * _amtCloudC;//*_colCloudC.a;
8.  
9.             o.Alpha += tex2D(_MainTex, 0.999802 * IN.uv_MainTex * 1.4 + (windCoords.xy*_cloudSpd.y)).g
10.                    * _amtCloudC;//*_colCloudC.a;
11.  
12.             o.Alpha *= tex2D(_BlendTex, IN.uv_BlendTex).r;
13.        
14.             float4 uv0 = IN.screenPos; uv0.xy;
15.             uv0 = float4(max(0.001f, uv0.x),max(0.001f, uv0.y),max(0.001f, uv0.z),max(0.001f, uv0.w));
16.             skyColor = tex2Dproj(_Tenkoku_SkyTex, UNITY_PROJ_COORD(uv0))*0.88;
17.  
18. half dpth = max(IN.screenPos.w,0.001)/_TenkokuDist;
19. depth = saturate(lerp(3,0,dpth));
20.  
21.         }
22.  

Basically, if you look at line 9 instead of doing additional passes, it just slightly offset the uv (this I believe lines up with the - (v.normal * .198) offset you used on the cirrus clouds second pass).

It seems like the vast majority of the overhead in the cloud shader is just these slightly offset passes. This may lose some extremely subtle difference since we're not using the normal here for the second offset but to my eyes it's exactly identical.

I would personally just add more variables to the input struct that capture the offsets you want precisely but I kept getting "too many interpolators" errors. I haven't really worked with surface shaders and moving absolutely everything to vert/frag is way, way too much work.

I noticed that the majority of the shader is also really working on the low clouds. I know these guys must be hard to get visually correct (I remember the first version ;D) but it's also worth noting that if someone is very performance minded, just removing the cumulus layer entirely represents a giant improvement in fps. Obviously these clouds look great and that's not ideal, but it's worth having the option - (also worth keeping in mind if cumulus clouds = 0).

For now, I will just sort of hack the clouds like this for myself (looks decent), and wait for you to do a proper fix

 

@CaptainMurphy To be honest I'm a complete GIT-noob. I had to go google what a pull request was. I'm not quite too old to learn new tricks though. Is this something that you've seen other Asset Store developers do?

@frosted Thank you for the code breakdowns and tips! The cloud shader edits are an interesting idea... so you're talking of doing multiple XY offsets from the cloud position in a single pass rather than doing vertical vertex offsets? I can see how this would contribute to better performance (it's those vertex offsets that force me into doing multi-passes), I do wonder how the visuals will compare, especially at glancing angles. I will investigate further.