Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Time of Day - Dynamic Sky Dome

Discussion in 'Assets and Asset Store' started by andererandre, Mar 4, 2013.

  1. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Just a quick update on a few things:
    • I decided to include some simple weather type management (fade between weather types) regarding the sky dome parameters (mainly cloud-related) but no particle effects for now as most of you wanted to keep the package focused, but some wanted to at least control the sky dome a little better. It's wrapped in a single script that's disabled by default and should be easily customizable. I hope this solution is okay for most of you guys, but as always I'm open for feedback. For now there will only be the three basic weather types clear, cloudy and stormy (+ any of your custom settings of course) as the focus of 1.5 is on all the other new stuff and changes. It's still a possibility to offer some sort of addon containing rain and snow particles, snow shaders and weather sounds at some point in the future, but as most of you said that's not the point of Time of Day itself.
    • I thought those of you targeting high performance platforms (PC, consoles) for games like flight simulators may want to have 3D volume clouds. I therefore decided to start working on a volumetric cloud system (sold separately, fully compatible to Time of Day). I implemented a technique that (as far as I know) hasn't been done in Unity before and isn't even being used in most current AAA games (flight simulators might do something similar but the exact technical details are unknown in most cases). It offers superb performance compared to clouds consisting of hundreds of alpha blended particle renderers and is based on actual volume rendering of 3D textures. The results I achieved so far look really good, you can definitely look forward to it if you're interested in that sort of thing.
    • I'm going to submit Time of Day 1.5 for review this week.
     
  2. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,507
    Very, very interested to see your cloud system :) If it is a post process approach, I haven't had good experiences with that :(
     
  3. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    I read about the post-processing volume rendering approach but I actually managed to implement my cloud volumes in a normal fragment shader. Applying correct lighting has been quite the hassle but I achieved some very promising results. It will be Unity Pro only however as access to the depth buffer is required to handle intersecting objects. That's all I can say for now, stay tuned.
     
  4. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    So 1.5 has already been reviewed and is available for download! It's amazing how fast the Asset Store reviewers do their work. I also updated the demo scenes and the screenshots in the first post, just make sure to refresh the page to clear the old ones from your cache.

    Version 1.5 Changelog:
    • Enabled mip mapping of the stars texture by default to avoid flickering
    • Added support for using custom skyboxes at night (see readme for details)
    • Greatly improved the parametrization of the sun color influence at sunrise and sunset
    • Added internal pointers to commonly used components for faster access
    • Split the sun and moon parameters into their own property classes
    • Adjusted the cloud shading calculation to keep it from darkening some clouds too much
    • Adjusted the color wavelengths to produce a more realistic blue color of the sky by default
    • Made the moon phase influence the intensity of the sunlight reflected by the moon
    • Replaced the lens flares with custom halo shaders that are correctly being occluded by clouds
    • Enabled the new halo effects on mobile
    • Moved all shaders into a "Time of Day" category
    • Added a basic weather manager with three weather types
    Thanks again for your support and the positive reviews in the Asset Store! If you haven't rated the package yet it would be nice if you could do so - it really helps spreading the word.
     
  5. cl-apps

    cl-apps

    Joined:
    Mar 16, 2013
    Posts:
    128
    Just picked this up on the asset store and have to say for optimisation and visual appearance this is really great! I've got both UniStorm and Silverlining which both haven't hit the sweet spot for me and tend to have looked a bit limp. Your solution looks perfect and with a touch of mobile bloom gives a rich sky without much performance impact! I hope you continue to tweak and add more as you have created a very special system. Well done!
     
  6. ChezDoodles

    ChezDoodles

    Joined:
    Sep 13, 2007
    Posts:
    98
    Same thing for me!
    Excellent stuff - I also have both the two other solutions (which are both great - but they just didn't "click" with me) - and I am very impressed by this one - and at $50 it is a no-brainer.

    Looking REALLY forward to the volumetric skies though. I hope they will work equally well both from a first person kind-of-ground based view - as well as more of an overhead RTS style viewpoint.
     
  7. daisySa

    daisySa

    Joined:
    Dec 29, 2011
    Posts:
    341
    The new version is very nice - it's great to see this asset progressing.

    One question re the new Space feature: I've created a custom skybox for the night sky. I've disabled the Space child object and pointed to my skybox in Render Settings. How can I configure Time Of Day so that the skybox is only displayed at night?

    If I change Clear Flags on my main camera from Solid Color to Skybox, the skybox is visible at all times (i.e. including during the day).
     
  8. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Looks like I didn't test the built-in skybox after changing the render queue in my shaders. It's a minor change and I'll submit a hotfix (1.5.1) today. It should be online around Monday.

    The technical details in case somebody wants to fix this on his own before the hotfix is available: I changed the shader queues from "Transparent-X" (around index 3000) to "Geometry+X" (around index 2000). The built-in skybox shader is actually in the queue "Background" (which would be index 1000 and therefore before "Geometry") so I thought this change should work without any issues. However, Unity apparently does something special and renders the built-in skybox at index 2500, leading to the issue that the built-in skybox renders in front of the dome.
     
    Last edited: Jul 14, 2013
  9. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    After 3 days of waiting for review by the Asset Store team, 1.5.1 with the hotfix for built-in skyboxes is now finally available. Looks like the recent promotions put some extra workload on the reviewers.
     
  10. VIC20

    VIC20

    Joined:
    Jan 19, 2008
    Posts:
    2,439
    I know it sux to say that… but Isn't the red dawn now way too less? I've skipped some versions and find it hard to create a setting that works at all times with a nice evening morning now.
     
  11. daisySa

    daisySa

    Joined:
    Dec 29, 2011
    Posts:
    341
    LOL - I've been playing with it and I arrived at the same conclusion, but was hesitant to post - it's gone a bit too far the other way now. :)

    OTOH, the 1.5.1 update has fixed the skybox issue, that part is working perfectly!
     
  12. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Have you tried increasing the "Falloff" and "Coloring" parameters of the sun? Especially "Falloff" changed a lot in 1.5, if you set it to 1 before you now have to set it to 2 to see the same result. You shouldn't go too far with "Coloring" though, 0.5 should be enough.

    EDIT: Another thing that changed in 1.5 are the wavelength constants for red, green and blue. I'll look into these again if the issue persists and try to find a middle ground, so please report back if you were able to achieve what you wanted by adjusting "Falloff" and "Coloring" or if I should take another look at it.
     
    Last edited: Jul 20, 2013
  13. VIC20

    VIC20

    Joined:
    Jan 19, 2008
    Posts:
    2,439
    You know the math behind it - it would be REALLY nice to have some presets of different realistic conditions to avoid creating nonsense (setting the right colors can be hard - and don't forget 10% of all users are in some way more or less "color blind"). In my quick test I could not set "Falloff" to some value that worked nice for all times of the day.
     
  14. daisySa

    daisySa

    Joined:
    Dec 29, 2011
    Posts:
    341
    I've played with Falloff and Coloring but unfortunately I haven't been able get enough orange into the sunsets. It still looks great, but as VIC20 said, it's just too much the other way now...
     
  15. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Alright, feedback received. Let's see what I can come up with in 1.6 to solve this. Presets do sound like a good idea. :)
     
  16. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,095
    ToD looks really great in my project, but I need to use the mobile version. Can you elaborate a bit on this note in the readme?
    "...all you have to do is set the noise texture in the cloud shader appropriately."

    Does that mean changing that texture itself (increasing contrast/noise?) or adjusting other variables?

    thanks
    Dave
     
  17. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    The package comes with 3 different noise textures, you can either choose one of those (they basically have adjusted color curves to achieve different kinds of contrast and cloud shapes) or create your own in Photoshop, Pixelmator or whatever else you want to use. This is necessary because at the moment the mobile version does not modify the contrast of the clouds in the pixel shader as it's a fairly expensive operation.
     
  18. angel_m

    angel_m

    Joined:
    Nov 4, 2005
    Posts:
    1,145
    This is exactly the general problem I mentioned with sky domes (sphere or hemisphere mesh). And it remains unsolved without using two cameras.
     
  19. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    This is not true. As I replied to the post you quoted the issue was that the Unity fog wasn't being ignored properly. I fixed this a long time ago and the sky dome renders just as good as the built-in skybox system. The only minor annoyance is that you have to scale it manually to fit your far clipping plane - but the visual result of the sky dome itself is completely independent from the sky dome scale.

    It's true that a lot of packages do not deal with this correctly and screw their sky dome scale up or make it so that the scale cannot be changed without breaking something. This is not the case for Time of Day.
     
  20. MaliceA4Thought

    MaliceA4Thought

    Joined:
    Feb 25, 2011
    Posts:
    406
    Greetings.

    I just wanted to check a couple of things, and please forgive me if it's been covered in the previous pages, but it's late and if so I missed it in the excitment of seeing this :)

    If I have a known Lat and Long, from that if I download the latest METAR data, can I inject into this the accurate weather from that location to be displayed, along with the real world time for that location?

    If so, how many cloud layers can I inject into this to represent the METAR data?

    Regards

    Graham
     
  21. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Importing weather data is not supported at the moment as so far the updates focused on the day/night cycle. The weather system will be extended with regards to weather types and weather conditions in the next update, but even then the parsing of the METAR codes would have to be done by you.
     
  22. MaliceA4Thought

    MaliceA4Thought

    Joined:
    Feb 25, 2011
    Posts:
    406
    Awesome, many thanks.

    Yes, i expected to have to load and parse the METAR data, but providing i can then translate that to set cloud types and levels and wind directions in the system, that would be the ideal solution.

    Many thanks for the reply.

    Regards

    Gaham
     
  23. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Purchased today -- marvellous work, awesome add-on! Looking forward to using this on mobile.

    Here's a glitch: I get a pink/purple sun using the mobile sky-dome (haven't tried the desktop one yet). Both in the stand-alone player and in the Unity integrated Game View --- both with Forward and Deferred render path --- both with DX11 and without.

    To reproduce: "Linear color space" is enabled for the player, "linear lighting" for the Sky Dome, and "HDR" for the Main Camera. Can send you the project if you like. Unity Pro 4.2.

    $time-of-day-pink-sun.png
     
  24. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    I reproduced the bug and found the cause: The mobile prefab has a material that cannot be found assigned to it, look at the renderer component of the sun game object and change the size of the materials array from 2 to 1. You should do this for the prefab, that way all your future instantiations will automatically work.

    I'll submit a fix for this and a few other minor issues people reported this week.
     
  25. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Great, looking forward to the update -- really appreciate your work! Hammerteil!

    1. Later on (weeks or months later ;), I'll probably check back with specific questions on how to exactly get sunrise and sunset red-orange scene lighting and sky tinting tweaked to approximate real world appearance with respect to lati/longitude and day-of-year --- but this isn't too urgent. As some previous commenter pointed out, unlike Silverlining your project *does* provide all the knobs to tweak this for earth or other planets --- which is great! --- but at the same time, most of us don't have a freaking clue on how to use these sensibly (from code dynamically) --- anyway, that's not too urgent.

    2. But another thing I was wondering about --- maybe your shader does implement this effect but I haven't specifically noticed it yet: shadow-of-the-earth in the atmosphere during sunrises/sunsets (most visible from higher vantage points or with otherwise very far viewing distance). Example: http://www.cloudynights.com/photopost/data/500/2660Earth_Shadow.jpg or google images for "atmosphere earth shadow".. this adds greatly to an atmospheric scattering shader's authenticity and since you're already getting a gradient on the screen even now, might be fairly easy to add (unless it already is included and I just haven't noticed it yet). See also figure 8a on page 7 in the 2008 Inria paper "Precomputed Atmospheric Scattering" by Bruneton/Neyret

    3. In the Unity live player (game view) I notice that night skies render more than twice as fast as day-time skies. Specifically, only as long as the sun is in fact being rendered, so it's not per se the sky gradient or clouds. Presence of the sun halves the frame-rate when rendering other stuff too (still in the many 100s so not hurting right now). When rendering nothing else it's not quite as extreme, but still I notice 3200 tris without the sun, 4700 tris with the sun. And that's the mobile optimized spheres? I should one day experiment with even lower-poly meshes for this. On small phone screens with everything else being lo-poly, I doubt anyone notices an "edgy" sky --- heck no non-hardcore gamer ever even noticed the sky was a cube in old games! But with a low-poly budget of say 100k per render, sky and sun eat a lot of that budget already! Compared to a cube-mapped skybox I mean. What was the reasoning for the sun mesh? It's supposed to end up as a big glaring white blob that could just as well be a 2D sphere, or am I missing something? Why are we spending 1500 triangles on it at present (from what I can tell at least from the render stats).

    Cheers, thanks again for making this and looking forward to the next update! Once I've moved on from 99% satisfaction to 100%, I'll better write "the best review ever written" :D
     
  26. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
  27. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    1. Alright, I'll brace myself! :)
    2. Earth shadow isn't included at the moment, you're correct. It might be something to look at when everything else is polished and 100% complete though.
    3. The sun mesh has 760 triangles - which is a fairly huge amount but nothing too insane, even for mobile. I'm currently trying to get rid of the necessity of the sun mesh altogether to reduce overdraw and possibly allow for the cloud sharpness parameter being applied on mobile using the precious cycles freed in the process.

    Your screenshot looks like it could use an increase in the mie multiplier (try 0.15 to 0.2). However, if you don't need to release your project right now it could be worth waiting for the next update (which as I mentioned will completely remove the separate sun mesh to save triangles and overdraw) before wasting development time on tweaking something that will soon be obsolete.

    Last but not least: Thank you for providing me with essential feedback to improve the package even further! Only things that are being reported can be changed, community interaction is really the most fundamental part of polishing a package. Thanks to you and to everybody who contacted me in one way or another.
     
  28. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Looks like the submission this week will be 1.6 instead of just a little hotfix.

    Version 1.6 Changelog:
    • Improved the visuals and functionality of the weather system (most METAR codes should now be possible to achieve visually)
    • Improved performance of the moon halo shader
    • Added official support for HDR rendering
    • Replaced the sun mesh with implicit sun scattering in the atmosphere layer to reduce dome vertex count, draw calls and pixel overdraw
    • Added an additional quality level (now Low/Medium/High instead of Mobile/Desktop)
    • Added sky dome presets from various locations around the globe for easier use
    • Tweaked the wavelength constants a little to allow for a wider range of sun coloring adjustments
    The quality level "Medium" is meant to be used on devices like the iPhone 4 and iPad 1 if your scene is fairly optimized and you have some free cycles on the GPU. Said cycles will be used to apply the dynamic cloud sharpness parameter in the fragment shader, which costs around 5-10 FPS on the iPhone 4, depending on how much of the cloud layer has to be drawn. On the other hand the "Low" quality setting should run about 2 FPS faster now as I simplified the cloud layers even further. It should only be used when your scene is very GPU intensive (overdraw, transparency, not much sky is being occluded by other objects, ...) or simply not as highly optimized and you need every free cycle you can get.

    At the moment there are two presets in addition to the default one: Tropical and Nordic. The first one features a more reddish tint at runrise and sunset and the second one a very clean blue sky. They should mainly provide a starting point to configure the sky dome yourself or just offer an easy way for those that don't want to invest a lot of time to read through all the parameters in the readme file.
     
    Last edited: Aug 9, 2013
  29. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Sounds awesome, can't wait! :D (OK I can wait if I have too...)
     
  30. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    I had to fix one more thing related to HDR rendering yesterday and finally submitted the update (now 1.6.1) for review by the Asset Store team. I'm not sure if the update will be reviewed and released this week, it might take until some time next week - depending on how much they have in their review queue at the moment.

    To make your waiting a little less painful, here are some screenshots of the new stormy weather possibilities:

    $screenshot-10.jpg

    $screenshot-11.jpg

    $screenshot-12.jpg

    EDIT: Some of you asked me about Oculus Rift support and I'm currently talking to someone who owns a developer device. We'll see to figure out how to support this kind of technology in Time of Day, stay tuned for more information on that. I don't want to state any Oculus Rift support officially in the package description before I receive some sort of positive feedback by someone who actually owns an Oculus Rift though. That said, the things I found out so far look promising.
     
    Last edited: Aug 11, 2013
  31. rchassereau

    rchassereau

    Joined:
    Nov 7, 2012
    Posts:
    10
    I'm having an issue, and I wonder if anyone else has seen it. Just after dawn, and just before sunset, the rendering of the world gets screwed up - only very distant terrain/trees gets rendered, anything near the player (including the player model) disappears for a brief moment. The duration of this event ties in with the length of the day; if I set it to 1 minute, it only happens briefly, but a longer day results in this issue lasting longer. Any ideas on what I'm doing wrong?
     
  32. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    What do you mean with "disappear" - does it become black all the sudden or do you see the sky dome where your objects should be?

    A few things to check:
    #1 Are you using light maps? Light maps should only be used when the sun does not move as they are static. With a dynamic day/night cycle you should always only use realtime shadows. Ignoring this leads to rendering artifacts.
    #2 Did you read the readme file and follow the instructions? You need the SkyCamera.cs script attached to your camera and set the reference to the sky dome. This moves the sky dome and makes sure it's always centered around your camera.
    #3 Do the demo scenes work?

    If those two things are not the cause, please upload a screenshot and post it in this topic (or send it to me via email or personal message if you don't want your project to be publicly visible yet).
     
    Last edited: Aug 12, 2013
  33. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Finally 1.6.1 update made it to the Asset Store, yay! :D Playing with it right now..

    Right now I'm only getting 60fps for the "empty" demo scene even though I have turned off vsync for all quality settings in my test project. But this seems more like yet another weird unity bug...
     
  34. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    FPS issue fixed. Now here's a (hopefully almost last ;) ) feature request... a new mesh "ultra-low-poly sphere" and getting rid of the "3D moon model"... :rolleyes:

    Here's the thing. I created a new empty dummy scene with a cam and added the "tropical (low)" prefab. Press play and I see "Tris: 3.2k" in stats, up to 5.8 as soon as the moon shows up (btw. why is the moon 3D instead of an oriented billboard quad?). Then while playing I go through your sub-objects in the Hierarchy view: Atmosphere, Clouds, Moon, Space --- and while still playing select for all their "Mesh Filter" components a new Mesh, specifically Unity's built-in "Sphere" mesh. Now I'm down to "Tris: 2.3k" without the moon, and "Tris: 3.8k" as soon as the moon shows up.

    That's a savings of 900 tris or a whopping 2000 with moon! A great deal on mobiles, a very great deal (lets me add a few birds or rocks or detail-meshes or, you get the idea, that I couldn't afford previously). I will experiment with ultra-low-poly spheres if I can find some FBX online (am not a modeller). In fact I'd love the old-school "sky box" (as in cube or even 4-sided pyramid) approach if feasible but seems like your shaders don't work with the built-in cube mesh right now. No problem, they're so cool anyway. But since cubes are not an option it seems, I'll go and see how low-poly I can go with spheres before things start looking **really** bad (by that I mean -- even so bad casual mobile "5 minute gamers" would notice).

    Well anyway thanks for the great update, it's definitely gotten from great to freaking awesome nonetheless! Will report back on my findings of my low-poly explorations.
     
    Last edited: Aug 13, 2013
  35. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    The reason the moon is a sphere is that moon phases are continous, not just discrete. The shader applies shading related to the moon phase parameter to the sphere, so a simple 2-triangle billboard is not possible. The triangle count of the built-in Unity sphere is 760, which I find is acceptable for the moon, but I can look in how far I could reduce this even further for the "Low" detail prefab.

    By the way, as the readme states, the moon mesh has to be rendered twice - once for the halo and once for the texture. If you want to save some triangles you can remove the halo material from the moon renderer component, that will save one draw call and therefore 760 tris and most mobile gamers won't notice it due to the small screen and generally hectic gameplay. I will probably make that change for the "Low" prefab by default in the future.

    The reason the sky dome cannot be a box is that the physical model that calculates the color has to be solved per-vertex. If I solve the model per-pixel instead of per-vertex the visual quality will stay the same with a box - but the calculations will take way longer (solve the equations for millions of pixels instead of a few hundred vertices).

    What I did is choose so-called icospheres as the sky dome meshes because colors interpolate nicer on their equilateral triangles than with the common spheres one usually uses to map UVs to (like the Unity built-in one). The tri count of the mobile version of that mesh is already quite low (1280 tris), but I'll see to reduce this (to 1/3 to be exact, one subdivision step) for the "Low" prefab and see how that looks. If the visual result is acceptable I'll include this by default.

    I hope that explained the thought process a little, and as always thank you for providing feedback!

    EDIT: And thank you so much for the great review on the Asset Store! It really helps a lot!
     
    Last edited: Aug 13, 2013
  36. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Thanks for the clarifications regarding the moon! Makes a lot of sense.

    First a bug report, with the newest version changing the "Clouds" preset in the "Sky Weather" script changes nothing. Whether I pick "Few" or "Overcast", always looks like "Default". Both changing live in Game View and also changing offline in Inspector, then re-starting Game View. Strangely enough, the only preset that changes the appearance of clouds is "None", which works and clears all clouds. Fade Time is always set to 1 at my end during testing (but same for 0 or any higher value).

    ((Edit: had some fps timings here but removed them for now as I take more accurate and complete readings.))

    One more thing: After experimenting with Unity's "sphere" mesh, I went crazy with this "ultra-low poly" ball mesh (80 triangles). All looked great enough for my casual-mobile use-case except the clouds... are the UVs off in the mesh or is there a more complicated cause for this? This low-poly polygonal "sphere" has 5 latitudes and the upper 2 look absolutely fine! The lower 2 latitudes don't matter since they're never visible. But the middle latitude was sadly completely messy regarding cloud rendering. Do you think you could include an ultra-low-poly mesh like this that would work for clouds? Just wondering, maybe it isn't too much trouble for a pro shader hacker like you :D

    Of course, the moon doesn't look very round anymore but for this quality setting for old (well 2012 and older) phones it won't matter for the game play and use-case, everything will look quite low-poly art-wise anyway so a moon like this would fit in totally fine. Just the clouds are bugging me....

    OK that's all for now. Awesome package really!
     
    Last edited: Aug 14, 2013
  37. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    OK here are some FPS timing stats for a 1-year old single-core low-resolution "consumer phone" that has an enforced, immutable hard cap of 60hz vsync. That's kind of the "lower end" I'm targeting. (Worse phones than that I don't care too much about, or can skip the sky dome for a blue background or something.) But these figures suggest only the "space" layer is bottlenecking the otherwise very fast skydome somewhat:

    https://docs.google.com/spreadsheet/ccc?key=0AnzOubYZgGCldGN2VDNZN1R3cE1WT3JOYVlvTHhwMWc&usp=sharing

    I should add that ToD runs super smooth on a summer-2013 high-priced quad-core phone. That's amazingly cool! (Well unless it takes the full 16ms within the constantly observed 60fps -- that'd be nasty. But I'll find out in the future ;) )

    For the spreadsheet: the first 4 rows are for using Unity's built-in "sphere" mesh for the Sky Dome's Atmo, Clouds, Moon and Space layers. The last 4 rows use the low-poly (80 tris) "ball" mesh linked in my previous post. In both cases, the "low" prefab was used, with transform's scaling set to 1000.

    All recorded "tris" over 1k are Unity's rough estimates from Game View. But ultimate I want the SkyDome to stay way under 1k tris anyway :cool:

    All timings have been taken 3x for each config. On a freshly-booted, plugged-in phone with all other apps closed and wifi disabled, for a clean starting point. Each time I let the game run around a minute to get a good average (the first 10-ish seconds always seem to be slower warmup seconds). Timings never differed in any substantial way consistently between day and night, even regarding space disabled or enabled. Timings have been taken with Moon Halo on, but for the lowest (40 fps) I have tried with Moon Halo off, no difference. Indeed only the space layer seems to make a difference.

    You can see, whether I use the sphere or the ball: the phone gets full 60fps most of the time only whenever the space layer is disabled, as soon as the space layer renders, performance degrades a fair amount!

    Now I'm wondering, what's up with the black space layer? Isn't it just a shader sampling a 2D texture? That can't be it, the moon does so too and introduces no such lags...
     
    Last edited: Aug 14, 2013
  38. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Last update on this for now. I took the worst-case timing of 40 FPS. Replaced the star field with a black 32x32 texture and got up to 45 FPS. Removed the 3 calculations in the vertex shader of Space.shader (I used to hack a bit in GLSL so I'm no total stranger to shaders) and now we're up to 55 FPS (of course it won't show a texture here but a diffuse-only night sky would be acceptable if push comes to shove). Still wondering why it's still lagging behind with the Space layer enabled, this very setup got 58-60 on the same phone in both "sphere" configurations that have Space disabled, even when showing clouds (I love that they're so fast btw, great way of doing them).

    A minor note, I noticed (when I briefly had a crazy colorful texture for Space) that the Space layer always renders throughout the day. I guess once dawn is over this could be suppressed until dusk or until the moon starts fading in? But this is not high-priority (I could script this myself if you feel your package shouldn't behave like this out-of-box) and shouldn't distract from the general lag introduced by the seemingly highly simplistic Space layer. I studied the Space shader and it seems a lot simpler than the others, so it probably isn't the shader. Is anything done every Update() CPU-side for the Space layer by your scripts somewhere?
     
    Last edited: Aug 14, 2013
  39. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Oh boy, that's quite a wall of text you produced there. :) I'll try to cover all of your questions...

    This is not directly a bug, but more of an area I'm not quite sure what to do with at the current point in time. As the readme states the "Low" prefab does not apply the cloud sharpness parameter for this prefab as it would have to be applied per-pixel and this prefab should only be used on low-end hardware where fragment shader calculations should be avoided. The "Medium" prefab applies the parameter, but this costs 5-10 FPS as I stated above. The package comes with 3 textures that can be used to do this manually, but the weather system does not use them automatically at the moment because I'm still brainstorming how I can do this in a clean and fast manner.

    The UV coordinates for the cloud texture are being calculated using the vertex position. A certain amount of vertices are required to do this without causing such rendering artifacts you described. I'll look into this when I test how far I can reduce the vertex count for the "Low" prefab.

    The space layer is, as you found out in your next post, really just a texture that is being sampled.

    This sounds like your target hardware has a really slow implementation for the "MultiplyUV" function in the vertex shader, try commenting out just that line and report back. If said function is in fact the cause try replacing it with TRANSFORM_TEX:

    Code (csharp):
    1.  
    2. MultiplyUV(UNITY_MATRIX_TEXTURE0, float2(...));
    3. TRANSFORM_TEX(float2(...), _MainTex);
    4.  
    ...and report your results.

    As you said this is indeed intentional behaviour. That way the stars slowly fade in at sunset because the scattering adverse to the sun drops off. If I disable it I'd have to hard-code the point at which the stars should be completely invisible - which is impossible to predict for all the parameter variations. However, you can of course write a script to do this for your specific parameters - it should be really easy as the sky script is very robust and you can pretty much do whatever you like with the star renderer component.
     
  40. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    The only thing that has me wondering is this...

    I removed all texture stuff from the space.shader, see here --- it's now a standard position-only vertex shader with a standard diffuse-color-only (white for testing) frag shader.

    Again, if the space is disabled, this runs at a constant 59-61fps with everything else included, using the spheres. Tested multiple times, observed for minutes.

    But with space enabled, even with this dummy no-op shader, constantly doing 55fps, tested multiple times, observed for minutes.

    So I was wondering whether the space layer might incur some other overhead. But this isn't terribly pressing really at this point. ToD performs so well already.

    Still I'm going to reintroduce texture sampling and try your suggestion to get some gorgeous starry skies. Can't let this topic go ;)
     
  41. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Wondering whether "limb darkening" for the moon is feasible?

    Take a look at this: $fee20304-619b-4b0e-b967-539ce5a70644_scaled.jpg

    Taken from https://www.assetstore.unity3d.com/#/content/4160 --- well your moon already does its phases very well, and this is kinda pretty similar. Just a very tiny black fall-off / gradient to the fuller half of the moon.

    Background: for artistic reasons and mobile device resolution / screen size reasons, I have scaled my moon from the default 0.05 to 0.2. Now it has the right size artistically but it looks like a close-by sphere hanging nearby, instead of a far-away planet. I believe limb darkening as illustrated above could fix this. Seems like the "space graphics toolkit" does this in a vertex shader (lines 37-43, can remove that link as soon as you see it to avoid copyright issues) --- not sure how easy it would be to adapt to the moon. But it would make a huge difference! I'd even "invest" a couple more milliseconds in this (whereas the star field I have happily ditched for now).
     
  42. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    [Deleted after further experiments...]
     
    Last edited: Aug 14, 2013
  43. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Have you tried replacing the shader with a Unity built-in shader? Furthermore, try just disabling the renderer component and compare it to the results when you disable the complete game object.

    The problem is I literally do nothing whatsoever with the space sphere in my scripts. I don't even reference it to set shader parameters (because it really just renders a plain texture, all scattering and haze comes from the atmosphere renderer).

    I could imagine it being a cache / RAM effect on your hardware or the crossing of CPU-bound and GPU-bound (you reach a certain critical mass of vertices to render and your performance drops because suddenly your code is GPU-bound). To reproduce you could just drop in some default spheres into your scene (try with both enabled and disabled dynamic and static batching) and see if you can reproduce the effect.

    Simple answer: No, because due to various surface properties the real moon also has no limb darkening! :)

    I could however add an optional parameter to the shader to do this if one wants to see limb darkening even though it's not realistic (maybe some artistic reason).

    However, because you mention the vertex shader: Be aware that as soon as calculations are being done in a vertex shader there have to be enough vertices - so with your custom really low vertex count sphere this might look quite ugly. I'll see if vertex or fragment shader is the better option performance-wise (the moon is ususally quite small, so fragment shaders aren't as expensive as they usually are in that case).
     
    Last edited: Aug 15, 2013
  44. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Yeah you're probably right with the GPU-bound. I mean I reduced the shader to a diffuse-color only, so the vert only has the matrix-mul call and the frag returns (0,0,0,0) for pitch black and doesn't do anything else. So it can't get faster than that. And also I checked your scripts, there's simply zero "overhead" code for the space layer, so it must be the critical-mass thing. So that's all cool then.

    Also forget about the limb darkening please. :D My moon was too big so it looked odd. Tuning atmo/haze just a little bit helps more than enough here, moon looks great, no need for added shader complexities or more vertices for such an effect now anymore!

    Only two more tiny little things are of interest to me now :razz:

    1. earth shadow in atmosphere --- not as a hugely complex "physically accurate" simulation or anything, but simply as a gray-ish shading at the lowest end of the atmo-half-icosphere's overall gradient. At some point. Not terribly mission-critical. Only if feasible without too much trouble or losing sleep or heavy calculations. Plausable is more than good enough, accurate is overkill ^_^

    2. ultra-low-poly icosphere --- I tried two that I found for 80 and 180 triangles respectively: that would definitely be too low. Especially noticeable during sunrise/sunset and in the clouds. I'll keep the 180 one around just for the moon. But if we had an icosphere of around 300-600 tris that should be pretty cool. Sure probably still a "bit noticable" for the discerning graphics-aware users (but no one is targeting those in mobile gaming), but not as bad as 180 tris as far as real visible artifacts go. So that'd be much appreciated! It's not too urgent as far as I'm concerned, I won't be publishing for months to come. But ultimately it would be beneficial to this package. As I said, this would "buy" me easily a couple of trees, bushes, another enemy and some birds in the sky, at the very little cost of a hardly noticable (compared to 80/180 tri) reduction in the physical plausibility of the sky...

    If and when you find the time and peace to do this, do reduce your Game View in Unity to real phone or small-tablet size (not much bigger than your hand) so you're not too shocked by the "quality" of those ultra-low-poly meshes as you would certainly be on the big screen ;) ;)

    The simplest thing would be another copy of your current low-poly meshes for ico and half-ico, with tri count halved in both cases. If this is doable, I'll never ask or talk about any more meshes ever again, promised :D


    Btw. I noticed that Time of Day sets the fog color. That's great stuff! Sometimes I wonder if it could be slightly closer to the atmo color of the lower horizon (see https://dl.dropboxusercontent.com/u/136375/img/screens/tod-fog-day.png or https://dl.dropboxusercontent.com/u/136375/img/screens/tod-fog-nite.png) but nonetheless, even so your code already sets it much better dynamically than I could manually, so hey I'm not complaing :D
     
    Last edited: Aug 15, 2013
  45. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    I'll look at the physical properties of this effect at some point in the future - it's on the roadmap to at least evaluate the possibilities.

    As I said before, this is definitely going to be part of the next update - optimize the lowest quality prefab even further, maybe deal with the cloud conditions on that setting in the process.

    Also added to the roadmap. Setting the color of the fog didn't change since 1.0 while the sun calculations did get updated quite heavily, that's where this discrepancy comes from. Should also be part of the next update.
     
  46. Rastar

    Rastar

    Joined:
    Sep 14, 2012
    Posts:
    68
    Hi,

    just bought your fantastic asset, looking awesome! One question: I use and love the Skyshop from Marmoset for Image-based Lighting. There you start with a (HDR) skybox and the tool creates very realistic lighting and reflection in your scene. Would it be possible to use that with the TimeOfDay? The idea would be to export the calculated skydome to an HDR image and then import that into Skyshop. Of course, the pre-calculated lighting wouldn't respond to the dynamic TimeOfDay skydome, but I think in most cases that would hardly be noticeable.

    By the way: It seems both Skyshop and TimeOfDay have a global "Sky" definition which clash when imported into the same project.

    Thanks, keep up your great job!
     
  47. EmeralLotus

    EmeralLotus

    Joined:
    Aug 10, 2012
    Posts:
    1,337
    Can this asset work in-game, changing various skybox configurations during runtime ?
     
  48. msgamedev

    msgamedev

    Joined:
    Dec 24, 2011
    Posts:
    427
    A question:

    does this Asset work with lightmaps, e.g. for terrain?.

    If using lightmaps there is usually a directional light in the scene, then the lightmap is baked. Then the shadows around a specified radius around the main camera are rendered in real time (e.g. for the character) and all shadows beyond this distance are lightmapped.

    Does Time of day support this?

    Can i bake a lightmap with a directional light, then turn it off, and the sun replaces it ? (is it a moving directional light?) So that the lightmap still works?


    Does the sun cast shadows at all? or do i have to still use a directional light in the scene?

    Thanks
     
  49. shwa

    shwa

    Joined:
    Apr 9, 2012
    Posts:
    447
    Hi,

    1. What additional filesize overhead does this add to a webplayer experience?

    The web demo loads very quickly, and has a few additional assets that likely wouldn't be added to an existing scene one has.

    2. Are rain and snow part of this package?

    tx,

    shwa
     
  50. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    681
    Of course you can! If you want to do this right in the editor (ahead-of-time) you can use the script "SkyboxGeneratorEditor" that is in the "Demo" folder of Time of Day. Attach it to your camera, click "Render Skybox" and you will find 6 textures in your assets folder that can for example be used as a static skybox or for lighting calculations (create a cubemap and assign the 6 textures if the shader requires one, otherwise just assign the 6 textures directly). You should probably make at least two of those (one for day and one for night) and switch them out at runtime.

    Yes, all parameters can be changed at runtime.

    This doesn't really have anything with Time of Day specifically. You can of course bake lightmaps, however, lightmaps are only correct for one sun position - so as soon as the sun moves the shadows on your lightmaps will look wrong (as you baked them using a different sun position). This is just the way lightmaps work: lightmaps are supposed to capture static lighting, so as long as the light source stays at the same position they will look correct. As soon as it moves they won't.

    The sun and moon both have directional lights attached to them (only one of them is active at any given time). Realtime shadows of course work with these directional lights, so you don't have to add any directional lights on your own.

    The filesize overhead is in fact quite low as most things are being calculated on the fly in the shaders. The .unity3d file of a web player with just the sky dome and 4 default cubes in it is 237KB in size.

    The package does not contain any particle effects at the moment.
     
unityunity