SERIOUS Problem with Occlusion Culling in Unity 2017.3.0b9

Nonstatic skinned character meshes show up as invisible, some dynamic objects are invisible under occlusion culling. Turning off occlusion culling on the camera solves the issue, but for an indoor map, not having occlusion culling is unacceptable. What is going on??? As you can see, the camera simply won't render the models and the cube even though they are supposed to be visible in the occlusion culling visualization. I've only noticed this jumping from 2017.3.0b7 to 2017.3.0b9


https://imgur.com/a/4rtNd

 

UPDATE: Further testing has determined this bug was introduced since beta 8, around the time the Unity Team tried to "fix" another occlusion culling glitch regarding matrices and near clip planes. According to the community here, as of beta 9 that issue remains unfixed, and here it has caused a new never before seen bug to happen...

This bug does not happen in beta 7, but crashes on Vulkan API make beta 7 unusable. The Stable 2017.2 version is unusable due to Content Size Fitter performance issues in UGUI. I will begin the long and time consuming test of stepping back through betas 6 and 5...

My project is 40GB in size, and I really don't have the time to prepare a sample for the Issue Tracker, and I doubt it will be reproducable anyways. I have seen no replies to this thread, implying I am the only one who has run into such an obscure set of circumstances which will probably not affect anyone else in their game development, since everyone else attempting a AAA 3D game with all of these performance enhancing tricks probably all used Unreal or are not indie developers and have their own in-house engine to work with....

This is becoming a recurring theme lately in the past few versions. 2017 promised shadowmasks and greatly enhanced performance tricks to render fancy open world terrain even on low end hardware. Bake GI with shadowmasks they said. It will look just as good as realtime GI with a fraction of the lag they said. Yeah right... and in exchange I've had to deal with.. .a UGUI system that lags to 8 FPS.... Fleeing to beta 7 gives a crash on Vulkan API. Fleeing to beta nine gives invisible character models when occlusion culling is turned off on indoor maps... I COULD turn off occlusion culling. I mean sure why not, right? 15 FPS lag spikes is no big deal right? Yeah great idea, guys! Who needs occlusion culling anyways! /sarcasm

 

*edit (because it won't let me edit my own post???) "Fleeing to beta nine gives invisible character models when occlusion culling is turned off on indoor maps... I COULD turn off occlusion culling."

should be "Fleeing to beta nine gives invisible character models UNLESS occlusion culling is turned off on indoor maps... I COULD turn off occlusion culling."

I'm curious, is everyone else mostly fine with Unity the way it is? I hardly see any cautionary threads or warnings, so I upgrade thinking all will be well, but lately.... is Unity even meant to be able to handle an almost AAA level of polish in the games, or did I mess up real bad continuing to stick to an easy newbie engine? The major reason for still staying with this game engine is one I have a workflow in place for fancy 3D models that are more or less free, and two, mecanim means I don't have to hire animators or spend that much time animating each individual model when I can just drag and drop a set of animations flawlessly between characters of differing heights and such....

It's considered bad form to rant like this, I know, but this is all too much. When the very engine upon which you stand doesn't have your back... then really what chance is there???

 

It's a beta. You're doing good testing. Would you rather this bug was in the actual release?

Unity's the best engine.

 

Not really a helpful comment..

Did you make sure you didn't accidentally put these objects on a layer that isnt rendered by the camera?

 

You should be able to edit your own post in the forums.

It definietly is capable of high quality games and at least decent sized games. The problems you describe have nothing to do with any of that and are individual issues. I actually work with 2017.2 mostly right now and don't have any problems with the UI.

First thing I suggest is not to use any Beta version for your game that size or at least not for the core development verison. Also I hope that you made backups because going back and forth with your project on different versions of Unity can really break something at some point.

As @PhilippG has pointed out, is it actually the OcclusionCulling? Because it should be culled in EditorView already and have you tried rebaking Occlusion? Because again after version change that might be necessary as well.

I can relate that big projects break at some point if you switch to a new Unity version, but that can also be the case with Unreal. Therefore make a backup, update and see if anything works. This is more of a workflow thing rather than specific for Unity, even professionals have to do that. At some point your only chance is to go back a few iterations and try again. This is why SVN or Git are even helpful for individual developers.

Also this is increasingly hard for big sized projects and this is why at some point you have to split your project and make use of AssetBundles for instance which are managed on another project.

 

It's pretty helpful.

 

As I've said, I've changed nothing in the occlusion culling setup of the map from Unity 2017.3 beta 7 to beta 9. downgrading to beta 7 fixes the issue. Beta 8 - 10 all have the disappearing models issue. I have tried rebaking occlusion with all range of settings.

The reason I moved onto beta was as I've said before in the wall of text that probably didn't get read 100%, the stable 2017.2 has a frame lag issue with UGUI's Content Size Fitter component. The beta versions have fixed that issue, but introduced the inability to compile on Vulkan and in the later betas, completely unusable occlusion culling.

It's inconceivable that I would not know what I'm doing with occlusion culling, considering I've been at this for years and I've never had a problem with it until now. The only things I've had trouble with were frame lag. I've been working for years with all manner of tricks just to get the game running on old hardware at 30 fps. It runs perfectly fine on modern hardware of course.

For now I will settle with beta 7. I really only wanted Vulkan support for its one size fits all deal with Mac and Linux (supposedly) and its promises of utilizing the GPU more efficiently, but if it doesn't work, oh well. I guess DX12 and DX11 work just fine....

Also, I strongly believe the issue is tied to the new "fixes" in the occlusion culling oblique matrix (w/e the hell that is) behavior with near clip planes. (What?????)

Beta 8 was the first one to touch occlusion culling and starting in beta 8 was when I saw that issue. Those who haven't run into issues from 2017.2, I'm not really sure what to make of that. Either you all are extremely fortunate, or you all make simple texture and environment 3D games that don't stress the engine and the hardware.

I wouldn't THINK a 3D anime art style game with a wannabe CryEngine / Unreal look to it would be that much of a hassle, but apparently it is....

 

https://imgur.com/a/UwHLn

As you all can see, in beta 6 (and in beta 7) everything looks as it should and everything acts normally. from beta 8 onwards, both the girls in those pictures are invisible to the camera when occlusion culling is turned on. Nothing in the scene configuration has changed at all. Plus, I would never be stuck on such an elementary mistake as the wrong layer. I have two camera setups, UI camera only sees UI layer and other camera sees the rest. The combat backend only procs the Actors layer for example. The playmaker AI "canseeobject" only analyzes default layer and Actors layer.

And I of course always rebake when switching versions. I'm not usually the type to ask for help either. I only knew about the content size fitter issue in Unity 2017 after experimenting with the UI canvas setup and disabling components to see which one lagged. If it really was so simple I would have fixed it by now. But just as surely as Vulkan crashing in standalone was a thing until beta 8, so too is this occlusion culling glitch.

I have made sure it's not a shader issue. the cube in the first picture had a unity standard shader.

[Stardog said: ↑
It's a beta. You're doing good testing. Would you rather this bug was in the actual release?

Unity's the best engine.]
Well as it stands, many bugs DO make it into the actual release. The content size fitter issue in unity 2017.2 for example. Which is to be fixed in 2017.3, of which one of the patch notes said they had to revert to the 2017.1 backend. A great leap forward, 10000 li backward.

Not to mention the new video system that was supposed to replace the old movietexture system for ingame TVs and movies (like in Alan Wake, Grand Theft Auto, etc etc). It does no good to have a fancy new video texture system when the audio is choppy and out of sync. It's back to converting to oggtheora.

If you're very curious I can make a video showing the fail of the video system (unless it's been fixed already. Its been so long and I've reverted back to the old MovieTexture method). It's not that important at this stage in this game so I havent raised the issue yet, but starting in the unity 5 cycle, quality seems to have dropped dramatically, and I see its only gotten worse.

When I first started out in Unity many moons ago, it obviously was not like this.

P.S. Pay no attention to the 43 FPS. It was 60 FPS before I added code to the inventory window. I will have to fix that, but it WAS 60FPS before.

 

My only problem is when basic things break, such as selecting objects, reflection probes being pink, unable to F2 to rename objects, etc. Occlusion Culling would count as a "basic". Before they do a major release, they should do a last minute check of all these basic features first. For everything else, I don't see what else they can do other than do a lot of betas like they are.

 

If you made sure there are no other things involved, you're very likely right. I'm just trying to help.

You're probably right about that, they changed a lot on the occlusion culling system in 2017.3.0b8, I guess it was a bunch of things they tried to fix in one go. Here is the culling related excerpt from the changelogs:

• Graphics: Cull projectors correctly to match Editor scene cameras to fix i.e. Preview of a material color is changed to the color of the material used on a Projector (954828)
• Graphics: Fixed incorrect calculation of the Umbra occlusion culling near plane from the camera settings. (840098)
• Graphics: MeshRenderes with disabled "Dynamic Occluded" property were not being frustum culled. (956887)

I'm also involved in the oblique culling matrix issue, having major interest in having this fixed, as this is also still not working correctly in 2017.3.0b
I'd really like to encourage you to write a bug report with sample to reproduce. I know its tedious, but seeing that more things still don't work as expected by now or got worse, this gives me hope the devs will iterate once more.

 

This is 100% the issue I'm seeing in this thread on b10: https://forum.unity.com/threads/any...on-for-dynamic-occludees.505831/#post-3297850

I am out right now and can't upload a repro case for a few days, but The House asset on the asset store, which I linked from the other thread, demonstrates the problem.

To those complaining in this thread: this is a beta, we're getting releases fast and hot because we're the guinea pigs. You can only automate testing so much. This is why the non-beta releases are so much cleaner now. It says all this on the tin when you go to the beta download page.

 

Nope it does not. But I am relieved to see it has been reproduced at least. Forgot to mnention that, but that is one of the things I've tried.

 

Oh I would love to share your sentiment, but content size fitter performance issues in the *stable* release of 2017.2 with news that it will only be fixed in 2017.3 necessitated a migration.

I've had alot of feedback from my team about the game not being viable and extremely resource intensive on the majority of PC platforms (which basically spells doom on mobile and switch platforms), but we could not keep the old UI system due to unacceptable tradeoffs between text readability and UI screen sizing. (It used NGUI instead of UGUI Canvases. Very old system.)

The non beta releases used to be cleaner actually and I at least have noticed a reverse trend from what you described, hence my dismay....

 

@phil-lira: Wonderful that you can reproduce it! I'll be curious to know what it was if you don't mind sharing, once you hunt it down. Might make it easier for us to watch for any sort of recurrence. I'm guessing something in the frustum matrix calculation?

@Spiral-Organ: I hear ya. I started using Unity around version 2.6 or so, and things were great until a huge upheaval around 4.0. Things were slow, though. Then after that things were both slow and uneven, and eventually they started doing patch releases, thank goodness. I stayed on 4.4 for years because it worked for my purposes and the new GUI system didn't seem stable. Then 5.x came out and was a huge mess for a while, and we finally made the jump over to something like 5.4 or 5.6. It's felt like pretty smooth sailing from then on, but I had a bad feeling about 2017.2 and didn't need the features in it, so stuck with 2017.1 and its patch versions until deciding to move my latest project over to 2017.3 beta because I thought it would be a good fit. I've shipped about a dozen games on Steam since 2009, but most of them we used unity in as "bare bones" a fashion at all -- no GameObjects, no occlusion culling, one scene only, no GI, etc. Not even dynamic or static batching, instead a custom batching solution I made myself using raw DrawMesh calls. And only using GUI for the textboxes, which are a pain to replicate manually; beyond that we rolled our own code for most everything. The cross-compatibility between OSes, and the shader pipeline, were the reasons for us using unity. It's basically been in the last two years that I've fallen in love with using unity "the right way," but I haven't shipped a full product using it that way yet. Soon!

Anyhow, I guess I just treat this like I do Microsoft Windows upgrades or Apple iOS upgrades: expect insane bugs on major new versions, and don't upgrade core systems to them until other people have fallen on the pikes and reported no substantial ongoing losses. Then follow, and wait until you need to repeat. Every new iOS version is a clusterbomb of badness for a while. Etc. I figure that's just the way of it with sufficiently complex software meant to cater to a sufficiently wide array of hardware. Hopefully it sounds like your 2017.3 woes will be behind you pretty soon, and then maybe you can just stick with this version for a while until there's a compelling reason to move to 2018.whatever AND it looks battle-tested. In the meantime I'm in love with the new patch cycle they have out, since during that waiting period for the new big build version to stabilize, you're still able to get updates, etc.

 

Unity must have an insane amount of automated tests by now.

 

Awesome, thank you for the fix there!

I think that this behavior is probably related, and caused by the same thing:
1. Turn off occlusion on the camera.
2. Observe that some (maybe all?) skinned mesh renderers are now invisible from that camera regardless of whether dynamic occlusion is on or not.

I'll re-test in the new version when that comes out, but I'm guessing it's all the same thing at this point.

 

@phil_lira: I notice that b11 just came out, but the fix you mentioned wasn't in the release notes. Out of what is mentioned, that's my main incentive to upgrade to b11, or else I'll probably just wait for b12 and save myself some project-upgrade time. Can you confirm what the plan is with that fix, if it's known? I don't mean to be pushy, and it's not urgent for me, I'm just trying to plan.

 

Thanks for the update!

 

I just upgraded a project from 5.6.3p1 to 2017.2.0p3 and am seeing this issue (I'm using this specific version as it is required on the platform I am developing for). Disabling "Dynamic Occluded" on the mesh renderers does not fix the issue. Disabling occlusion culling on my cameras does fix it, as well as deleting the occlusion data from the scene.

However, oddly, if I go through my hierarchy while playing in the editor and disable mesh renderers (either the component or by disabling the game object), seemingly random *other* mesh renderers will get turned on/off (sometimes missing renderers become visible by disabling some other mesh renderer in the scene).

Additionally, I have a first-person character that has some renderers set to render 'shadow only', with proxy meshes so that the player doesn't see them with the camera but they will render a shadow - and these meshes will sometimes render (while performing the above actions) in the camera.

Of course, I was having no issues with 5.6.3p1

 

Hi phil_lira,

will the fix also fix the issue with layers? I've noticed that cameras that use layers to hide certain objects, will have those objects rendered in 2017.2.0p3 with occlusion culling enabled (again, disabling occlusion culling fixes this issue as well).

Thanks for jumping on this!

 

I am registering this issue on 2017.2.0p3 too

 

Soo... 2017.3.0f1 just came out, and I don't see any mention of this or other important issues that were recently fixed in the diffs section. However, the diffs say that it is since 2017.3.0f0, which isn't a public release that I can tell. Is there some way to see the diffs between b11 and 2017.3.0f0? Or is 2017.3.0f0 just another name for b11?

Thanks!

 

Thanks for the update!

 

Confirmed still exists on 2017.2.p4.

 

Good work @phil_lira thanks for getting on top of this. any idea how long for 2017.3f2? this issue is killing me right now.. I have a release in 2 weeks, and I can't do it without this fix (I needed some of the features of 2017.3, and can't go back now).

Thanks again!

 

Hi @phil_lira - sorry for pinging again, but tomorrow is Friday and I'm just wondering if there is any patch in sight for 2017.2?

Thanks again for looking into this.

 

For anyone waiting on beta fix:

2017.3.0f2 - "Graphics: Fixed Occlusion culling regression that was causing objects to be incorrectly culled. (972075)"

 

Was very excited to see it. Got it downloaded, and so far so good!

 

Any timeline for a non-beta patch?

Thanks again!

 

I see that 2017.2.1f1 was released, but the patch notes mention this:

"Graphics: Fixed incorrect calculation of the Umbra occlusion culling near plane from the camera settings"

But, I don't think that's the bug, as the other patch notes don't match.

I don't suppose anyone can verify if this version has the fix?

Thanks!

 

I could not reproduce the problem on 2017.2.1f1. Seems to be fixed!

 

the fix seems to be in 2017.2.1f1, which is supported on my platform so I'm going forward with that.

Thanks again for jumping on this!

 

We have a lot of performance overhead for culling (1.5ms~) in our scene, I don't think it's occlusion culling; but does anyone here know if there's a way to disable culling entirely? It's pretty large amount of our 10ms cpu budget and our scene is always all in view so it's a complete waste of time for us (on android, not as much on PC obviously).

 

Unfortunately there's no way to disable frustum culling, which is probably the culprit for you. If you've disabled occlusion culling on the camera, that's all you can do. With the new scriptable pipelines coming up, one of the things I've been very excited about is the possibility to get rid of the unity concept of frustum culling; there are a lot of cases where that can be shortcutted by game logic to save time, but there's no mechanism to do that yet.

 

I got scriptable render pipelines up and running to try exactly that - but the API gives you a list of renderers via the CullResults query, there doesn't seem to be a way to skip the frustum culling even in SRP. Unity halp!

 

That... is an enormous bummer. I hope that's something that changes as the SRP matures, because I've seen on a variety of forum posts and unity answers questions over the years that people really want this. Right now the only way to avoid frustum culling that I know of is to use DrawMeshNow and equivalent, but those have many other drawbacks performance-wise.