Umbra Occlusion culling occure stuttering in built result.

In my scene , There is one directional light . It has shadow map.

I would like to object ( out of camera ) be removed from the shadow map.
But After Baking Occlusion Culling , executable application occure stuttering frame.
In Editor mode , there was no problem even baking occlusion culling.

Is it interop problem? or Umbra problem ? or How can fix it?

It’s not a known issue afaik at unity, so please report this as a bug with attached example scene, thanks!

Do you think they would really be interested in it ?
Except that they do not have any interest in selling thier toolset.
I regret to use Unity for my project.
I reported many bugs in the past, But never answered.

if there is no example scene attached they can’t do much.

In my experience the QA is pretty efficient. If you submit a bug with clear steps to reproduce and a scene you can be sure it will reach the devs.

On a related note though, on beta 18 umbra seems to be very broken (I’m getting VERY unpredictable results).

FWIW my experience with bug cases being looked at has been mixed. IMHO Unity’s approach to deciding which bugs to look at is flawed (see FogBugz feedback loop on reported bugs? - Unity Engine - Unity Discussions), but no harm in submitting a decent bug report. If you don’t your chance of having the issue looked at is very low (near zero), if you do submit a bug report your chance of having the issue looked at is a lot better.

I appreciate your feeling on this but Unity’s QA is pretty great, but ultimately you don’t really understand the magnitude of the task Unity has. Not only does it have a million users, many of which bombard the bug report tool with red herrings (so unity cannot always respond) but also they do not respond to bug reports without a repro (although this data is often used to track down issues, so isn’t a waste).

Having a decent reproduction scene will 9 times out of 10 get a bug fixed. In some cases, a bug cannot be fixed because it relies on a number of other issues which also affect it. So that bug could also be the result of other bugs, and will get fixed when the other bugs get fixed.

So put that across all the platforms Unity supports and you have outstanding QA when you put it into context…

I looked at your other thread and most of these were issues where the work is ongoing and the issues are known (such is the way of beta), so you can’t hurry these bugs up to get fixed :slight_smile: I think what you are looking for is a clear answer from the QA team and that might be tough with a thousand reports a week.

Just don’t feel disheartened about it and carry on reporting, you have no idea how much they do appreciate it. It must be frustrating for them to not be able to reply to each and every bug report also.

It would be really cool if we could check if a bug was already reported though. It would potentially lessen their workload as well.

No, it’s necessary for them to have multiple bug reports. Each report shows different hardware/os configurations and gives them more clues than a single report.

Multiple reports can also indicate a severity of an issue, maybe they can’t reproduce it, so when 10 reports come in they know it’s something really happening and not just user error (as is often the case).

Lots of reasons for more bug reports.

1 Like

To be clear here, my comment was not deriding the capabilities of Unity QA. Trust me, I understand the combinatorial complexity of the testing they have to accomplish. It’s IMMENSE. My comment was merely that they are drinking through a straw from a firehose. There’s is so much more external data coming in than they can realistically process. And I would suspect that not all of it is quality data. And as stated the current approach to handling this data via FogBugz is flawed IMHO. Unity QA would agree I think and I suspect they are working to improve the external bug reporting workflow and toolset. There’s always room for improvement.