MirrorReflection4 has odd shadow culling issues, is there a workaround?

So I am playing around with reflections using https://wiki.unity3d.com/index.php/MirrorReflection4 and I already did the following changes: reflectionCamera.useOcclusionCulling = false; on the reflection camera right after its creation, and the following right before its .Render() call:

Code (csharp):

1.  
2.         reflectionCamera.ResetCullingMatrix();
3.         reflectionCamera.cullingMatrix = (  // disable frustrum culling
4.             Matrix4x4.Ortho(-99999, 99999, -99999, 99999, 0.001f, 99999) *
5.             Matrix4x4.Translate(Vector3.forward * -99999 / 2f) *
6.             reflectionCamera.worldToCameraMatrix
7.         );
8.  

... which is from https://answers.unity.com/questions...lling.html?childToView=1406013#answer-1406013 to disable frustrum culling.

To my understanding these two changes should disable any kind of culling on the reflection camera, yet this happens:

Direct video link: streamable.com/nh1ib6

(Observe shadow below the cabinet in bottom left, the video was recorded looking at a MirrorReflection4 mirror pane.)

Does anyone have an idea why this glitch with the disappearing shadow happens, and if it can be avoided?

 

By the way, I noticed reflectionCamera.useOcclusionCulling = false; tanks performance so hard I basically moved engines for now - because without it, random nonsense is clipped away in all mirrors because apparently either the mirror script or Unity's occlusion culling in regards to it are completely broken. I've seen mentions of this from a decade ago, will this ever be fixed? The amount of bugs in Unity on such basic things is really staggering. One would think basic non-raytraced reflections would work in 2021.

 

Bug is here: https://issuetracker.unity3d.com/is...rs-if-occlusion-culling-is-baked-in-the-scene (9 years old!)

Forum thread is here: https://forum.unity.com/threads/water-reflections-occlusion-culling.322379/

Edit: also see the comments that clearly state that 1. no this is not fixed (and it really isn't), and 2. the workaround is to disable culling but this completely ruins performance if any mirror is in the view since - as you would expect - the entire scene is then rendered without culling in the mirror. This is not an acceptable workaround at all and will turn most non-trivial games simply unplayable, since culling is usually enabled for a reason.

 

Because the bug wasn't ever fixed, it should be reopened.

The bug description says nothing of a crash, it describes exactly the problem with wrong culling in reflections that wasn't fixed. Also see the tons of comments from as recent as 2020 that state later versions than the one claimed as fixed still exhibiting the problem, just read the comments. It's not just me. I therefore suggest you reopen the bug report.

Well, there are all the comments agreeing it's not fixed on the closed one i linked

 

I currently use the disk space I had available for Unity for another engine. Unless this bug is fixed I'm not switching back. Also I don't really understand how just clicking the reopen button on something reported by so many people as clearly not fixed (see comments on the issue) is such a roadblock anyway. So you are correct, at this point I don't want to file a bug report since it's not very practical to me. (Unless there is a way to do so without reinstalling Unity, but I'm not aware of any.)

 

I don't think there is a bug here.

Planar reflection happens by spawning another camera and rendering the scene again a second time from weird locations (typically symmetrical to the plane of reflections, so it ends up within the ground).

If you use occlusion culling with that extra camera, which is rendering from invalid positions, results might be a bit unpredictable. (I mean, what do you expect occlusion to culling to do?).

The solutions are: Don't use occlusion culling for the reflection camera, or, tailor the occlusion with the "reflection camera positions" in mind as well (which might mean excluding the ground from being an occluder etc etc).

So either reflectionCamera.useOcclusionCulling = false; or tweak occlusion culling until things look ok.

Planar reflections render the scene again, they are a heavy effect, it's an effect you more or less design your scene around and it's not something you just add at the end and hope everything works out.

 

Sorry for my ignorance, but shouldn't an occlusion query "just work" if done the same way but from the mirror position along the reflection camera render pane? (Like just testing intersection of occlusion colliders/areas with whatever viewing volume that gives.) I mean yes things are mirrored etc, but I can't wrap my head entirely around why that would suddenly make such a query infeasible without altering the whole underlying occlusion data. Please note I'm a bit of a math noob, so maybe this is a stupid question in which case I apologize.

 

What does "just work" mean? It is "just working", which is the problem here

Occlusion culling for the mirror camera is hitting the backfaces of the ground and thinks "oh, I'm seeing the backfaces of something, I probably don't need to render anything beyond here, it's an invalid area" (AFAIK you can tweak the behavior if you want).

 

Sorry, I'm a bit dense on those things: since the reflection shows the front and not the back of faces, how does it query somehow differently than what I'm seeing?

 

It doesn't query something differently, it just queries it from a much different position (for examples, 3 meters in the ground looking up), which can be an an invalid position for occlusion culling.

 

Is the occlusion system something that can be changed without full source code access? Otherwise since I haven't found any other way of doing reflections, it seems like the Unity dev team should expand the occlusion query code to allow some sort of "start the query from this plane rather than camera origin position but keep the original query cone volume" for reflection cameras. Otherwise how is this ever going to work? I'm a bit surprised though that such a fundamental limitation with the mirrors wasn't really thought about before if this really is the root of the problem. I always thought the MirrorReflection4 wiki code originated from within Unity, but I guess maybe not...?

On a side note, is the wiki just temporarily down or gone for good? Is there a different official or semi-official way to do basic mirrors than the one that was available on that wiki? Since I guess part of the issue is with that script, if it's now gone entirely I'm wondering how that can even be addressed.

 

Changed? It has settings and you can include and exclude stuff to be occluder.

If I remember correctly it was based on a script that Aras wrote on a whim?

Here are planar reflections working with Occlusion Culling.


I had to remove a bunch of meshes from occluders to do it and tweaked the settings a lot.

It's doable. There is no bug here. We can talk about the Occlusion Culling system being not great (and it's not great), but there's not an inherent reason it doesn't work properly with Occlusion Culling. The only thing is that you end up having cameras in unexpected positions, so you end up working around that.

With all that said, I typically keep Occlusion Culling for the reflection camera off, because I don't want to bother.

 

Doable doesn't mean sensible, and what you describe still seems like a hack to me (albeit a better one than just turning off occlusion for mirrors). Why wouldn't a query like I described be possible to add in? That would avoid altering the occlusion data altogther. It seems to me like the problem stems from the camera position itself being a relevant filter point always with the lack of an option to specify a different point (the camera/mirror plane or slightly in front) while keeping the same query volume. Just based on the available data, I don't see why it would need to be altered to be traversed in such a manner necessarily - at least not on an occluder level, maybe on the internal level of whatever tree is traversed for the query, I wouldn't know how that part works.

And with "changed" I mean changing the query code to allow something like above, a fix to the wrong query style.

By altering the data itself as you described, it seems to me like that would possibly degrade the regular camera occlusion queries as well anyway. So apart from being cumbersome, it also has other IMHO undesirable downsides. That doesn't really seem like a great solution to me, since it just seems to work around the symptoms (wrong query style) with suboptimal data rather than address the issue.

Edit: maybe another more usable way would be to be able to mark something as occluder for regular cameras, but not for mirror cameras at least. That'd be a compromise that has less of an effect on regular camera performance just to get the mirrors to be less confused. Is that currently possible by any chance?

Edit 2: also I forgot, thanks for explaining it so well. That was really helpful!

 

This query?

That seems like a verty specific feature /workaround that is built for a feature that Unity doesn't really provide. (I mean, HDRP has it now, but I don't know what HDRP does).

I do not see what is a hack about what I'm describing. You are doing what you would be doing for normal occlusion (checking if everything looks okay, there's no pop in / pop out that is visible etc), you just need to include areas inside the ground in your checks and then adjust the settings accordingly.

 

So HDRP has mirrors in some official capacity?

If Unity doesn't really provide mirrors outside of HDRP with some more or less official script without these issues (avoiding these might e.g. be possible by it using such a new query style) then maybe it should? Although I guess this does change this from a bug to a feature request. It just does baffle me a bit that such an old effect (doesn't e.g. Sims 3 already have mirrors that render full geometry rather than just cube maps or other reduced hacks? When did that come out again, 2009?) has no simple official method of adding it in. And fighting the occlusion system because it doesn't really like one doing this doesn't seem very simple to me.

I definitely fail to see what you are suggesting as anything but a hack, since it's messing with occlusion data for something which IMHO is a fundamentally unsuitable query style for mirror cameras. But I'm repeating myself, see above. In any case, this feels more like something that should just be in Unity as a working thing to drop in anyway to me. I don't really understand why it isn't, especially with this somewhat headache-inducing caveat in getting it to work.

 

I doubt Sims 3 used Occlusion Culling.