Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Time of Day - Dynamic Sky Dome

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

  1. Evil_Echo

    Evil_Echo

    Joined:
    Sep 30, 2011
    Posts:
    48
    André and myself ( Gregg ) have been looking at various aspects of his Time of Day system that could be used for my Zulu combat simulation library. One such feature is multiplayer support. In order for sun, moon, clouds to look right - the timing has to be synchronized across machines so that players see the same thing at same time. ToD will support such network synchronization.

    We've talked about a number of other cool ideas as well. Great to work with him, a fellow fan of hyper-reality.
     
  2. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    About the network synchronization: At first I thought I could just synchronize a single float (the time stamp) and just calculate the cloud position on every client to guarantee similar results, but this of course will not handle the case that the wind strength is 5 knots for 10 minutes and increases to 10 knots after that. So the way it works now is that a new animation component exposes a Vector4 representing the current cloud position (UV coordinate offset) that can be synchronized. It also exposes the new wind strength and wind direction parameters which of course should also be synchronized if you change them.

    Overall: It's now possible and quite easy to guarantee equal sky conditions across multiple clients, but it's still your job to actually broadcast the values. This can easily be done with a number of Unity features and methods or third party networking libraries.
     
    Last edited: Sep 3, 2013
  3. Evil_Echo

    Evil_Echo

    Joined:
    Sep 30, 2011
    Posts:
    48
    Thank you, looking forward to trying this out.
     
  4. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    I am getting the weirdest issue with the new update... maybe or maybe not related...

    I generate my tree placement procedurally, and set the trees to non standard heights i.e. not 1.0, and since the new update I am now getting these crazy artefacts :

    $2013-09-06_1819_trees.png

    If i paint the trees using the tree placement tool in unity the trees are the size of the outlines you can see above.

    Anyone else getting this ?
     
  5. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    As you guys might have noticed 1.7 is out! I'm ready to receive bug reports... oh I see you're already at it! :)

    It doesn't look like that's caused by the 1.7 update, but let's see. Is the color you're seeing there the camera clear color (the gray looks like the clear color of the editor camera)? If so it could be that something is writing to the depth buffer at those areas without rendering anything. The terrain demo scene uses the builtin terrain and the trees have been placed using the normal tree brushes, as I understand you're also doing it that way? Does the terrain demo work? How do you generate the trees procedurally, are they being scaled in a shader or are they being created using some default Unity functionality? Did you reimport the package correctly? (I recommend deleting the old folder and do a fresh import)
     
  6. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    This is the code i am using to place the trees :

    TreeInstance temp = new TreeInstance();
    temp.position = new Vector3(normX,height,normZ);
    temp.prototypeIndex = idx;
    temp.widthScale = t.width * strength;
    temp.heightScale = t.height * strength;
    temp.color = t.colour;
    temp.lightmapColor = t.lightmapColour;
    terrain.AddTreeInstance(temp);

    Fairly standard stuff i think... i will create a clean project and see if i can reproduce, as the project I am experiencing it is in a test project, and it may be from some of the other assets i have been experimenting with.
     
  7. vrpostcard

    vrpostcard

    Joined:
    Feb 24, 2013
    Posts:
    33
    Can anybody help me please? First of all, what a great asset, it's certainly bringing a great level of realism to my simulations. I am not a coder by any stretch of the imagination and rely on playmaker to do my coding for me. I am unable to set the time of day, date, latitude, longitude and UTC using this method although I can set the cloud and weather types. My current simulation requires the ability to set a real world location and animate the sun over a period of a day. Is there something that I am missing?

    Many thanks in advance.
     
  8. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Looks rather normal, yes. I cannot reproduce the bug with my trees however, so I would guess it is in fact another part of your project. As I said, it looks like there's something writing to the depth buffer where it shouldn't.

    I don't have any experience with PlayMaker, but in your custom scripts you should set Cycle.TimeOfDay to adjust the time. For a day/night cycle you can also simply enable the script "TOD_Time" that is attached to the sky dome. It progresses the time (and if enabled date and moon phase) automatically.
     
  9. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508

    I have seen this...I am trying to recall the exact circumstances. I believe it has to do with scaling your tree (width and height scales), the shader you use, and whether or not you are using built in trees (Unity Trees) or importing them.

    Something alone the lines of...importing custom tree meshes and trying to use the built in shaders does this. Are the trunks and leaves separate meshes, and if so, can you try using the diffuse shader for the trunks and the transparent\cutout\diffuse shader for the leaves?
     
  10. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    I am using Unity trees from Jacal's Big Environment Pack... (awesome pack!) but only just had this issue after i upgraded to 1,7. I also imported a package called Sunshine and then removed it as it seemed to create a weird haze. Tomorrow I will rebuild the project from scratch and see if i can replicate.

    Am not doing anything with shaders etc.
     
  11. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Thanks jc_lvngstn for checking in and providing some details on the issue.

    I received a few minor bug reports so far, all of which have already been fixed on my local dev branch. I will wait a few more days in case some important bug comes up, if it doesn't I will submit the fix this week. I also tweaked some parameters of the default prefabs as I haven't been completely satisfied yet, so if you have suggestions regarding those please feel free to post them.

    All in all 1.7 looks like a solid release, apparently the testing paid off - especially if you consider the extent of the 1.7 update. I also like the "major release + hotfix one week afterwards" release schedule a lot, if you have any thoughts on that please do post them.

    Regarding the future: I still have some suggestions for Time of Day in the pipeline, but overall it seems to progress towards a nicely polished state. The 3D cloud package is also still on schedule and will be completed as soon as I find the time to do so, which will hopefully still be this year.
     
  12. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    OK - worked it out - to a degree anyway - turning off the shadow projector in the clouds settings stops the issue. Hopefully that gives you somewhere to look.
     
  13. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    The cloud projector uses almost exclusively built-in Unity features, with the exception of the shader which merely calculate texture UV coordinates and shouldn't even be rendered in areas where there are no visible meshes. However, it might be related to the tree shaders if they don't have the correct tags to ignore projectors. Do you use the built-in tree shaders or those from the package you mentioned? The built-in leaves and bark shaders have "IgnoreProjector"="True" in their tags, if the package's shaders don't it might be the cause of the issue.
     
  14. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Just submitted 1.7.1 with a few fixes for the things you guys reported so far, let's hope it will still go online this week.
     
  15. Setmaster

    Setmaster

    Joined:
    Sep 2, 2013
    Posts:
    239
    What are the big differences between this and UniStorm?
     
  16. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    I don't want to start a discussion about which package is better or worse, but if you look at the UniStorm thread, description and screenshots there are a few areas that are quite different. To help you with the comparison I'd like to enumerate some points I'm focusing on in the development of Time of Day.
    • Sky: Simulate the atmospheric scattering as it is in real life, possible to achieve very realistic sunrises and sunsets that way
    • Clouds: One draw call and two texture samples, calculate shading based on a modified form of normal mapping, correctly projected cloud shadows are supported since 1.7
    • Performance: Highly optimized, runs great on mobile, even on the iPhone 4 and iPad 1
    • Weather: Dynamic weather type manager (sky, clouds, wind direction, wind speed), no particle effects for rain and snow out of the box as I'm focusing on the actual sky dome, I want to do one thing right instead of adding dozens of features that might not be thoroughly thought through
    • Location: Full longitude / latitude and time zone support
    • Customization: Highly customizable yet clearly arranged and understandable
    • Code: Well structured and focused, it's probably the cleanest code you've seen in quite a while as I'm extremely anal regarding code quality
    I hope that helps in making your decision. Other than that I would suggest you read through the customer reviews and user comments in the two forum threads to get an idea about customer support and quality of the two packages (maybe compare the amount of bugs / issues users are reporting and the update frequency).
     
  17. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    @Setmaster

    I love this package! Its the first thing that I put into any new projects, and as promised it works well on mobile as well. Can't wait to see the clouds package when it comes though as well. Am sure i will be a buyer!

    I also want to add weather to my game - and you don't currently support that - can anyone suggest a good package show how they have integrated it?
     
  18. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Version 1.7.1 with the promised fixes is online, make sure to update. I also updated the screenshots and of course the web player demos to better represent the current state of the package.
     
  19. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    By weather, do you mean rain/snow/dust-storm/etc?

    If so, that's just called a "particle system" and is incredibly easy to use and tweak right inside Unity without any coding skills. Make one for snow, one for rain etc. then activate/deactivate them depending on your needs...

    I mean there's no better way to implement rain/snow/etc than with a particle system. And the Shuriken particle system inside Unity is so easy to use, it's not even funny.

    Sure if you wanna save a few hours time of playful and entertaining experimentation with Shuriken, then you can grab a rain or snow package from Asset Store, there are quite a few and they're usually cheap or free. Because they're ultimately just pre-tweaked Shuriken setups from what I can tell...
     
  20. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    I'm pleased to announce that 1.7.2 is on its way with some adjustments related to the automatic ambient light calculation and some general minor tweaks here and there. I also updated the documentation to include all classes, variables and properties - each with a short explanation.

    A big thanks to all of you and especially Gregg aka Evil_Echo for providing valuable feedback on all sorts of things. I hope 1.7.2 will fix the last inconsistencies and annoyances of the 1.7.x cycle and I'm therefore ready to take requests for the 1.8 update. So far I got requests for earth shadowing and an API to access and modify orbital parameters of the planet.
     
  21. mcmorry

    mcmorry

    Joined:
    Dec 2, 2012
    Posts:
    580
    I found some problems:

    On the projector shader I had to add Offset -1, -10 to the Pass, to avoid a bad z fighting issue.

    The Brightness parameter of the moon shaders in some way cut the colours and I had to set it to 1:
    $Screen Shot 2013-09-18 at 1.02.16 AM.png $Screen Shot 2013-09-18 at 1.02.54 AM.png
    So I had to make the moon's texture much brighter. I reduced it ( 128x128 ) too and squared for compression.

    I don't know why but the stars are still too little on the horizon. If I look on top of the dome it very nice, but near the horizon is almost impossible to see them (I tried with the night haziness to 0 too, and material tiling to 1)

    For the version 1.8 could be very nice to have aurora borealis effect ;)

    Thanks
     
  22. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    This most likely greatly depends on the scene and platform (depth buffer resolution), so finding the perfect values out of the box is rather impossible. This is something that will have to be dealt with on a per-customer basis - if someone has an issue I'm more than hjappy to provide support.

    This appears to be an issue that only appears when compiling the shader for mobile devices. The moon also appears to be a lot darker on mobile. It could also have something to do with linear / gamma space. I'll look into it, thanks for reporting this.

    Unity actually automatically makes textures a power of two for PVRTC compression. As the texture is set to "Automatic Compressed" you shouldn't have to worry about this - but you can of course reduce the texture resolution if you feel like it.

    I feel like this is the correct realistic behaviour - it's very hard to see stars at low angles due to air pollution and atmospheric turbulence. However, I'll reevaluate the current behaviour.

    Thanks for the suggestion, I planned to analyze what I can do to increase the visual quality at night anyhow and will see if something like this would be feasible to implement.
     
    Last edited: Sep 18, 2013
  23. mcmorry

    mcmorry

    Joined:
    Dec 2, 2012
    Posts:
    580
    Yes of course depends on scene and platform. The question is: does "Offset -1 -10" create any issue in some scene? Or could be set by default? Just to avoid to edit shaders after every (great) update. My current settings is for a mobile (android actually) platform. For the scene I'm using a far plane at 10.000, but I tried at 100 only and shadows still flicker.

    Good to know, so I don't have to fix it anymore for iOS :)

    You are right, but at very high latitudes the air is very dry, without pollution (until now). Could be useful to have a parameter to tune it as needed.
    Look at this 360 degree photo: http://1.bp.blogspot.com/_VgbOrdteh5w/TLlpGbvQ6iI/AAAAAAAAD0k/ZQyVdL-SiBw/s1600/vlt-mw-potw.jpg
    Would be super to reach this type of night quality :)

    Thanks again for you great work! ;)
     
  24. mcmorry

    mcmorry

    Joined:
    Dec 2, 2012
    Posts:
    580
    Ops! I've just seen that this settings create problems in the editor. When I select an object the wireframe highlight is not visible. But with Offset -1 -1 it works fine.
     
  25. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Awww.... yisssss "puleaze" give us earth-shadow-in-atmosphere.... :D

    I'm itching to try out the most recent version shortly --- been busy with various other aspects of my project so haven't found the time to upgrade yet, but will soon. Can't wait to see the glory of the current version! :)
     
  26. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    1.7.2 is out!

    Offset can in theory alway cause the issue that transparent meshes can be overlayed in some way or another. I'll see if -1 -1 is in fact flawless for most cases, if it is I will add it as a default.

    As I said, I'll look into ways to enhance the night sky - I feel like that's the least enhanced element of the package so far. I would love to render the stars in a realistic manner with the exact stars that can be seen in real life, but I don't know how to implement this efficiently. There's definitely some reading I'll have to do on this, but I put it on the list for 1.8 - it might be a while though as I have to finish up my bachelor's thesis over the course of the next few weeks.

    I'll look into the earth shadow that's being cast onto the atmosphere in 1.8 as promised.

    I hope you'll like it!

    By the way I scheduled another release (1.7.3) for next week to include fixes for the varying moon brightness depending on the platform and linear / gamma color space. If you find any further minor issues in 1.7.2 please let me know - ideally before next week as I'd like to submit 1.7.3 between next Monday and Wednesday.
     
  27. mcmorry

    mcmorry

    Joined:
    Dec 2, 2012
    Posts:
    580
    I didn't test 1.7.2 yet, but I added a new parameter to the WorldParameters class for the fog color:
    Code (csharp):
    1.  
    2. public Color fogFactor = Color.gray;
    3.  
    and in the FogColor method I changed these lines:
    Code (csharp):
    1.  
    2. float L1_r = _SunColor.r * Day.Brightness * (0.5f + World.fogFactor.r) * numerator.x / denominator.x;
    3. float L1_g = _SunColor.g * Day.Brightness * (0.5f + World.fogFactor.g) * numerator.y / denominator.y;
    4. float L1_b = _SunColor.b * Day.Brightness * (0.5f + World.fogFactor.b) * numerator.z / denominator.z;
    5.  
    In this way I was able to tune color and brightness of the fog to mach better the color below the horizon. In fact my problem was that I don't have a very big land in front of the camera (only 2000 meters). And when I go up with the camera (let say 200 meters) I can easly see the end of the land. The fog color doesn't mach. With a color of (18, 52, 210) now it match much more.

    I don't think that this is the best solution, but if you find a better way, it could help.

    Thanks
     
  28. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    It does look like the fog calculation at day is off compared to the sky color at the horizon again. I'll add this to the list of things to tweak in 1.7.3, thanks for the report.
     
  29. Rastar

    Rastar

    Joined:
    Sep 14, 2012
    Posts:
    73
    Hi,

    I had a quick look at your TOD_Sky script and I think I found a little (meaningless) error. You're using the Julian day (1 to 365) to compute the obliquity of the ecliptic in

    ecl = 23.4393 - 3.563E-7 * d

    but according to the web page you quote http://www.stjarnhimlen.se/comp/ppcomp.html#3 the time scale is the day number counted from Jan 1st 2000 onwards. Not really making a big difference due to the 10[SUP]-7[/SUP], though.
     
  30. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Good spot! However, I'm doing this intentionally as the calculations vary so little from year to year that I decided not to offer a year parameter as it wouldn't change enough for users to understand why they should even adjust it. That being said, if there are in fact people out there that really want a year to be added I'll gladly do so.

    Regarding 1.7.3 - I plan to submit it tomorrow, so please report any issues you may find within in the next 24 hours if you'd like them to be addressed in this release. So far it contains fixes for the fog color calculation, moon brightness and star visibility at the horizon. It also features two new parameters called "StarDensity" and "StarTiling" to adjust the number of stars and the size of the stars directly in the prefab, leading to a greatly improved look of the night sky.
     
  31. daisySa

    daisySa

    Joined:
    Dec 29, 2011
    Posts:
    341
    Just a suggestion - can you include some sample scenes that generate an orange or pink sunset at night?

    I bought ToD early on when it generated these kinds of sunsets by default, and I love all the enhancements that have been applied since then - it's definitely a much better product now - but I'm finding it difficult to replicate these dramatic sunsets.
     
  32. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    +1 to that - i loved the older sunsets
     
  33. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Have you tried the Tropical prefab? It produces sunsets quite close to the old ones, but I can of course add another set of prefabs with even more intense and colorful ones.
     
  34. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    Just tried - Nice :)
     
  35. daisySa

    daisySa

    Joined:
    Dec 29, 2011
    Posts:
    341
    Yes, that's much better - thanks.
     
  36. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Good to hear you guys like the Tropical prefab.

    In other news, 1.7.3 is now available for download.
     
  37. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,408
    sweet thanks! :)
     
  38. Goofy420

    Goofy420

    Joined:
    Apr 27, 2013
    Posts:
    248
    Would be more useful if everything wasn't hard coded, even the color setting resets on play
     
    Last edited: Sep 28, 2013
  39. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    I think you're either using the package incorrectly or I misunderstand what you're trying to say. Almost everything in Time of Day is configurable and, with the exception of some nature constants, barely anything is hardcoded.

    I could imagine you're trying to adjust things like the sunlight color directly in the light component of the sun child object. If that's the case, make sure to adjust everything in the sky script that's attached to the parent object of the prefabs instead. This script manages the properties of the child objects and its parameters are organized in several categories to adjust almost every aspect of the sky dome. All adjustments will be applied directly in the editor, even if you don't hit play.

    Also please make sure to have a look at the readme file if you haven't done so. Things like how to configure the prefab correctly are written down in there with explanations of all the properties that can be adjusted.
     
  40. Evil_Echo

    Evil_Echo

    Joined:
    Sep 30, 2011
    Posts:
    48
    Absolutely not! The combinations possible would be huge, too much to code properly. Even more so if, as hoped, support for other planets comes to fruition.
     
  41. WarHead

    WarHead

    Joined:
    Nov 15, 2012
    Posts:
    28
    I know this has been mentioned before, but what are the chances for some weather ie rain :)
     
  42. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Newsflash, Unity has a rain/snow/sand-dust/etc. system called "Shuriken". Some oldfashioned people like to call it a "particle system" but let's face it, it's essentially a weather machine :D ;)
     
  43. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Still essentially the same reply: At some point in the future, when the sky dome is completely finished and regarded as perfect by most people, this is on the table again. Whether it will be a separate addon or directly included in Time of Day will depend on its complexity. My top priority is still to keep the code base of Time of Day organized and focused, so either way the particle effects should be an optional thing. I also don't want to add them in a way I'm not completely satisfied with (rain should for example be able to properly handle shelter and houses) so there's definitely still some thinking left to do.

    As a lot of people said before, if you're just looking for a simple rain particle effect using the Shuriken particle system you should be able to make it on your own within a few minutes or hours.
     
  44. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Been a while, had a chance to implement the latest release now finally!

    First off, I can't have a pitch-black night sky ever (artistically) ---that's simply not workable on glary phone/tablet glass displays on bright days--- so I pick a very gorgeous dark-turquoise tone for "Night/Additive Color". Lovely! Works great with the stars now, too. But the moon always has a "black half" still, whenever it's not full-moon. What to do? A shader refinement with a new addded "backcolor" input for it would be highly advisable, I believe. Right now the shader fades from moon-tex to black depending on phase, cool! Now instead of fade to black, let's have it fade to anycolor... thoughts?

    Quad-sunlight: basically looks great, but again I think we need a color input. It's always white like a clear northern winter sun, this may be physically correct (though I'm using tropical) but isn't really always artistically desirable: first of all I understand you want ToD to be "fantasy-planet capable", but even in earth setups I'd go for a pretty yellow shade even for mid-day sun, like GTAV does: http://s11.postimg.org/wribdy7fn/gameplay.png

    Now sure, I can set the light color itself to something extreme like green or blue or magenta and it picks it up but highly "lightened up", so setting it to a nice yellow like this screenshot isn't possible, it turns fully white. Ideas? Plus I just wanna "color the sun" artistically really, but I don't want all scene lighting to be happening in a "traffic-light yellow". I'm sure this is achievable with the plethora of tweakable toggles we now have, so I'd love to learn how :D

    Last point is this: using tropical prefab, about 1 "hour" before sunrise until about 3 hours after, and about 2 hours before sunset until about 1 hour after, most of the horizon near the sun-pos turns into one huge bright white area like an atomic explosion or something. As I live in the tropics myself (except for summers..) this is pretty overblown in the current ToD. The phenomenon of a brightened sky like this exists -- even now at 4PM it's somewhat brighter out west where in 2 hours the sun will set--- but by far not as blown-out / massive. What would I need to tweak to tune this down to "calmer" levels?

    (NB I'm sure it's all according to formulas from papers and I'm not doubting them, but ultimately in "gamedev, rather than physical-sim dev", once we get to mathematically-speaking proper stable plausible models, that's only when we can (and must) begin tweaking away to maximize/emphasize visuals that fit the overall project..)
     
  45. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    I'm thinking fading to the additive night color instead of black should work? I can easily implement this.

    I see your point. The reason for this is mainly the additive blending of the sun, leading to dominantly white colors. I'll investigate and report back as soon as I find the time.

    Generally speaking, this is caused by Mie Scattering and can be adjusted by lowering the parameter "Mie Multiplier" in the "Day" category - you could give 0.05 and 0.025 a try. HDR rendering combined with tone mapping can also handle this by dealing with the immense intensities directly at the sun.
     
  46. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    That would be sufficient much appreciated, thanks in advance ;)

    Thanks for looking into this :)

    Cool, thanks for that info, gonna play with that.

    Sadly, I'm LDR at the moment.. Once Android 4.3 (GL ES 3.x) hits my ONE and Unity 4.3 gets rolled out, I'll give Linear+HDR+Tonemap another try on mobile..

    Totally loving the new cloud shadow projector by the way! Great effect. Sadly not usable on mobile as it adds some 40-50 drawcalls (generally an issue with projectors from what I hear) but who knows, 1 or 2 years down the line... should be awesome!
     
  47. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Projectors require all geometry to be drawn a second time, so as you correctly stated cloud shadows shouldn't be used on most mobile devices for now. That's also why I disabled them for the "Low" and "Medium" prefabs by default.

    By the way, I spent some time experimenting with the sun while waiting for a few PVRTC texture compressions to finish.

    $Untitled.png

    It's not quite where I want it to be yet, but I'd say it's a good start. The hard thing is implementing all of it in a single draw call of a simple quad as the built-in lens flares are pretty much unusable.
     
  48. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    This looks stunning! Very cool... but would be nice if you put two variations of this in the next version: one with those lensflary spikey "sonnenstrahlen / rays" and one without (but still sharing the nice soft fade-out all around the disc). Because, while you're right that the out-of-box flares are a bit ugly, some folks do use custom or 3rd-party flares nonetheless, and then the sun disc shouldn't exhibit "flare" behavior or the "rays" might overlap or otherwise interfere...

    By the way, while the out-of-box built-in 3-or-4 standard lens flares are ugly, Unity still offers another 10-or-so, prettier and more professional lens flares on Asset Store for free. They're quite cool! Especially the "85mm lens" and the "sun from space". Gonna use one of those for sure, probably the 85mm since the space one adds a huge white blob over the light source, hiding our actual sun quad. And if I wanna get to a "GTAV"-class or nicer sun, I shouldn't have my flares hide the sun quad..
     
  49. andererandre

    andererandre

    Joined:
    Dec 17, 2010
    Posts:
    683
    Well, I dislike the way sun flares fade out at the corners of the screen, especially the way Unity implemented it (time-based rather than distance-based). You can of course always use the default particle texture for the sun plane:

    $Untitled.png
     
  50. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Yeah I'll probably go with this one in my case -- still going to need to "colorize" it ideally via shader, though! For example, I'd set it light-orange during the day, dark-orange during dawn/dusk...

    Two more questions ;)

    - one thing I notice for the day-light is a colorize option. Even if sunlight is (255,255,255) it colorizes the lighting yellow-ish if colorize is not 0. I realize this is going to be useful at dusk/dawn but then it always goes for yellow, it seems? Might want to go for more orangey myself, so what exactly is this and why is it calculated the way it is currently?

    - more importantly, what would you recommend regarding high-altitude camera positions:

    1. If the SkyDome is always centered around the camera for x and z and also y, this is great at ground level but if we only go "100 metres up" with a scale-1000 skydome the horizon is noticably no longer at the horizon, but quite a bit above. This also results in the rising/setting moon and sun popping in and out "above the horizon".

    2. If the SkyDome is only centered around the camera for x and z (but remains at y=0), then at a cam altitude of say 100 or 200 units, the skydome is partially outside the far-plane. Now I could extend the far-plane but that kinda defeats the purpose of a far-plane. I don't really want to render stuff that's 1200 units away at higher altitdudes if I cull it at 1000 on ground level, you know?

    What's your thoughts on those? ;)