Unity 5.2.1p2: Realtime lights not working - Occlusion Problem

Edit: Problem still exists

I just upgraded to Unity to 5.2.1p2 from 5.2.1p1 and noticed about 1/2 of my realtime lights weren't working anymore.
Just in case anyone else runs into the issue.

 

Hey I'm having a similar issue with 5.2.1p2, re-doing the occlusion seemed to help with some lights, but any realtime light that has shadows enabled is not working at all. If I disable shadows on those lights, they work just fine. Also, if I disable occlusion culling on our main camera, lights and shadows all work as intended. Tried messing around with related quality settings and nothing is working. This was not happening in previous patch.

 

YES. i just found that the issue is still occuring today.
Case 733005

I uploaded it to dropbox if anyone wants to see for themselfs:
https://www.dropbox.com/s/bbhtmbfrzhhfu25/BugReport-RealtimeLightsOcclusion.zip?dl=0
It's only 2 MB download

To reproduce:
1. Notice the realtimelights are working
2. Bake the occlusion data
3. Suddenly the realtime lights turn off in the editor and player

 

Turning off the shadows also ellimated the problem. So it sounds like we both have the same issue.

 

I also have this problem but I think I'm going back to 5.2.1p1

 

Same issue in 5.2.1p3, ever since p2

 

Same issue here. Turning off Shadows on the problematic Lights or Culling on the camera fixes the issue. Also clearing the Occlusion Culling data fixes it. Can anyone confirm going back to 5.2.1p1 fixes it?

Thanks

 

Unity hasn't even addressed my bug report yet (above). Apparently they aren't responding to OC related bug reports.
I spent 4 hours generating bug report that they don't even respond to.

What really irks me is that bugs keep getting into new patches which are unrelated to anything added to the Unity release notes. If you look at the Unity 5.0+ release, there is nothing in there related to OC changes. This happens over and over again.

 

Shameless bump. Is this related to the things implemented in the 5.3 cycle under the hood perhaps?

 

Can also confirm this issue coming from 5.2.1p1 to 5.2.1p3. Clearing occlusion data fixes it for now, but performance obviously tanks because of this. Looking forward to a solution (or a least a response?), occlusion culling is a pretty major feature in my opinion.

 

Downloading now the 5.2.1p4 patch

EDIT: still not working

 

Still there in 5.2.1p4. We were finally able to update from 5.2.0f3 (subsequent releases broke version control in P4), but now our entire game is pitch black.

Realtime lights and occlusion are common features, and their combination is not some fringe case. How did QA not catch this regression?

 

BTW, has anyone tested if this problem can be worked around by setting lights to mixed mode rather than real time? I highly doubt it, but it might be worth a shot. Even if that works, it would probably be a complete workaround only for projects that use no static lighting at all. But that would work for our projects. If someone tries this, please post!

 

Didn't work for me, but as soon as I changed a light to Mixed it popped up a warning under the Baking property saying that we need to enable Baked GI for Baked or Mixed to work. I guess we don't have Baked GI enabled in this scene, but to be honest I have been letting our artist and LD focus on lighting and don't know much about that whole process.

 

Cool, thanks for the update. The question that comes to mind for me is what percentage of teams are building for the PS3 versus PS4/XB1/PC/Mac. That sounds like a loaded question, but it's not intended to be; I have no idea what the numbers are, and for all I know there are still a large number of last-gen platform teams.

If it's a small number compared to current gen platforms, perhaps someone could reach out to PS3-dependent teams and let them know not to update if it's backed out? Or offer a custom build with Umbra that works for PS3?

That might be more trouble than it's worth, of course, or not feasible. Just a thought in case the # of PS3 teams is significantly smaller than the # of teams affected by this on non-PS3 platforms.

 

Great news! Thanks so much for hopping on this so quickly; it is much appreciated.

 

Yeah Karl, thanks so much! But I am afraid you made a huge classic mistake by demonstrating your effectiveness, as I now have someone's shoulder to tap on directly! muahahaha...

 

Oh yeah, I also wanted to mention-- as far as I can tell, the release notes for the patch where this problem started made no mention of an Umbra update or anything else related to OC. I know it's easy to miss things when putting together release notes, but it would be useful to try to include info about revs to Umbra (and PhysX, etc). It would be an indicator that we may want to pay special attention to stability and perf of that system when evaluating the patch. Even if we are happy with our current patch level, if I see something like a rev to Umbra or Physx, I definitely want to evaluate the patch in case there may be a performance boost to be had!

 

Hi, we also have this issue in 5.2.1 patches 3 and 4, which is a very big deal for us seeing as how we're gearing for a Halloween promotion. Having realtime light shadows in a baked scene seems as though it should be an EXTREMELY high priority.

We were also instructed to update to at least patch 3 in order to resolve another Unity5 bug issue pertaining to resolution. So, here we are, seemingly stuck in a bug loop.

Which version of Unity5 should we revert to in order to have realtime lights/shadows after a bake as well as resolve the resolution issue? When playing in the Editor, Directional lights seem to ignore this bug; all other realtime lights, while working as intended in the Scene view, are completely absent from the Game view unless shadows are turned off. Lighting our scene with only probes is unfortunately not a solution. A very distressing conundrum to say the least, with our deadline looming.

If anyone has a hack solve, we'd love to hear it!

 

Hi Karl,

Thanks for the response. Unfortunately, 5.1 has a resolution bug that affects full screen mode. This bug is resolved 5.2.1p3, which as we know, has the 'realtime lights' bug. So, our current options are to either have a game that works which is lit by probes and lightmaps only, or a game that looks pretty but breaks when changing resolution.

 

Hopefully stories like these will contribute to a change in process at Unity that puts more focus on maintaining the stability of existing features. We were stuck on 5.2.0f3 -- which was incredibly buggy and required constant restarts -- for over 5 weeks because the first patch broke P4 integration and we couldn't upgrade.

The entire 5.2 branch has been unbelievably frustrating; as soon as one critical bug is fixed, another equally bad one crops up. I'm not aware of any 5.2 build or patch that works for our team; right now we are running at a bad framerate due to having to clear occlusion data because our entire game uses lights that no longer work with occlusion. 5.2.2p2 will be the first stable 5.2 build for us ... if it does fix the lighting issues without introducing new critical bugs. We honestly may never update again if we get a known working build, which is a sad state of affairs given that we're still 6 months from shipping.

I'm just hoping that the extreme fragility and instability of 5.2 will lead to meaningful internal changes at Unity. I would much rather have a dependable engine than a steady flow of new features if the constant forward march comes at such a cost to existing games and teams. Obviously new features are going to come, but there's a delicate balance between creating new functionality and preserving what's there, and right now the balance is tipped way too far toward new features.

 

Check out the 5.3 beta forums and poke around for what Alex has to say about this sort of thing. Short version: don't hold your breath. The people with the power to influence decisions like you're hoping for are either oblivious, in complete denial, or have their hands tied (it's impossible to know from outside) regarding how much of a disaster 5.2 has been for people trying to ship large projects.

Hopefully 5.3 turns out better for our other project, but we're stuck with 5.2 for the current one. To be completely fair though, we really shouldn't be trying to use an engine rev that was released just 2-3 months before we need to enter cert. That's pretty crazy, but it was a judgment call based on risk comparisons: we needed 5.2's fixed function shader support because we have a lot of fixed function legacy shaders and I had no idea how long it would take me to learn enough about shaders to write them properly. (That aspect of 5.2 works really well, by the way!)

 

We'd be happy with realtime lighting. Which I thought was pretty standard since... roughly over a decade ago? We have a zombie game that can't even use flashlights anymore, and our biggest promotion day of the year, Halloween, is next week. Yay!

 

I see it in the release notes, but I'm sorry to say it's still not working... I already tried clearing and rebaking the Occlusion, even tried emptying out the Library/Occlusion folder myself since it keeps old files around - but nope. The only difference with this release is that 1 of the shadow casting realtime lights that are missing sometimes flickers into existance when I look around, while all the others stay missing.

EDIT: If you follow the link to the issue tracker it says "Status: Fixed in Unity 5.2.3" - is it actually next week and someone left this in the notes by error?

 

I just updated to 5.2.2p2 and still see the issue as well. Had several other engineers verify that they also saw it. I also tried clearing my occlusion and rebaking with no luck. Please reopen the issue.

 

How can 5.2 consistently be this unstable, and how can the internal process for verifying fixes be just as broken? 5.2 was release over 7 weeks ago and there is still literally not a single 5.2 build or patch release we can use without major, game-breaking issues.

 

Tried the project and it seems to be working, but when I added other lights everything broke.

Added some spotlights and it broke, as soon as I cleared the data lights came back

 

Just tried 5.2.2p2 with a completely clean reimport. Realtime lights are still broken with occlusion culling (some lights are OK, most are not).Looks like we're not going to be hitting our holiday release.

I don't really know what to say at this point. What's the use?

 

I made my own repro for you by trimming down from my own project, it's still a bit large but I hope it will serve the purpose. After some initial trouble to send it, the Case Number is 740988

 

Reported with projects files, case number is 740977

 

This is a pretty classic case (which mostly afflicts inexperienced engineers) of, "well, it worked in my test level!" where only a small subset of conditions are tested by the person fixing it. Sure, the fix might cover some of the problem conditions (i.e. the ones exposed in the test level), but unless part of the process is to test fixes in production levels, there is no way to be sure they have all been caught.

The missing piece here is testing in production levels, because Unity only wants bug reports in a small test level. Actually, the piece isn't missing, the piece happens when the patch is released and then customers get to do the QA in production levels.

I don't think this problem will go away unless the "test in production levels" step can happen before an update is released to the public. I know small test projects are convenient, especially to jump start initial work on a bug, but it seems like there also needs to be a formal way to incorporate testing of bug fixes in actual production projects before the fixes are released in patch.

If Unity were more agile, it wouldn't be such a problem. For example, now that we know this fix is not comprehensive, if it could be prioritized and a "hot fix" released within days that addressed only this one issue (frankly, what should have been done when it was originally broken), it wouldn't be a problem. But now that the fix has failed, given what appears to be the current lead time from a bug being reported to it being fixed and released in an update, it will be weeks, if not months.

 

This is exactly why I make all of my bug reports public and upload it to Dropbox for EVERYONE to see.
Had I not done this, I would have downloaded the Unity patch, only to find out, like everyone else, that something is still broken. Then I would have to spend more time submitting a bug report again.

What I'm not understanding here, is how the fix could work for the existing lights in the repro, but yet when you add additional lights, the problem occurs again. I've been sitting here for 30 minutes trying to imagine how that can happen. The only conclusion I can draw is that someone didn't take the time to see the larger picture of the bug report, and the fix was done just to handle that particular situation. There is an interesting thread here which explains this issue:
http://forum.unity3d.com/threads/please-unity-slow-down.361090/

 

In my experience, this is actually quite a common pattern with inexperienced engineers. It just takes a while of mentoring and monitoring, teaching them to take some initiative and think comprehensively (and preemptively) when addressing bugs, rather than focusing narrowly on just what's laid out in front of them. I have to imagine that at the rate Unity is growing, there is a lot of mentoring going on right now.

 

Ahh... look at me.. thinking I was going to finally be able to leave behind 5.1..

As the others said, lights don't work with Occlusion Culling enabled.
I wish there were 'nightly' builds or hot-fixes available instead of having to wait > 1 week for another try at "let's see if the new Unity build is usable in production'". Each time a new build fixes a major issue it creates a new one.

 

Thanks for the update, Karl. Given this info:

• Our project is currently on 5.2.1p1.
• 5.2.1p1 (and its predecessor 5.2.1f1) is unstable, with frequent crashes in the GfxDeviceWorker system.
• Support threads have indicated upgrading to newer releases in the 5.2.1 and 5.2.2 line could alleviate crash problems, due to fixes in that system as well as memory handling.
• We are unable to perform such upgrades as all 5.2 releases after 5.2.1p1 have broken realtime lights when occlusion culling is used: our project is 100% realtime lights and requires occlusion culling for shippable frame rate.
• We need to enter cert for PS4/XB1 by the end of November, for a holiday release.

Nevermind any frustration, it's irrelevant at this point and I am beyond that. What I need is concrete advisement for how to proceed, given the above info and the status update you just provided.

How do we go about shipping our project? Do we need to downgrade to a different version of Unity? If so, what would be the specific recommended version, given we are currently on 5.2.1p1? If we need to downgrade, will there be any problems with assets that have been created or modified using 5.2.*?

Or will the backported fix be available in 5.2 within the next week or two, and we should hold steady at 5.2.1p1 and plan to be able to upgrade in time to have a couple weeks of stability testing before entering cert?

Or are we advised to notify our publisher that the current time frame is not feasible, and they need to wait an unknown amount of time for 5.2 (or 5.3) to be stable enough for our game to enter cert?

Please help! The period of just trying to make good general decisions and letting that guide things in the right direction is passed for this project. We need very specific advisement regarding this issue.

 

FYI to anyone following this topic: Karl and Richard are 100% on top of this, we're working on testing it offline, and hopefully the results of that will mean this will be fixed for real (in 5.2) asap!

Oh, and did I mention that Karl and Richard are fantastic and that even though we pesky customers can be annoying when frustrated, all their support on these forums is very much appreciated? If not, well, I just did!

 

Is there an ETA? This week's patch? Next week's?

 

Ok, thanks Karl

 

thanks karl for your information