Lighting Modes in 5.6 Beta 2

I see; I had a different association but then I'll change my understanding of the term. ;-)

Yes, to me the placement inside "Mixed lighting" implies that it is only relevant for mixed lights (same as for "Realtime GI" and realtime lights).

Ah ok. I like both the text and the size.

Well, to me shadows are a part of lighting, so I was confused as to why its in the global settings at all instead of the lighting tab, so I think I would move all of them (soft/hard shadows are also configurable on lights, so the lighting tab seems "nearer" to those).

If there are any internal shadow settings which allow to remedy this situation then please expose those as well ;-)

 

Yeah I guess you're right! Wrong association with the term on my part.

 

This one's tough when I think about it since the shadow interaction actually comes from the light and the objects but then you have more project specific settings which is where areas like Graphics and Quality come into play. A lot of the settings in both Graphics and Quality aren't something every user would want access to and I'm not 100% sure you'd really be changing those frequently enough to warrant them being in an interface like the lighting panel.

There's definitely merit though in going through all of these interfaces and identifying if we've really found the right homes for all of this stuff or how we can improve.

 

I like the new grouping a lot! I can tell that you folks have been giving this a lot of though, simplifying to that level, thank you.
I'd rename mixed lighting to baked lighting and move those toggles to the left like before because the light mode only affects baked maps.
Regarding naming of the rest, after using it a lot this weekend I got the idea of what all the modes do in realtime so I don't mind the unusual naming. And since we're doing realtime here, I wonder if the infobox is even necessary, seems redundant because nothing is hidden, maybe tooltip. Also those boxes add unpleasant visual noise and macbooks have limited vertical space:

Regarding the explanation, I'll chime in with @Claytonious: keep the wording non technical "real time shadows up close then baked shadows" and move the tech stuff to the documentation.

 

So you would want the interface to be something like this where these three entries are their own top-level rollouts?

Realtime Lighting
Baked Lighting
Mixed Lighting Modes

The light modes actually affect both realtime and direct lighting i.e. do you get realtime shadows, baked shadows, etc which is why we went with calling it Mixed Lighting to make sure it was understood the combination of the two. If we get the radio button layout we may be able to get away with tooltips but with the current drop-down structure the info box provides the best way to inform users since tooltips on drop-downs are quite weird.

 

@laurentlavigne @Claytonious @AcidArrow I've started to do another pass on the info boxes and wanted to get your input on the length of these. Let me know if they're too long, too verbose, if we're missing info you want here, etc.

Baked Indirect - Mixed lights provide realtime direct lighting while indirect light is baked into lightmaps and light probes.

Distance Shadowmask - Mixed lights provide realtime direct lighting while indirect light is baked into lightmaps and light probes. Shadows are handled with realtime shadow maps up to the shadow distance quality setting.

Shadowmask - Mixed lights provide realtime direct lighting while indirect light is baked into lightmaps and light probes. Shadowmasks are used for static objects while dynamic objects are realtime up to the shadow distance quality setting.

Subtractive - Mixed lights provide baked direct and indirect lighting for static objects. Dynamic objects receive realtime direct lighting and cast shadows on static objects using the main directional light in the scene.

 

They seem fine to me. The only thing missing which I think is important is that in "Distance Shadowmask" lighting becomes fully baked beyond the shadow distance. Not sure how you fit it in there without it becoming too verbose though

 

No I meant like this:

See how the check box is smack left after the folding triangle and before the title? is compact, is nice.
Tooltips on drop down are no bueno.
Don't rack your brain too hard with the infoboxes, like I said after spending a few minutes (or was that hours) with the new light modes I knew what to use intuitively. But ... it seems from everyone's descriptions that lighting is object centric (funny uh) so maybe try a setting layout that reflects that?
ex:
Shadowmask - Dynamic objects: realtime direct lighting and shadow up to shadow distance then lit by light probes only. Static objects: direct light and GI baked into lightmaps, realtime shadow from mixed lights up to shadow distance.

If I get that right, it's clearer, shorter and adds @AcidArrow's comment.

 

Yes, that was the original direction I had wanted to go but there was some pushback against using that. I find it clean and easy to just toggle at a high level. At one point we were actually looking at the idea of using it like the mockup below but it felt a bit weird having just these two checkboxes at the top level and nothing underneath. It also broke the association between Realtime lights and Realtime Global Illumination (we use the Realtime Lighting label now to inform the user that Realtime Global Illumination only affects Realtime lights to bridge that association). Would be interesting to hear thoughts on this vs the previous mockup I posted layout wise.

 

I'm confused by the separator between baked and mixed... I thought mixed lighting is only active in baked?

 

Yes. This was something that confused some users. Technically Baked GI affects both Mixed lights and Baked lights but the Mixed modes are only available when you have Baked GI enabled. This was one of the reasons we landed on the previous mockup I posted was to help make it easier for users to understand the association.

 

Hi,

I am using Unity 5.6b5.

I am trying to achieve something like this image with a mix of static and realtime elements:



Here is a screenshot of what I've been able to achieve so far. The cubes are static, the capsule is dynamic.



I have managed to make the static object's shadows behave pretty much how I would like by setting the Baked Shadow Angle to 25 degrees. This only works when in ShadowMask or Subtractive baked Stationary Lighting modes. This is expected since this Baked Shadow Angle is baked lighting only and we don't get baked shadows in Baked Indirect and Disatnce ShadowMask (at least up close).

As you can see from the screenshot, the realtime shadow on the dynamic capsule looks very hard. Is there anyway to get the shadow on the dynamic object more like the very soft shadows on the static objects? A Real-time Shadow Angle slider I can play with to approximate the same behaviour on my dynamic object would be perfect, but this does not seem to exist.

As an aside, I may have found a bug. I added a second directional light to the scene, I had one set to static and the other to Dynamic. The dynamic light is causing realtime shadows to be rendered for the static objects for some reason. I have the static light set as the sun source in the scene lighting settings. I would expect the shadows for the cubes to remain the same as in the image above. It's my understanding that a light set to Dynamic mode should not affect Lightmap Static objects.

The reason for the dual light setup is that I was thinking I could alter the shadow settings for the dynamic objects separately from the static objects and make the shadows appear more similaf. Perhaps just by changing the light direction so the angle is steeper and the shadow is shorter. I may just what shadow information from this light, with all of the shading etc taken from the other light (via light probes for instance?)



Perhaps I've gone down the wrong route entirely, if you can suggest another approach, I am all ears.

Thanks for the help,

Niall

 

How does the new lighting system handle Dynamic objects with static lighting inside such as an airplane cockpit, car interior, ship bridge, etc?

Is there any performance hit when you tag the object as static (so that Enlighten works) but then move the object?

Related:
https://feedback.unity3d.com/suggestions/global-illumination-movable-interiors-cockpit

 

We're thrilled to see this functionality fine return to Unity...but we have a big problem still: Currently we have a project stuck on 4.7.2 because it offers great options for mixed mode lighting -- AND it offers great flexibility within a build:

* On lower quality levels, we use Forward Rendering (baked shadows for all static objects, dynamic shadows for dynamic objects within the shadow distance).
* On higher quality levels, we use Deferred Rendering (baked shadows for distant static objects, dynamic shadows for static and dynamic objects within the shadow distance).

Works great and ensures that the game will perform well on a wide range of computers.

But now with this new system, it looks like we have to choose either Shadowmask or Distance Shadowmask and that's the only mode available within build, which is extremely frustrating and limiting when we have a broad range of players. I asked this question back in September on the beta list, but didn't get much reply, and I'm really bummed that this limitation remains in place. I really don't know what we're going to do, if it doesn't change. Our Steam players are accustomed to high-quality realtime shadows, but that'll kill performance on lower-spec computers. Surely we're not that unusual in having this need? Am I missing some options here? If not, any chance of getting it switchable at runtime, or do you have any other suggestions?

 

@gecko - I just had a discussion with some of our graphics programmers about this and wondered if there's some simplification we can do here to help here.

Currently Shadowmask and Distance Shadowmask use the exact same methods with a few small changes that happen in the runtime environment based on which one you choose. With that said, what if we were to consolidate Distance Shadowmask and Shadowmask into just 'Shadowmask' for the Light Mode and then place a 'Shadowmask Mode' setting inside the Graphics Settings that you can define per tier? This would let you leverage the base Shadowmask system and then define which setting you want to use per tier i.e. Tier 1 = Shadowmask, Tier 2 = Distance Shadowmask, Tier 3 = Distance Shadowmask.

Thoughts on this? Open to all feedback as we do have some time to potentially make these changes.

 

That sounds ideal! (Right? I can't see any downsides, but I haven't spent a lot of time with the new system.)

And we can trigger each "Tier" via quality levels...or anything else in code, right?

Thanks so much for investigating possible solutions -- I appreciate it enormously!

 

I'd be curious if anyone else here has reservations about this change. I'll give it another day or so for some feedback before we dive into the implementation work.

 

Any news on the dynamic object static lighting issue?

 

Sounds good! And if you can do that in the same movement, remove or fold the bottom info box which takes too much space.

 

Hello kemalakay,

I'm afraid I don't understand. If in both cases (Tier and Quality Settings) you're able to switch between the modes through AI at run-time, how can the Tier option have the properties you describe? If I can change it at any time at runtime via code, how can it be limited to "the very beginning (to setup your project before running the build)"? And what do you mean by "to setup your project before running the build"?

And aren't QualitySettings per project as well? And you can just change them at runtime via code. How's this different between Tier and Quality Settings?

 

I also have Tommi's questions....but it looks like Quality Settings method perfectly matches what we're doing now with Forward/Deferred rendering tied to quality levels (especially so the player can change those at any time in the quality menu), so I'm pretty sure I favor that approach.

 

Okay, so Tier allows it to be tied directly to hardware, which is cool, but not as critical to us as being able to tie it to quality levels....so it sounds like the latter is the way we'd prefer it to work.

 

Tier is basically on initialise only so it gets invoked at the start of the runtime and then you cannot change it afterwards. This would also mean there is no API exposed to set this programmatically on the users end.

Quality you can set at any time (when a scene loads, when you change a quality level, etc). This method would have an API exposed for it that you could programmatically call into.

The big question from our end is how often do you really want or expect to change this?

Also, 5.6 Beta 8 has the fixed up naming and lighting interface fixes we pitched in the last mockups. Let me know if there's any further feedback there and how the return to Realtime, Mixed, Baked feels for light modes

 

Thanks for the additional info. We definitely want quality settings then, as we need to let players switch quality/lighting mode at any time. Probably not frequently, but at any time.

 

Hello.

I've read docs and experimented a bit, and everything seems clear enough, except one thing. Stationary Lighting --> Shadowmask. I want static objects to cast shadows on dynamic, so I need light probes to store occlusion data, right? Question is: these light probes are used for shadowing only or they are used for lighting dynamic objects too?

Maybe I've done something wrong, but my experiments've showed me that light probes are used for (shadowing && direct lighting && indirect lighting) of dynamic objects. Is that right? I am not very experienced, so I assume I may be terribly wrong. But if I am right, is it possible to use light probes for shadowing only?

I am sorry for my english.

 

I could be wrong on this, but the only way to do that is with Distance ShadowMask. That uses realtime shadows for both static and dynamic objects up to the shadow distance and then just baked shadows afterwards.

Using just ShadowMask mode, you won't get shadows as such cast onto dynamic objects from static objects, but you can kind of make the whole dynamic object go a bit darker when it's in/around the area of the shadow. You do this by making sure you put light probes in your shadow areas. You should also have light probes in your non shadow areas or wherever there are noticeable lighting changes. They also need to form a volume. I basically just make one set just above the ground, another at character head height and then another a few more metres up int he air (0.5, 1.5 and 7 units I think).

Would be great if you could get proper shadow casting from static to dynamic objects in the basic ShadowMask mode, but I don't think it's possible (would love to be proved wrong!).

 

In general, light probes just store lighting data in some points and use it to lit dynamic objects, but if shadowmask/distance shadowmask mode is on, then light probes also store occlusion data and use it to properly cast shadows from static objects onto dynamic ones. That's what documentation says. If I use light probes, static objects cast shadows on dynamic just fine, but it seems like now dynamic objects are lit both by realtime lights and light probes (is that right, or I am mistaken?). I do not want dynamic objects being lit by light probes, because they are already lit by realtime lights, but I want to use light probes for shadowing, so I cannot remove them. Ideally I want light probes to be used for shadowing and for indirect lighting, but not for direct.

 

I believe that light probes only store indirect light as of unity 5.4, at least when using mixed (stationary) light sources. I guess they probably also store direct light from baked (static) lights. What light probes stored used to be user configurable in the light panel, but Unity removed this and manages it itself now to avoid the double lighting issue you describe.

Last paragraph on this page has the info: https://docs.unity3d.com/Manual/LightProbes.html

So in your case, you definjtely do want your dynamic objects to be lit by both your mixed light and the light probes.

I'd like some clarification from Unity on the light probes casting shadows using Occlusion data. I read this in the documentation too at some point, but after it didn't work, I guessed that maybe it should say "shading" instead of shadows...

I don't see anything about Occlusion data and light probes casting shadows in the latest Beta light probes documentation here:

https://docs.google.com/document/d/116JvLXljfbdfllOLlyzVvWmNWpbUwcYKV16blVHuS2E/edit

Hmm here is something about Occlusion in deferred mode... But it doesn't really explain what it is.

"When a dynamic object uses probes for shadowing it does so by interpolation"

I'm guessing if this is a feature it's not available in Forward rendering mode for some reason?

 

@uy3d Can you comment on light probes being used for shadows, specifically static objects casting shadows onto dynamic objects in Stationary ShadowMask mode?

The table you just linked to has a section for shadows and it says Light Probes for this occurrence. What should we expect that to look like and how do we set it up?

Please see my post above for some more of the confusion around light probes and shadows.

Thanks a lot.

 

Hi, thanks for the quick reply.

Unfortunately, (as far as I can tell) this feature hasn't been working for me at all, is there a test project I can look at for what to expect and some more setup details?

Thanks.

 

Oh, okay. Thank you. I was just confused because when I use light probes, dynamic objects look much brighter, than when I do not use light probes. Well, I guess indirect light alone makes this difference.

 

Damn! Lightprobes are becoming the goto solution to everything.

You guys absolutely must give runtime access to these magical things, like the new navmesh: feed it a new array then call LightProbes.UpdateAsync()

 

there is typo in the documentation for distance shadowmask. Table: Within Shadow Distance: Static caster -> Static receiver: Shadowmask.

 

Does anyone understand this new system well enough to say if it offers new options for performant lighting and shadows with a continuous time of day, in a large open world? I'm trying to figure out the best way to do that without a massive performance problem on older/slower computers (and mobile).

 

Hi all, just a quick update from our end but we opted to not put the Shadowmask changes into the upcoming Beta 10 as we wanted some more time to soak test and make sure we didn't introduce any anomalies. I'll share some screenshots and maybe a video showing how we've structured it but the changes won't go live until a future release.

@gecko a good person to reach out to would be @kemalakay as he's done a lot of scenario testing and scene testing with us and would be able to help with any scene setup questions.

 

It seems that one basic but super-important topic is completely out of scope, for years, and I cannot understand why: Lightmaps on AssetBundles. Will it finally work with a newer version of Unity?

Will there be some kind of AssetBundle-Explorer/Viewer? I found one from Unity Technologies, made for Unity 5.6, not doing anything in Unity 5.6, completely useless!?

"we've relocated "CPU Usage" to the Edit -> Project Settings -> Graphics." -> There is no such setting, not here, not in any other menu!?

 

Another thing refering to Lightmaps in Unity, from Beast up to Enlighten: When you are nearly finished with your big world setup an start the lighting process what do you do first? You create the "perfect" lightmap atlas for your scene. For this you do not need lighting at all, not even "super fast super low quality". Will Unity 5.6 have a mode where just the atlas is calculated? Within a few seconds instead of waiting 1-5 minutes?

An effect I recognized a few days ago, maybe offtopic in this section: When you layout the atlas with very low settings to get a fast response ("Lightmap Parameters - Default-VeryLowResolution") and you have one finally done (on my current project 4 x 2k lightmaps nearly filled to 100%) you change the settings to highest resolution, go home, and on the next day, you have 5x 2k lightmaps, where lightmap 4 and 5 are filled up to 60% -> ??

 

Will be great if we could put the exact lightmap resolution of a object. I think that must be a problem to calculate the atlas of lightmaps and the reason because we obtain atlas with a lot of free space.

 

So I am also currently in a very similar situation as this poster, and was wondering if there was going to be any plans to implement a directional specular-like systeminto the progessive lightmapper that is fully baked? Are we really going to be forced to always have a realtime light in scene in order to get specularity? Our team has been happy with the results of directional specular (even with its quirks) and losing all of its functionality going forward is a giant regression in visual quality for us.

I've tested out some of the beta progressive lightmapper in 5.6 - but it still lacks the basic functionality of baked directional specular from 5.4 and earlier. I'm currently stuck now at how to proceed, since my team is being forced to upgrade to Unity 5.5 for other bug fixes needed in that version, but if I have to rebake lighting, I will be unable to. Deprecating directional specular in 5.5 but NOT implementing an alternative solution has really been frustrating and a bit of a blocker for our team.

If anyone has additional information, I'd love to hear. Thanks so much.

tl;dr
have VR game, forward rendering, lightmaps - losing directional specular 5.5 and beyond regresses game visually (no baked in spec highlights), no apparent replacement? Help please! Thank you!

 

Unity -- please can we get an answer on this important point? How can we get specular on baked lighting in recent versions of Unity, and 5.6 onward with the new lighting modes? Currently it seems to not be possible.

There are a lot of developers (including myself) literally waiting for a solution on this. When you're trying to create a realistic looking scene in VR that performs well, and using baked lighting... it just doesn't look right of course.

Thanks!

// WildStyle

 

I've been experimenting more with the new light modes today and baking. I have been able to get some fairly decent results for indirect specular by properly setting up my reflection probes.

Ref doc:
https://docs.google.com/document/d/1KbRgmLuBhDsf7RnNrXz1ObOIq8r0-fIialmvqzCfYC4

// WildStyle

 

Here's how things are looking now... baked and mixed (subtractive).



// WildStyle

 

Getting a pretty weird crash in one of my scenes at run-time in builds, works fine in the editor. If I set all my lights to unimportant everything runs fine. If I change one lights 'Render Mode' to be 'Auto' or 'Important' (force pixel) then the build crashes as soon as I turn the player camera to look at the important light.

Basically I'm baking lights mostly and want to have a few stationary (mixed) lights giving real-time shadows, so it's a bit of a show-stopper this issue.

Any idea what could be causing this?

// WildStyle