We’ve been working on fixing the issues around mixed lighting for a while now and think that we’ve reached a point where we can share a build with the community. With this build we are also adding a revised Lighting window, which includes a lighting lister we call the Light Explorer.
Overview
Goals of this experimental build:
Fix what’s referred to as “mixed mode” approaches to lighting (baked lightmaps + realtime shadows/lighting).
Offer long range baked shadows support.
Offer a set of well-defined lighting solutions targeting different use cases and hardware.
Improve lighting authoring.
Key details:
Dynamic lights remain unchanged, two modes for these exist in the Lighting window.
Mixed mode lights are now named “Static”. Five light modes are being offered for them, see the new Lighting window for options to globally pick one.
Baked lights are unchanged and now called “static cheap lights”, this is a single mode by definition.
How to get the beta builds
These builds are based off of 5.4.0f3 - the release version of Unity 5.4. However they are EXPERIMENTAL builds so we do not recommend you use them in production.
Please read the Documentation on these features in PDF form which you can download from the link below:
Feedback
The type of feedback that we’re looking for:
Do the modes provided cover your lighting needs, or are we still missing something?
How is the usability of the new lighting window? Does everything work?
Is there any important information missing in the UI?
Is there anything else that’s broken?
Known Issues
We have some known issues and parts of the UI that are work in progress. Note that we will do our best to update this part of the post as you report stuff to us! -
Runtime/Tools
In some light modes gamma color space mode looks broken.
→ Please test in linear color space for now
Standard shader: Exceeded allowed instruction count in shader model 2.0.
“Directional Specular” lightmap mode is broken.
Visual disparity of normal maps between modes
Using subtractive with high intensity lights produces some weird artifacts
UI
Lighting Explorer: We should not be able to set Area lights to dynamic.
Lighting Explorer: GUI performance is bad whenever a lot of lights are used (temporary workaround: close the Lighting Explorer while in Play Mode).
Mac : Font size issue on retina display
Subtractive mode : Only one directional light should be in the Scene and it should be static → display a warning when this is not the case.
We are looking forward to your feedback and appreciate your help!
Calling lights static and static cheap is a bit confusing, would be nice to have something similar to unreal terminology, where “static” is fully baked, and a light that allows shadow blending is “stationary”.
Point light masked soft shadow was strongly pixelated.
IF shadowmask is limited, say, to only 4 lights for any given point in scene (it appears to be), there should be some sort of visual warning in situation when a light couldn’t be baked into shadowmask.
I’m going to cautiously say that this is (so far) excellent. I’ve popped together a quick scene to test one of the two situations that I’ve been unable to do until now; that of distant baked lighting/shadows and close-up realtime lighting/shadows. No issues located!
Baking lighting is still painfully slow, even at 1 texel/unit, final gather off, compression off, ambient occlusion off, and baked GI 1/unit - any clues as to speeding this up for test rendering would be greatly appreciated!
I’m going to have a look at the second commonly used layout in a while - that of a high-quality baked scene with a handful of dynamic actors in it. I need to wait for this bake to finish first tho!
Also, it appears that you broke one of the Legacy shaders :
Shader error in ‘Legacy Shaders/Transparent/Bumped Specular’: invalid subscript ‘_ShadowCoord’ at line 102 (on d3d11)
Compiling Vertex program with SPOT FOG_EXP2
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING
For fast global previews only, i use 0.5 or less for the texel/unit and similar number for indirect resolution, this can speed up your lightmapping somewhat.
I am actually impressed with how comprehensive the list of modes is. Awesome.
It seems to be. I will admit that on first glance, the lighting → settings window is a bit overwhelming with all the descriptions, but I got used to is quick enough. My only “real” complaint, is the lighting explorer demands too much width and the fields don’t scale, while it doesn’t need to.
The other complaint is as @neginfinity said, static cheap is an awkward term. Maybe change it to Fully Baked, which is what it is.
EDIT: Also, for what is worth, I approve of the removal of the lightning → Object tab and everything being moved in the mesh renderer component.
I see that’s in the known issues list but… Please fix the gamma issues. The way things are set up right now it’s even more obvious than before.
I think “baked”, “dynamic” and “masked” would work for lights would work I think.
I’m concerned about limits of masked lights, though. It looks like their masks are stored as one light per channel in shadow mask texture, but that texture can only have 4 channel max. So it is unclear what happens when number of lights goes above this limit. I assume that they’re silently switched to dynamic or something like that. Would be nice to have some visual warning when this happens.
I think fallback to baked is not a good idea, because it will not produce desired result, and it will be easy to miss the issue. It should either fallback to dynamic, or fallback type should be configurable.
Also, it would be nice to have obvious indication that light couldn’t be baked properly. Different light icon with a warning sign, for example.
That’s not enough. I think it should be instantly visible in scene view even in default lighting mode. Basically, see how it works with Unreal’s stationary lights.
If you have to switch display modes to check for the problem, then one day you’ll forget to switch and miss the problem.
Fair enough. An indicator that something didn’t go as planned would be useful in the scene view as well. It could also be marked in the lighting explorer somehow.
But the existence of “Show Shadow Mask overlap” mode makes the feature usable, at the very least.
I was thinking about our use cases here, basically we have time of day. So I’m thinking that a shadow mask, or the shadow can update in a staggered performant manner?
As we have TOD, the idea is that we use dynamic regularly updated shadows close to view, but in the distance, it updates very slowly. Perhaps I should forget mixing things like this and instead just optimise as hard as I can in merging geo for normal realtime shadows to be cheaper further out.
Any thoughts regarding this scenario being optimised are very welcome.
sorry if i missed this from known issues,
is lightprobe display are broken, i mean i can’t see any baked/result of the lightprobe?
Edit : My bad, i didn’t notice the lightprobe viz settings in the bottom
The occlusion lightprobe for deferred mode is tricky, is there any plan to improve this? the way it behave in forward path are perfect though, just need to get the same behaviour in deferred
I think that if you want time of day you shouldn’t use baked lights.
Completely unrelated to this topic, we have work going on to expose more of the high level renderer controls to C#. With this you could for example update the shadow cascades for far away objects at a lower frequency than the one up close.
So the right solution imo would be: enlighten + future features giving control over updating shadows incrementally.
So basically i don’t think this use case part of what we are trying to solve with this build specifically.
“I think “baked”, “dynamic” and “masked” would work for lights would work I think.”
"Calling lights static and static cheap is a bit confusing, would be nice to have something similar to unreal terminology, where “static” is fully baked, and a light that allows shadow blending is “stationary”.
So in regards to naming the basic idea is that static cheap really discourages using it, which is what the goal of the name was. Static cheap is something I believe has very few use cases. For almost all modes you would always use either dynamic or static. Static cheap is the fastest to render but also means that your lights completely lose all specular high-lights & the light color / falloff is much less crisp.
The only use case i can imagine is for areas where you have lots of lights in an area and some of them you deem very unimportant. Or very far away geometry that only affect surfaces with very little specularity.
So we are looking for a name that is accurate but discourages clicking on it as a “default”.
And I did read the manual n’ all… (well, maybe skimmed is more accurate)