Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Lighting Modes in 5.6 Beta 2

Discussion in '5.6 Beta' started by smcclelland, Dec 21, 2016.

  1. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    Hi all,

    We’ve been working hard on addressing issues around mixed lighting and have made the latest iteration of these improvements available in Unity 5.6 Beta 2. The team is looking forward to hearing your feedback on lighting modes so please direct all feedback here in this thread so we can iterate on this together.

    The work in progress documentation for this feature can be found here: https://docs.google.com/document/d/116JvLXljfbdfllOLlyzVvWmNWpbUwcYKV16blVHuS2E/

    Overview

    The goal we are striving for is to provide a much more robust, intuitive way for Unity users to light their scenes using a mix of baked lightmaps and realtime lighting/shadows. This is being done with the following features in 5.6 Beta 2:
    1. The old Realtime, Mixed, Baked modes on lights in Unity have been changed to be Dynamic, Stationary, and Static. See the Lights section below for more details.

    2. We have introduced a new set of Stationary Lighting Modes that offer a set of well-defined lighting solutions targeting different use cases and hardware. See the Stationary Lighting Modes section below for more details.

    3. The Lighting panel itself has undergone a major overhaul and refresh as well as the Mesh Renderer and Light Component Inspector panes. See the User Interface section below for more details.

    4. We have introduced a new editor panel called the Light Explorer which gives users quick access to Lights, Reflection Probes, Light Probes, and Emissive materials. See the Light Explorer section below for more details.

    Lights


    Lights can now be set to the following Modes:
    Dynamic lights cast dynamic light and shadows. They can change position, orientation, color, brightness, and many other properties at run time. These are the most flexible type of lights and can be used for Realtime Global Illumination. Dynamic lights compute direct lighting at run time. They also use realtime shadows via shadow maps. Enabling Realtime Global Illumination in the Lighting panel will cause Dynamic lights to contribute realtime indirect lighting to the scene. Indirect light is from realtime lightmaps and Light Probes updated by Enlighten.

    Stationary lights allow a mix of dynamic and baked lighting based on the Stationary Lighting Mode set in the Lighting panel. All Stationary Lighting Modes except for Subtractive compute direct lighting at run time and store indirect lighting in lightmaps and Light Probes. Subtractive mode will compute direct lighting at bake time but only for Static objects. Stationary lights are affected by the Stationary Lighting Mode that is set for the scene. See the next section on Stationary Lighting Modes for more information.

    Static lights cannot move or change in any way during run time. All lighting for static objects is baked into lightmaps. Lighting and shadows for dynamic objects gets baked into Light Probes.

    Stationary Lighting Modes


    Stationary lights can be controlled by scene wide Lighting Modes which instruct the lighting system on how direct lighting, indirect lighting, and shadows get handled by the various lights in your scene. The available modes for Stationary lights are:

    • Baked Indirect
      Stationary lights contribute realtime direct light and use lightmaps and Light Probes for indirect light. Realtime shadows are used up to the Shadow Distance quality setting.

    • Distance Shadowmask
      Stationary lights contribute realtime direct light and use lightmaps and Light Probes for indirect light. Realtime shadows are used up to the Shadow Distance quality setting. Beyond this, Static objects use shadowmasks and Dynamic Objects receive shadows via occlusion from Light Probes.

    • Shadowmask
      Stationary lights contribute realtime direct light and use lightmaps and Light Probes for indirect light. Static objects cast shadows on themselves using shadowmasks. Dynamic objects cast shadows in the scene using realtime shadow maps up to the Shadow Distance quality setting. Dynamic objects receive shadows from statics objects from Light Probes occlusion.

    • Subtractive
      Stationary lights contribute indirect light through lightmaps and Light Probes. Direct light is handled with lightmaps for static objects and dynamic objects are direct lit in realtime. Static objects receive shadows from dynamic objects using approximate realtime shadow maps from the main directional light up to the Shadow Distance quality setting. Dynamic objects receive shadows from themselves using realtime shadows up to the Shadow Distance quality setting. Dynamic objects receive shadows from static objects from Light Probes.
    These overview descriptions are presented as information tips in the Lighting panel now to help you get a better idea of the Lighting Modes within the editor context.

    User Interface

    We have made a lot of changes to the Lighting panel as well as the Inspector for Mesh Renderer and Light components that is outlined below.

    Lighting Panel

    The Lighting Panel has undergone a complete overhaul to improve the usability and provide a more intuitive approach to lighting going forward. The following changes have been made:
    • The panel has been organized in a way where sections can be collapsed when not needed and all relevant properties for a given section exist within the collapsible frame.

    • Labels and their tooltips have been re-done to be more user-friendly and informative.

    • A new Statistics panel has been integrated into the bottom of the Lighting panel which gives you a quick overview of lighting related statistics in the scene.
    • Lightmaps tab has been renamed to “Global Maps” and now includes maps such as Intensity, Directionality, Shadowmask, etc.
    • The “Object” tab has been refactored and renamed “Object Maps”. This tab shows the currently selected objects baked texture previews. You can pan and zoom around in this view as well as use the ‘f’ hotkey to frame on a selected objects lightmap UVs in the tab. Properties previously found in the “Object” tab have been relocated to their appropriate component Inspector. The following views are available:
      • Charting
      • Albedo
      • Emissive
      • Realtime Intensity
      • Realtime Direction
      • Baked Intensity
      • Baked Direction
      • Baked Shadowmask

    Inspector

    As part of the Lighting panel overhaul the Objects tab in the Lighting panel was refactored and all lighting related properties were distributed back to the respective components.



    Mesh Renderer components now have a foldout section labeled Lighting and all properties that affect how the mesh will interact with the lighting system are stored in there. Enabling the Lightmap Static property will mark the object as Static (same flag in the Static dropdown list) to be used in lightmap calculation. This also exposes the various other properties related to lightmapping.


    Light components have also been refactored to include the new light modes (Dynamic, Stationary, Static) and have had a pass to make the labels more user-friendly. We’ve also done a pass over all of the tooltips to make them more informative to users on what a specific property does.

    Light Explorer



    The Light Explorer is a new interface in Unity 5.6 Beta 2 that allows you to view and edit every light in the scene. This is very useful for large, complex scenes where you may have lights scattered across your hierarchy that you want to tweak. There are four tables in the Explorer that allow you to tweak Lights, Reflection Probes, Light Probes, and Emissive Materials. Each table is searchable to help find specific objects you want to work with and you can also Lock Selection which will maintain the items currently selected in the view even if your scene selection changes. The tables also support multi-editing by selecting multiple items and editing a value which will set the value across all selections in the table.
     
    Last edited: Dec 21, 2016
  2. seon

    seon

    Joined:
    Jan 10, 2007
    Posts:
    1,441
    Wow, those are huge changes. Lots of new UI and lighting model stuff to learn and understand.
    Thanks for the continued efforts to make mixed lighting better.
     
  3. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    This is HUGE... and welcome... One thing I want to know and how things like baking Lightmaps to prefabs will be handled. I have a lot of geometry that are prefabs and it is important that we somehow get this working...
     
  4. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    KRGraphics - could you describe some of the issues you're seeing with prefabs or toss me a link to investigate?
     
    Last edited: Dec 22, 2016
  5. StaffanEk

    StaffanEk

    Joined:
    Jul 13, 2012
    Posts:
    380
    Is it possible to move stationary lights? For instance, having a stationary moon move in the sky even though its shadow map doesn't move.

    EDIT: Just read the doc. You can.
     
  6. kslarson1

    kslarson1

    Joined:
    Jul 25, 2016
    Posts:
    1
    I'm excited to apply this update - looks like it'll be much more flexible. Going to start playing around with it, and would love a video tutorial to help everyone get started faster.
     
  7. S_Darkwell

    S_Darkwell

    Joined:
    Oct 20, 2013
    Posts:
    320
    Is realtime indirect bounce light/shadowing going to be a part of this project, or is there a timeline for this? I remember during the Unity v5.0 rollout, the inspector stated that it wasn't "yet" implemented, but I haven't heard of anything upcoming.

    Thank you in advance!
    - S.
     
  8. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    Fantastic job on this, guys. Subtractive mode is pretty awesome in particular!
    EDIT: Actually, one question. How come 'lightmappingMode' is now deprecated, but 'lightmapBakeType' generates an error when I go to make a build (as if it's an editor-only API)? I've got a custom lighting system inspired by Valve's Lab renderer and it relies on checking the bake type of a light. What am I supposed to use for this scenario?
     
    Last edited: Dec 23, 2016
  9. salex1

    salex1

    Joined:
    Jul 9, 2015
    Posts:
    29
    This looks very promising and yes video tutorial would be nice..
     
  10. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    Hi all,

    Just wanted to follow-up and see how everyone's experience is with the new lighting modes is going? We have a few questions we were looking for feedback on that I thought I'd post here:

    1. Does the transition to Static, Stationary, and Dynamic light modes make sense to you? Is the terminology accurate or descriptive enough compared to the previous modes?

    2. How is the Light Explorer holding up for you? Does it handle most of your workflows or are we missing anything in there you need?

    Any other feedback you have while using this feature is greatly appreciated!

    @PhobicGunner - I'll look into this with our dev team and get you an answer.

    @S_Darkwell - Will have a chat with the dev team about this one and get back to you.
     
  11. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    231
    This is on the roadmap for sure. We've been very busy with lighting modes and progressive lightmapper lately. But once these stabilize we will get back to this among other things.

    Cheers,
    Jesper
     
  12. MinhDao

    MinhDao

    Joined:
    Oct 28, 2013
    Posts:
    155
  13. kemalakay

    kemalakay

    Unity Technologies

    Joined:
    Jul 12, 2016
    Posts:
    224
    Hey,

    @PhobicGunner - You can use `Light.bakedIndex` to identify a light's contribution to a lightmap. That doesn't output any compilation errors while building the standalone in the latest versions of Unity. Please check the documentation page here: https://docs.unity3d.com/ScriptReference/Light-bakedIndex.html

    @MinhDao - Currently, this is a known bug and unfortunately, new lighting modes don't fix it. However, we will definitely address this issue later.

    @KRGraphics I couldn't manage to reproduce this issue on our side (thus, with 3000 static objects and 200 stationary lights), but ensure that you have enough GI cache. If the issue still persists, then please share your project, that would be very helpful to debug.

    And as Shawn said, please also provide your feedback about how you find the new lighting workflow.

    Thank you!
     
    Last edited: Dec 29, 2016
  14. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    The new light modes are great, by the way. It's awesome to be able to have baked distance shadows - it enabled me to use a single cascade and move the realtime shadow distance very close to the viewer for a mobile graphics test I did (http://jetfistgames.com/Files/Videos/MobileGFXTest.mp4). This scenario would have been impossible previously, so very good job!

    Bit of a question though - let's say I wanted to swap out my shadowmaps for projector-style shadows (maybe project them in screen space into a sort of screen-space shadow mask, not unlike deferred decals). In this scenario, are there any pointers for how I might integrate that with either the shadowmask mode or the subtractive mode? Maybe some shader files I should refer to for how those work?
     
    StaffanEk likes this.
  15. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,221
    It's good to see mixed mode back and it works very well but the experience with the new lighting modes is confusing with all these options and the info bubble bombarding me with too many words - an image explaining what I'm getting into would be very nice, because, ya know, I'm doing lighting I'm an artist not a genius speed reading nuclear physicist.
    Lighting mode: why would I want substractive when shadowmap looks more integrated? (THIS info bubble I can't read past the 4th word) what do distance shadowmap and baked indirect do? it's like probes? They look the same.
    The GUI of the old lighting panel was a bit clearer, it took quite a few iterations to get there. For example the toggle was in front of the title whereas now it's below the title so when you fold that title you can't access activation button or see in one glance what's on and what's off. The terminology was also more precise: realtime GI? I wish, better call it what it is: precomputed dynamic GI, also where is realtime resolution? Ah I found all the way below, makes sense.
    So global illum get baked even when I have only dynamic lights, from the sky? That's cool.
    use "auto" instead of the ultra verbose "auto generate" less is more yeah?
    I'm confused about probe occlusion, does it mean probe now contain shadow information? It's always been the case isn't it. What is probe weight? I'd move the probe visu options to gizmos and keep this panel centered around settings that affect lighting.
    Segway: since you're improving the lighting system, why not fixing probe selection as well.

    1. static mixed dynamic was clear because we had two varieties of lighting and so mixed was a precise way to tell us it combined those two, but maybe stationary means more than mixed in the new system? Explain that with a few images.
    2. The light explorer is cute but I can't see a use for it, I name my lights with what they do and hierarchy search and filters works perfectly. Good candidate for the asset store, IMO.

    ... one last thing: maybe it's a good time to fix the behavior of dynamic GI when changing light in the editor, the GI solution has never updated unless auto was on, at runtime it makes sense because GI only updates when you call the GI.Refresh() or whatever it's called but when I'm not in play mode that doesn't make sense to enforce that.
    ... one last thing: dynamic GI isn't supposed to break lighting is it? ambient mode in realtime does that, why isn't it reading the skybox?

    Screen Shot 2016-12-31 at 1.36.43 PM.png
    Screen Shot 2016-12-31 at 1.36.36 PM.png

     
    Last edited: Dec 31, 2016
  16. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    Subtractive is faster.
    Yes, the new system has far more possibilities than the old "mixed" mode did. I can't be bothered to make images now though :)
     
  17. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    What are the steps to replicate this? I tried it just now, and it seems to work properly.

    Also, here is a quick explanation of the modes.

    Baked Indirect means, direct is realtime, indirect is baked into lightmaps.
    Shadowmask means, everything static is baked into lightmaps, dynamic object cast realtime shadows that blend properly with static ones.
    Distance Shadowmask means : Up to shadow distance it behaves like Baked Indirect, further than that, it switches to Shadowmask.
     
    Last edited: Jan 1, 2017
    laurentlavigne likes this.
  18. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    This is good feedback. We don't tend to put documentation in Unity interfaces but this was an experiment as the Modes do have a lot of stuff going on behind the scenes that's not apparent from their names to users. I'm not entirely sure an image inside the interface would help much here given the size of the window but I'm curious to know if there's any value at all to the info boxes or is it just wasted space for people? Is this something you would prefer to have better documentation elsewhere for?

    Sounds like we could do a more thorough job explaining these up front with a video overview of the feature set? We bounced around quite a bit with the toggle being on the main menu entry like the old system and figured we'd try the new approach for the beta to see how it measured with users. I'm quite curious to hear more feedback on this change and how people feel about it. For the terminology our attempt here is to move to more human readable terms and away from using acronyms but it sounds like that missed the mark? Interesting point about "Auto" as many users found this to be too assuming - you tick a box that says Auto but there's no affordance or link to what it is for new users.

    The goal is to have a good amount of material out of the gate to help illustrate the changes, show the benefits of the new modes, explain why you would want to use each mode (situation, cost, benefit, etc).

    Note taken for the Light Explorer.

    Thanks for the feedback and Happy New Year!
     
    laurentlavigne likes this.
  19. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    900
    My opinion is that the info boxes are exactly the right idea here in this interface - I think the problem right now that @laurentlavigne has correctly pointed out is that the content within those boxes, at the moment, is repetitive and opaque. That text is dense with jargon about the "how" of the lighting system instead of being explanatory in terms of the "why" of each choice. Instead of each mode explaining how it's implemented, it should instead explain its best use cases, as in:

    "Use this mode when you need your dynamic objects to properly cast shadows on static objects at all distances, and can afford some overhead. If you're in a constrained environment such as mobile, consider this other mode instead..." or something.
     
    Dreamaster and laurentlavigne like this.
  20. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    I think that's something for the docs though.
     
  21. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    Thanks for the feedback. So your thoughts are that the info bubble should be more about why you would use the mode instead of the details of what the mode does? This is something we'd really like to find a good balance for as right now we do go a bit overboard with the technical jargon and some of it is pretty large blocks of text.

    @AcidArrow - I'd be curious to know where users see us drawing the line at in-editor vs going to docs. I think we can definitely clean up the messages a bit now but wondering at what point users will feel like the docs makes more sense to them.

    Keep the feedback coming.
     
    laurentlavigne likes this.
  22. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    In this specific case, I think it's something that is much easier explained with a bunch of images (or maybe a video), than pure text, so the explanation, I think, belongs in the docs and it would be counter intuitive to try and have a full explanation in the editor (I mean, the first experimental build did something like this and while I was able to "get it", the text was a bit overwhelming, and required very careful reading. And, after I "got it" it was just wasted space)

    My personal opinion is this : In editor text shouldn't attempt to completely explain what the feature does. That's something for the docs. In editor text is useful in cases where I already understand the general gist of it, but I can't exactly remember which is which. (Like: "I want the one that bakes direct on static everywhere, which one was that again?")
     
    laurentlavigne likes this.
  23. fguinier

    fguinier

    Unity Technologies

    Joined:
    Sep 14, 2015
    Posts:
    146
    Hi PhobicGunner,

    For subtractive mode (forward only):
    To change the shadowmap sampling/dist comparison with a projector based i would look at UnityComputeForwardShadows() in AutoLight.cginc.
    The "darken the lightmap" code could be interesting to read as well its in UnityGlobalIllumination.cginc in SubtractMainLightWithRealtimeAttenuationFromLightmap() however it should work the same no matter how realtime shadows are done.

    For shadowmask mode
    forward rendering : UnityComputeForwardShadows() in AutoLight.cginc seems a good start as well.
    deferred rendering : i would take a look at UnityDeferredComputeShadow in UnityDeferredLibrary.cginc.
    Other than that the code in UnityShadowLibrary.cginc is probably usefull to read also, for example : UnityMixRealtimeShadowAndShadowMask().

    Last but not the least : Happy new year to all !!! :)

    Florent

     
    kemalakay and StaffanEk like this.
  24. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    To prod the question again here since we'd like more feedback on this matter what are the current thoughts around Static/Stationary/Dynamic naming? Is it intuitive to everyone? For example if I asked you to create a scene with only baked lighting what would you expect to see on a light drop-down to force a light to produce baked lighting only?
     
  25. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I think the naming convention works well enough. If I were to try and guess what these meant without any knowledge beforehand:
    - To me 'Static' implies that it is a fully-baked light since that's what Static generally means in the context of a game engine. Maybe it's not really clear from the name that these lights don't light dynamic objects in the usual way (that is, that they are baked into probes instead), but that's not a super big deal as far as I'm concerned; there's only so much information you can try and convey with one word. A little RTFM will go a long way in that regard.
    - Stationary sounds as if some optimizations are available to that light because it's assumed not to move, but not quite as baked as a Static light is.
    - Dynamic implies something like a light that is fully movable and isn't baked at all.
     
    laurentlavigne and smcclelland like this.
  26. kemalakay

    kemalakay

    Unity Technologies

    Joined:
    Jul 12, 2016
    Posts:
    224
    Thank you for your feedback!

    This is a known issue and already fixed in the next beta version. The fix simply didn't make into this beta, sorry for the inconvenience.
     
    laurentlavigne likes this.
  27. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    Hi.

    I am trying to figure out how i should go forward with my game dev. I have fairly complex scene for my VR game and i am currently hitting 90fps with my directional spedcular lightmaps. With the new lighting system the directional specular lightmaps are being deprecated and this means i cannot have all the specular highlights back without sacrificing performance on extra rendering.

    For example on the attached screenshot is a fully baked environment in 5.4 When i am watching this scene trough vr the triangle count is around 1.5 million and hits 90 fps on target hardware. The lightmaps itself were janky at places but it was acceptable.
    Now i tried the same scene in 5.6 and with default directional lightmaps and without the specular highlights it looked bad.
    The only way i could get somewhat similar result was by adding two stationary point lights that gave me realtime specular highlights. For VR i am using forward rednering and i did my best to make sure that these stationary lights do not overlap each other. This way i got some of the specular highlights back but now triangle and drawcalls have doubled. 3 million triangles and 2000 drawcalls. I am barely hitting 60 fps.

    I cant stay on 5.4 forever. Unity own study cases are not helping me. Adam interior demo is not made for VR and is not running at 90fps. Other VR samples are rather simplistic. I am trying to achieve somewhat realistic scene and carefully fine tuned over the years to keep it at framerate but this new lighting workflow ruins everything.

    Not sure what to do in this situation. I am not high end graphics specialist, maybe there is a workflow for me that would help me keep the visual style without losing all the details that we worked on so hard.

    Unity guys, if you are interested i can get you this scene in near future if you would like to test it. It is a pretty complicated scene and would be a good candidate for lightmap stress testing i think. Maybe there is a solution that i am not aware of.

    Any input and advice is highly appreciated.
    Thanks

     
  28. MrEsquire

    MrEsquire

    Joined:
    Nov 5, 2013
    Posts:
    2,712
    When is the next beta, seems holiday delay?
     
  29. Petter_G

    Petter_G

    Joined:
    Apr 19, 2016
    Posts:
    12
    Have you tried using box projected reflection probes? You could open the reflection probes in Photoshop and then use the Flexify plugin to make changes easier. Then add highlights.

    Import Unity 6 frames > convert to Equirectangular and change the reflection probes by adding some very bright overexposed pixels to certain spots, then back to Unity 6 frames. Make sure to upscale the probe capture in Unity to get rid of aliasing.
     
    KarelA likes this.
  30. plmx

    plmx

    Joined:
    Sep 10, 2015
    Posts:
    308
    Hi guys, nice to see you working on the lighting modes. We are working on room-scale VR games and for the last game had to switch to "The Lab" renderer due to realtime shadows. I am now trying again for the next game.

    I would suggest keeping the text; I find it very helpful to have some explanations in-line. In addition, I find the tooltips to be quite good, too. As Laurent mentioned it uses a lot of jargon, but I think that's OK, IF the jargon is unambiguous (see below) AND I would add a link directly in the text box to a more thorough explanation in the docs. This way I can directly jump to the docs for an explanation, and later will hopefully remember when opening the panel again what the jargon means.

    I personally don't find the naming scheme to be intuitive, particularly since the words "realtime" and "baked" still appear in several places, even in the UI, and game objects in general can be set to "static", which is yet another word which may or may not be the same as "stationary". This immediately begs the question what the difference and the relationship between all those words and concepts is, if some mean the same concepts but just in a different context, or whether there is an n-to-m mapping. I was missing such a "global view" even in the old docs.

    Thus my main suggestion is adding documentation for overall lighting in the form of a comprehensive table or flow chart. This should explains the relationships between light modes, types, shadows, objects (static/dynamic), light probes, and the options in the scene lighting window, i.e. what kind of shadows and lights are cast when using this-and-this combination of light types, shadow modes, object types, etc. Such a chart or table could point out the most common combinations of settings, could point out which combinations don't make sense, and could potentially give some example rendering screenshots. Maybe it could also, for some common setups, point out which settings are good for which end results (as in "I want to have shadows on static and dynamic objects" => you have to use these lights, these light probes, this rendering mode).

    Obviously what is confusing to one person may not be confusing to the next. If I don't understand something, it may be me or the docs/terminology. But here are some things which I find confounding because I think the terms are too ambiguous (not only with regard to the new names, but in general with regard to lighting in Unity).
    • For me, "stationary" implies that something (possibly the light itself, but could also refer to shadows?) "can't move". Thus, "dynamic" probably means that it can move. However, normal game objects that can move should be "non-static", and those that can't move should be "static". So maybe "static" in the light means "can't move" too. But then, what does stationary mean? In the first post of this thread, for example, you write "Stationary lights allow a mix of dynamic and baked lighting." - Is "baked" here an oversight which should be "static" as in "static light", or do you really mean "baked", which thus does refer to something different?
    • Do "dynamic" and "stationary" only refer to the light itself? Or do they also somehow affect game objects depending on whether THOSE are set to static or dynamic? If so, is this a 1-to-1 relationship or how do the different light modes affect the different game object modes?
    • In the Scene panel there is "dynamic lighting" and "stationary lighting", but the checkboxes below use the words "realtime" and "baked" which I find confusing. Also, I am continually thrown by the name "global illumination", which to me implies lighting in general but what is actually meant here is indirect lighting (right?), but this is something I will eventually remember I guess ;-). It is also confusing that there is another panel called "Global Illumination" in which you can set an "ambient mode" which also uses the words "realtime" and "baked".
    My main issue with the previous lighting implementation, however, were dynamic shadows. I did comment on the differences to "the lab" in this thread. My question here is: Did anything change regarding shadow quality in the new implementation? From my tests this doesn't seem to be the case; the quality of the shadows of point lights in particular is still extremely blocky, regardless of settings. Any thoughts (or tips) with regard to this topic?
     
    Last edited: Jan 7, 2017
  31. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    We will definitely be keeping the text and doing a few more passes on the verbosity of it in the next couple cycles. What I'll probably wind up doing is sharing some of the mock-ups here to help steer the discussion before we implement it so there's consensus amongst users that we have the right amount of information and clarity.

    This is exactly the type of feedback we want to hear! In your opinion what's the clearest terminology to you? The primary difference between a lot of this is the functionality that each light has. A 'Static' light for example will always be baked into lightmaps whereas a 'Stationary' light can use the light modes to produce a mix of dynamic and baked lighting. Our use of realtime has always been met with some mixed views as the Realtime Global Illumination isn't exactly that since the indirect is pre-computed from a set of realtime lightmaps. This used to be called Pre-Computed Realtime GI and before that I believe it was once called Dynamic Global Illumination.

    With all that said... we really want this to be intuitive so I'm all ears on what terminology is the most logical here. In Unity 5.5 the light modes for example are called Realtime, Mixed, Baked.

    For the documentation we will absolutely be providing a lot of comprehensive pages on the relationships of the modes, lighting, effects, etc. It's something we're actively working on now with the beta docs to help users understand what each lighting mode does and how it interacts with all of the systems/objects in Unity. We're also working to setup some example scenes and scenarios that help illustrate the benefit each mode has with a certain genre or setting in a game environment.

    This next section really illustrates to me that we've created a bit of a mess with the current naming as I can see many new users coming into this and just getting lost at the subtle variations of naming here. I'll add some information but I just want to preface this by saying I'm not justifying the naming here and we're open to changing it.

    a. Stationary lights can move but it's not something we recommend users do as it will conflict with your baked lighting since that won't be updated as the light moves. Static in terms of the light means that the lighting data will always get baked into lightmaps - this was probably clearer before when the light mode was called Baked and was pretty clear to the user that if they used this on a light it would always be baked lighting. Baked here isn't an oversight but actually what the Unity lighting system does to a light marked 'static' - all illumination generated by the light is baked into a lightmap.

    b. Dynamic and Stationary do indeed refer to the light itself. A dynamic light is a light that can move, change, and be updated at run time in your game (say a flashlight, headlights of a car). These can affect objects marked 'static' or non-static objects (we tend to call them dynamic objects). Stationary lights are a hybrid between the static (baked) light and the dynamic (realtime) light in the sense that they have these modes that allow for mixed lighting to be used. This allows users to get much more flexible, and performant lighting in their scenes by using stationary lights. To re-use @AcidArrow's good summarization for example if you put only stationary lights in your scene and chose the Baked Indirect mode then all of your direct lighting is done in realtime and indirect is baked into lightmaps.

    c. Yeah... since you pointed this out I've been mulling it over a lot that we've got many terms that are too similar to be of much use to users. It does seem like we really need to evaluate the use of "Dynamic" vs "Realtime" and "Static" vs "Baked" to be more clear here. I'd be curious to know which you prefer. Yeah, I need to fix that Ambient Mode label as well and get it back to the right area and a bit more clear. Yes, global illumination specifies how indirect light is handled. The "Global Illumination" section you see below is for more of the general settings on how the system is setup. Would be good to understand how we can make that a bit clearer as well :)

    It's also worth noting just because it's in the beta doesn't mean you have to accept it! :) If you look at something and say "that doesn't make sense to me" or "that seems unintuitive", call us out on it. A lot of times we won't be right and we need you as the users to really help us understand the problems you have with these things to correct them.

    There haven't been any changes directly to the shadow quality though it is definitely something we hear users loud and clear on. I'll take a look at your other thread and chat with some of the team members about what we can do or information we can provide to increase shadow fidelity.

    Thanks again for this great feedback!
     
    laurentlavigne likes this.
  32. plmx

    plmx

    Joined:
    Sep 10, 2015
    Posts:
    308
    Hi,

    thanks for this very nice and positive post and attitude! I'll help out as much as I can. Great to hear you're working on "relationship docs" ;-) The beta docs I've scrolled through so far seem much more explicit than the current ones. Good!

    You asked what the clearest terminology is for me. Terminology should be unambiguous and as simple as possible. I thus thought about how to simplify some of the terms here, but lighting is such a complex topic that I couldn't think of a good way to get that complexity out of the terms, which makes it even more important to have good docs with relationship info. Nevertheless, here are a few rather minor points in terms of terminology from my perspective.

    I would prefer "baked, mixed, and realtime" for the light modes. I have the feeling those names accurately reflect what the light is doing. The other names seem unhelpful since so much more hangs on this selection than merely whether the light moves, and the movement-related names also overlap with the various static settings of a game object.

    Speaking of that, I find the "lightmap static" checkbox is way too hidden, and to me its placement in a long list of "static" options does not signify its importance for lighting. What about adding a dropdown to each game object's renderer where you can select the lighting-related mode as "dynamic" or "static"?

    I like the four new mixed mode "modes", and the fact that they are explained in the text box below. What I would also suggest is adding a similar text label below the mode in each light, where it clearly says what the mode implies. In particular, it should mention - like the mode descriptions - if light probes are necessary, and where light maps and shadow masks/maps ( are used. Another thing which would be helpful here are links to related artifacts - for example the affected light probes, light maps, and maybe other related settings?

    I'd also change the scene lighting panel. I'd personally get rid of the name "global illumination" since it seems to be used both in the abstract (as in "set of algorithms for realistic visuals") but also very specifically for indirect lighting, and "global" can mean so many things. Why not call indirect lighting "indirect lighting", ambient lighting "ambient lighting" and non-specific lighting settings simply "lighting"? I'd also suggest adding three sections "realtime", "mixed", and "baked" which contain the settings and infos for lights with these modes, along with links to stats, a lightmap view, a light probe view, etc. Sort of like a "portal" for all things related to this lighting mode.

    Thanks for looking into the shadow issue, this really is a big problem for us.
     
    laurentlavigne likes this.
  33. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    Thank you so much for your suggestion. I will certainly check this out asap.

    @ Unity lighting guys. Any statement from you would also be greatly appreciated. Even if it is negative. Just want to be sure that i am understanding my situation correctly and there is no good workaround for my described situation without rendering extra geometry.
    At least then i know my position and can start working on custom reflection probes and removing geometry.
     
  34. uy3d

    uy3d

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    187
    @plmx I assume you've found the new docs explaining the light modes already. At the bottom of that page there's a link to a reference card which gives you an overview of the modes. The reference card actually has two tabs which present the same data in two different ways and should fit neatly on a page if you want to print it out.
     
  35. plmx

    plmx

    Joined:
    Sep 10, 2015
    Posts:
    308
    I did; however I assumed that the page you linked to isn't finished. I really liked the first two sections ("Introduction" and "Precomputing") which set a great pace and explains things nicely and on a high level. After that - with "lighting modes" - the document just stopped and provides links to other pages. I was expecting there to be more explanations in the same vein and on the same abstraction level about generic things such as light maps, shadow maps, shadow masks, differences between shadows, what a light probe and a reflection probe is, etc.

    I skipped through the linked individual docs, and what I noticed is that those docs seem pretty focused on an individual topic, for example, "dynamic lights". The explanation seem good but there is little cross-referencing to other topics; you have to read all individual docs and then form the complete picture in your head. What I am suggesting here is that the overview doc do that for you. Specific stuff can even be repeated in the individual docs, which can also information which is really only required for the topic at hand, as has no relations.

    I had not seen that! That is really helpful and should be given a prominent place in the docs! The terms in the reference card might, by the way, be a good guideline of what could/should be explained in the overview doc above.
     
  36. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,221
  37. uy3d

    uy3d

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    187
    @plmx There are still a few missing things in the current docs, but right now there are no plans to explain everything regarding lighting in there, as there already is existing documentation covering topics, like shadow masks or light probes (if there's enough demand, though, then we can take it under consideration, I guess). If you want to have a continuous explanation of what's going on with regards to light modes, the reading order would be Introduction => Technical terms and Notation (that's a separate page linked to from the main page) => Precomputation => Lighting modes => Dynamic Technical Background (separate page) => Stationary Technical Background (separate page) => Static technical background (separate page). Shadowmasks are for example explained in the Stationary Technical Background section. I restructured it in the current way so people that don't care about what's going on behind the scenes can quickly access the information they need to use the new light types and modes.

    @laurentlavigne LoDs of statics have always used lightmaps. However, in order to generate them, light probes are still necessary. How it works internally is that everything is baked at LoD0, so we get lightmaps for LoD0 and light probes for dynamics. When creating the lightmaps for higher LoDs, instead of baking everything again, the light probes around the static mesh are sampled instead and a lightmap for that LoD level is generated. So, because of this intermediate step in the baking process, you still have to surround all your static LoDs with light probes to get good LoD lightmaps, even though no dynamic object will ever pass through there.
    Also, we've fixed a bug with regard to how the probes are sampled in the intermediate step, so LoDs should look much better now.
     
  38. plmx

    plmx

    Joined:
    Sep 10, 2015
    Posts:
    308
    @uy3d I see. Well, a middle way would be to document the reading order you just told me somewhere in the docs themselves, perhaps under a heading "Gentle Introduction" ;-) such that people who want to have continuous intro can follow it.
     
  39. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,221
    Since enlighten replaced Beast we were told that Enlighten can't bake LOD1+ and needs probes to sample lighting in the same way dynamic objects do, hence the pop we'd see when switching LOD in static objects, and were told that it's a quirk of enlighten that Unity can't do a thing about. What it sounds like you're saying is that it's not the case: LOD1+ use probes instead of sampling LOD0 lightmap or baking for each LOD because someone at unity thought it'd be more efficient. Yes?
     
  40. uy3d

    uy3d

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    187
    @laurentlavigne This intermediate step that I have described all still happens within Enlighten. So what you have been told is still true. Unintuitively, in order to bake the lightmap for LoD1, Enlighten doesn't look at the baked lightmap of LoD0, but looks at the baked light probes surrounding that LoD1. That's why Enlighten still needs light probes around LoD1+. But, Enlighten cannot auto-generate light probes around the LoDs for this internal step and then throw them away again. So these must be provided from outside, in other words by you.
    To recap, what happens when you hit bake is (this is all within Enlighten, and a bit simplified):
    - Enlighten creates some internal representation of the scene at LoD0 that it needs for its calculations
    - bakes lightmaps and light probes
    - goes over all LoD1+, samples the probes in the vicinity of the object and bakes lightmaps for LoD1+
    At the end of this process, the LoD1+ all have proper lightmaps on them which are saved to disk. And at run time when a LoD1+ is rendered, it is rendered only using the lightmap on it, just like LoD0.
    So, as a general rule of thumb, if you want to use GI, you need light probes:
    - everywhere dynamics go
    - around all LoDed static meshes
    Do NOT think about light probes as a means to only light dynamic objects.

    And we'll make it even a bit more complicated. The one difference in rendering between lightmapped LoD0 and LoD1+ is that LoD0 gets realtime lightmaps as well, whereas LoD1+ doesn't. So, if you use Realtime GI, then the realtime indirect lighting for LoD1+ must also come from realtime light probes (and we're still working on supporting that case).
     
  41. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,221
    keyword here is "unintuitively" - good to hear you guys know it's super weird and I'm sure you saw it takes quite a bit more work to get non poppy-results.
    Is this something you folks can fix, removing that extra step of adding extra dense light probes around static LODs? My guess is it's tied very close to how enlighten computes light transport between surfaces and unless the UV2 are the same on all LOD levels good luck.
    At least have the progressive lightmapper function like Beast on LOD
     
  42. GenaSG

    GenaSG

    Joined:
    Apr 19, 2014
    Posts:
    111
    Hello everyone,
    First of all I want to say thank you!
    Shadowmask modes are great and they give that sweet middle ground between fully dynamic and fully baked approaches. It's awesome.
    I have one assumption but it looks like that it is a false one.
    I assumed that there would be possibility to choose GI approaches(Realtime/Baked) for Stationary lights with Shadowmask. So it would be possible to have Stationary lights with dynamic GI. For example flickering lamp or 'Sun' with weather effects like clouds, rain, etc.
    Maybe I'm just missing something and it's there already or it shouldn't be there in the first place.
    Anyway thank you guys.
     
  43. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    584
    I find the names confusing, particularly Static vs Stationary. By definition, static means 'unchanged' or 'not moving'. Stationary means 'stays in one place'. My intuition would tell me Stationary is good if I have lights that need to rotate, but stay in one place?

    I understand this is not what it means, but you are using that term to recommend that the light not move, but it can, I think. For me, simpler and consistent terms should be used for all lighting - Static, Hybrid, Dynamic. Then, I at least understand hybrid is some combination of things that I need to look up.

    I think tool tips are helpful here, and I like when parenthesis are provided (fastest) or (highest quality but slower ). The tips should point us in the direction of why we might choose a particular mode.

    In terms of how they work with lights, probes, etc. If static requires that at least one light be set to static, there should be a message informing us of that or a requirement (yellow warning flag until the condition is met) like we see for some rendering options. Likewise if probes are required for baking, I did not know that and had given up on baking as it is so slow and the results were unpredictable. I thought probes were an option if I wanted lighting to change while moving a character through a space.
     
    plmx and moco2k like this.
  44. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    Hi all,

    Based on the feedback we've received around the light mode names, the layout of the lighting panel, and other great feedback I wanted to share the latest set of mock-ups fresh of the press. This takes into account a number of points from this thread but here's the summary:
    • The "Environment" label at the top has been removed and we have changed 'Distant Environment Lighting" to simply be "Environment Lighting" and "Reflections" to now be "Environment Reflections". We hope this makes the section a bit clearer and easier to work with going forward.
    • Ambient Mode has been relocated from the very depths of the interface (previously Global Illumination) back to its rightful home in Environment Lighting.
    • We have moved back to the Realtime, Mixed, Baked lighting modes as we feel that describes the lights purpose much better than Dynamic, Stationary, Static. Please let us know your thoughts on this and how it feels or reads in the mock-up. @plmx this will hopefully address the problem of seeing intermixed Static/Baked and Dynamic/Realtime text throughout the interface.
    • We've done a pass over what was previously called "Global Illumination" and renamed the section to be "Lightmapping Settings" to be clearer about the properties. We have also moved all lightmap related properties to this section as users found it confusing that lightmap settings were part of the old stationary lighting section but also impacting the old static lights.
    • The legacy effects section has been relocated to the bottom of the interface under "Other Settings" now and will be collapsed by default to save on space.
    • I put a small test in as far as tooltips go to see if we can shorten it a bit but be warned these aren't 100% accurate. I just wanted to see how the sizing was with two lines and try the summary approach. If users think this is a good length then we'll tailor it more towards a "why you want to use this" and less the "here's the voodoo this thing does behind the scenes".

    As usual, fire away with the feedback and don't hold back :)

    Lighting Panel v2.png
     
    Last edited: Jan 17, 2017
    plmx likes this.
  45. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    That dropdown for lightmapper is supposed to switch between enlighten and the progressive, right? Then does that mean I can't use the progressive for baked GI and enlighten for realtime GI?

    Other than that, I like the mock up, seems like an improvement. I also really like the change from Bounce Boost to Albedo Boost, makes a lot more sense now (also, it may be just the mock up, but will we be able to have bounce boost to be lower than 1? I never understood why 1 was the minimum for that value).
     
    smcclelland likes this.
  46. plmx

    plmx

    Joined:
    Sep 10, 2015
    Posts:
    308
    First of all, let me thank you for doing these feedback rounds. I suspect it is a lot of work and I am grateful for it. I think that the new panel is a major improvement over the current one.

    I think this makes it clearer, yes.

    Definitely helpful as well.

    Thanks for this! I think these "old" names in this case are indeed better, and as you said match all of the other labels and documentation out there (less to clean up as well I guess).

    I think that moving the properties into one section for lightmapping is indeed way more understandable than having them in "stationary". Also, googling "Lightmapping" probably leads to more insightful matches than "global illumination". I think the name change here is great.

    Having said that, I wonder why "Global Illumination" as a name still shows up in the checkboxes in "Realtime lighting" and "Mixed lighting". Maybe I don't understand what these settings do, precisely, but the tooltip in the current beta for "realtime GI" seems to say "enable this for indirect lighting" (so why not use "indirect lighting" as the text of the checkbox?), while the tooltip for "baked GI" is more complex (and frankly extremely confusing) but at least it seems to suggest that this settings affect stationary AND static lights, so why is this setting still under "stationary"/"mixed"? If it really affects both kinds of lights, shouldn't it be part of another section?

    I was not aware that these are "legacy" (which to me implies "deprecated") - the docs don't say so and it's not in the tooltips. Shouldn't this be announced somewhere?

    Not sure what you mean here? I'm not getting tooltips in the browser, if that was intended.

    Since I am "the shadow guy" I have to ask why the shadows section in Settings>Quality is there, and not in the lighting tab. To me they seem pretty related, so why not add them here? Additionally, some of the settings in the shadows panel only affect some types of lights (for example, shadow cascades only affect directional lights). What about adding this info to the UI? Perhaps have a "Directional Light Shadows" section with the directional lights settings (and similar for the other light types, if there are any, which I don't think is the case)[by the way: Why can the lightmap resolution and size be configured, but not the shadowmap?]

    Oh, and I like the fact that the mixed lighting modes are now radio buttons. Much easier on the eye and for choosing a mode (I assume that the textbox changes when hovering over a mode?).

    Again, kudos for your work so far.

    Best,

    Philip
     
    smcclelland likes this.
  47. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    Because it enables/disables Global Illumination? Going by what you said previously, googling Global Illumination will give you more relevant result for what it does than the more general "Indirect Lighting" which might mean a number of things.
     
    plmx likes this.
  48. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    231
    The lightmapper dropdown only switches the "static" baking engine (the one that produces the static lightmaps) to the progressive lightmapper you can still use Enlighten for realtime GI in conjunction with that. You cannot, however, use baked shadowmasks with realtime GI, which is a totally valid use case: A light that doesn't move so you can bake out the shadows, but you can still adjust the other light properties and have the indirect update accordingly. An oversight on our part. If this proves a popular request we can add it later.

    The albedo boost draws the albedo towards white, which is useful when you have relatively dark textures that kills off the indirect lighting too quickly. We have never had a customer requesting the other way around. I think you rarely have too bright textures; but I might be wrong?
     
  49. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    Well, the use case is exactly the opposite :) If you generally have too bright textures (which can happen), you might want to globally reduce the albedo a bit so GI is a tad more realistic.

    Since PBR materials generally have dark materials (because in reality albedo is not that bright), if you are using non pbr materials (which may have somewhat brighter textures than it *should*) maybe reducing the albedo globally might improve results ever so slightly.

    It's not an issue, but if it's all the same, having it start from 0 makes more sense to me than artificially having it start from 1.
     
  50. smcclelland

    smcclelland

    Administrator

    Joined:
    Dec 19, 2016
    Posts:
    147
    This is more of just following a standards practice. We call it Global Illumination primarily as that's the terminology used throughout the industry to describe the effect of calculating indirect lighting. The GI tooltips are on my list of things to redo as well - I went too verbose with those and need to pull it back a bit to be more understandable. You're correct that this settings affects both Mixed and Baked lights but what it's really doing is instructing Unity to use Enlighten to generate the baked lightmaps for calculating indirect light. Previously this was exposed as a much more global effect (checkbox on the main widget called Baked GI) which made it quite clear you were enabling a new feature. I can see how this might be confusing and look like a sub-feature.

    I probably should have used a better word than "legacy" really :) They're still supported and not deprecated but they're just old effects that have been kicking around for a while.

    I should have clarified I meant the i icon text beneath the different lighting modes.

    Huh - that's actually an interesting point and ties to something I was discussing with a dev today about lightmap parameters as well having properties that are more closely tied to objects than settings. I don't have an answer right now off the top of my head but I'm curious what you'd like to see exposed here for Shadows.

    I almost forgot as well but we've relocated "CPU Usage" to the Edit -> Project Settings -> Graphics. This will now allow you to specify the amount of threads you want to dedicate to Enlighten per-project instead of the current per-scene setup. We felt this was much more flexible for users but let us know if you're against this change.

    Cheers,
    Shawn
     
    plmx likes this.