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…
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:
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.
@Spiral-Organ That is probably an issue introduced by the Dynamic Occluded property.
I’ll look into it.
Meanwhile, if you select your skinned mesh renderer and disable “dynamic occluded” property. Does that make the character show up?
I’ve tried to reproduce this locally but couldn’t. It will really help if you can share a repro scene.
This is 100% the issue I’m seeing in this thread on b10: Any known issues with occlusion for dynamic occludees? - Unity Engine - Unity Discussions
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.
Thanks guys. We managed to reproduce and we are working on a solutions at the moment.
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…
@ -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.
Alright guys. I’ve got a fix for it. We will do some more QA on it but the fix should be available soon.
@x4000 The way occlusion culling behaves is that if you have occlusion baked then both static and dynamic objects test against the occlusion buffer and before there was no way to tell a dynamic renderer to skip occlusion test. Say, you want to render the outline of a character behind a wall which is done in some shooter games, you don’t want to cull that character. We added the DynamicOccluded property to allow devs to tell Unity to not test occlusion culling against dynamic renderers based on the DynamicOccluded property, by default it is on, meaning perform occlusion culling on this renderer. The issue you were seeing was caused because we split the dynamic renderers into two lists, one that will perform culling against the occlusion buffer and other that will do only frustum and layer culling tests. There was an offset miscalculation in the culling job while computing these indices. Sadly, this issue was not caught by our automated tests database.
Unity must have an insane amount of automated tests by now.
