Adding screenshot

Note: this is issue in 2.2 only. Works OK in 2.1. Also OK in editor, but fails on Android phone.

This is an untested workaround. I don't have the time to properly solve this right now (will do next week), but as this seems to be critical for you, could you try the following patch?

Index: NoesisView.cs
===================================================================
--- NoesisView.cs	(revision 7956)
+++ NoesisView.cs	(working copy)
@@ -443,10 +443,13 @@
         }
 
         LoadXaml(false);
+
+        Camera.onPreRender += PreRender;
     }
 
     void OnDisable()
     {
+        Camera.onPreRender -= PreRender;
     }
 
     void OnDestroy()
@@ -749,8 +752,21 @@
         }
     }
 
-    private void OnPreRender()
+    private bool _updatePending = true;
+
+    private void PreRender(Camera cam)
     {
+        // We need the offscreen phase to happen before any camera rendering. This is critical for tiled architectures.
+        // This method is invoked for each camera in the scene. We enqueue the offscreen phase in the first camera and disable for rest of cameras
+        if (_updatePending)
+        {
+            RenderOffscreen();
+            _updatePending = false;
+        }
+    }
+
+    void RenderOffscreen()
+    {
         if (_uiView != null && _visible)
         {
             _commands.Clear();
@@ -819,6 +835,8 @@
             {
                 _texture.DiscardContents(false, true);
             }
+
+            _updatePending = true;
         }
     }
 

Thanks! Seems to work on first try - I'll test it and release (temporary) update of my app this week until the proper fix.

Could you please try with the attached NoesisView.cs? This is the right solution, it is a workaround for Unity bug and also an optimization for current 2.2 behavior when you mix cameras to the same render target in tiled architectures (mobiles).

Unfortunately it doesn't work. The cameras are activated later (based on what the user does) and the NoesisView.cs code is reading them on onEnable()
During onEnable() there's only Camera.main typically. Why isn't the offscreen phase applied to the camera Noesis is attached to (regardless of any other cameras?) Perhaps it has something with depth sorting?

I thought more about it - in my opinion, Noesis offscreen phase should be synchronized the the camera the Noesis script is attached to (unless I'm missing something) - will work as expected in such case.
Perhaps I'm missing something about offscreen rendering?

So, yes. That's what is happening for normal cameras (like a camera for the HUD, a camera for a render texture,...) the offscreen phase is rendered at PreRender time of that camera.

Problem is with cameras that renders to the same texture. In those cameras, only the first camera (by depth order) changes the active render target, the following ones reuse it.

So, if noesis is being used in one of those cameras (not the first one) and we do the offscreen in that camera, a render target change is happening with the following implications:

1. In Android, Unity is bugged and if the render target is changed it is not properly restored.
2. Changing the active render target temporally to render a few things in a different texture (like offscreens) and then going back to the original render target is extremely inefficient in Tiled based architectures (all mobiles).

So we need a way to render the offscreens at the first camera (by depth order) just before the render target is bound. My new code, was trying to do that, but I think that the selection of the first camera must be done by frame. I am not sure if I like this approach.

Another approach, is not trying to be smart and expose a property in the component to indicate that camera. I don't like this option neither because it is a manual process and a high percentage of users won't set it up correctly.

So I need to think more about it.

Hmm, yes - I see. Would the previous workaround with _updatePending work? It does look more "hacky" but may be the right one.

That workaround is the solution we had in 2.1 but it is inefficient for "normal" cameras because all offscreen from all cameras are done first, before any camera. So, if each offscreen phase needs one extra texture, and you have 4 cameras. you need 4x the number of render targets. If you do the offscreen when each camera needs then we can resuse the offscreen textures.

Not sure, if I am making myself clear here :)

Yes I got it - thanks!

Interesting problem.

I am working on a new solution, will send you later

By the way, this way to use cameras (Stacked cameras in Unity parlance) is deprecated in Scriptable Render Pipeline because it is inefficient and hard to implement (buggy) for Unity.

It is a pity they didn't deprecated in the fixed pipeline. :)

re: deprecated: Is there another option to render "Noesis UI on top of two cameras"?

https://forum.unity.com/threads/glitching-with-multiple-cameras-lwrp.592477/

They are deprecating multicamera layered rendering in LWRP and HDRP. For us it is going to be easier because we just do the offscreen in the attached camera, exactly what we are doing in 2.2.0. For you, I think you need to use render passes, but I am not sure about it, they are in beta and many things are changing...

But you can stay in fixed pipeline where layered cameras will be supported and we need to fix this issue.

Please, try this new version

Works! I changed the code a bit to make it clearer and avoid calling GetComponent<Camera> in Update() - a small thing, I know but just a matter of principle. Attached file with changes.
Very unlikely myCamera will change anyway.

Thanks for the fix!

Thanks! I took your changes, did a few more changes and uploaded to our repository.

I will try it later. When is the iOS error happening? when the camera changes to "Do not clear" ?

Yes, when camera changes to "do not clear" (or perhaps next render after)
This is the approximate timeline:

1. app start (1 camera)
2. some rendering
3. second and third camera enabled, each taking half screen, top camera set to "do not clear"
4. exception

Hope that helps! If you need any further specific info please let me know! Otherwise I'm going to work on my other tasks. So far I've spent 2+ weeks upgrading to 2.2 in total. Not frustrated just making sure to communicate the timeline so that Noesis is aware. Would be nice if upgrade time was less than 1 week - wondering what's the best way to achieve it. I'm not sure if I'm an "edge case" customer (since I have somewhat complex UI, and thus upgrade time is expected) or not.

I am not sure if this is still related to the same bug in Unity you were hitting on Android but this is another bug in Unity, they are sending us a null pointer when they shouldn't. In the scene I am testing (just two cameras, one rendering skybox and the second one rendering the UI) I am able to crash even with the GDC patch I sent you.

I am able to workaround by setting the Camera Culling Mask to: Nothing, this workaround is a minor optimization in fact. Please let me know if this works for you. If it does we need to document it.

Regarding the time for the integration. Well, problem is we took a lot of time between 2.1 and 2.2, more than a year. This version brought many many things and it is normal to have longer integration times. Honestly, apart from this bug I think you didn't hit more bugs (apart from deviation from WPF we fixed, that yes, they took you time also). We have more clients still integrating, and also clients that did finish the integration. You are not a edge case customer, just you were unlucky hitting this bug.

Our solution to avoid this: release often. That's what we want to achieve with 2.3...

Thanks for the update! Yes, the more frequent update plan sounds good.

Unfortunately, the problem with the crash is still here with Camera Culling Mask to: Nothing
I'm using the GDC patch, which works for now... (will have to test on many devices to make sure)

:( I don't know what's going on. I was able to reproduce the same error on macOS, with two cameras (one for Noesis) and the GDC patch didn't help. So I will try later today reproducing exactly your same scenario (3 cameras) and on iOS.

Perhaps some weird Unity bug... :(
Thanks! Just to clarify: for the moment, I'm unblocked (GDC patch works and performance is good for my use case.)
Worst case, I'll change my render code to manually clip and adapt all functions to use single camera only (could take several days) instead of using multiple cameras.
On Android so far in the last 4 days since release we haven't heard of complaints, which is good. iOS is still released with Noesis 2.1. I plan to test on more devices in the following week before getting iOS on Noesis 2.2 as well.

I tried to recreate your same scene: 1 camera rendering red up, 1 camera rendering blue bottom and a third-camera (Don't clear) with NoesisGUI rendering a UI using offscreen. If I set the culling mask to 'Nothing' it works on macOS and iOS (Unity2018.3.11). Could you please try it? If it works for you then I need to understand what's different in your project.

Thanks!

In fact, on iOS I don't need the culling mask workaround... that's only needed for macOS

I got the project - didn't try it, but it will work. The cameras are set-up at project start. Did you try your latest fix with the 3-camera project I sent when I opened the bug? It's in description. Does 2.2.1 work with it?

I think the difference is that I'm setting cameras at runtime (as in the repro project I sent), not at project start.

I manually modified 2.2.1 NoesisView.xaml with the initial patch that is not ideal, but works - attached

You are right, I didn't try delaying the change to 'do not clear'. I will try later today. Thanks!

NoesisView4.cs does not resolve the behavior for me on PC/default render pipeline.

Please, try with the last patch from nokola (0001427:0005598 )

btw, for my use case the NoesisView-2.2.1-modified-working.cs is ideal! I mentioned "not ideal" because jsantos mentioned it has some performance implications on mobile. I've tested NoesisView-2.2.1-modified-working.cs on mobile - for me no performance issue at all (although I only render 2 quads + Noesis.)

Just mentioning that I'm happy with NoesisView-2.2.1-modified-working.cs as current solution

Thank you, I'm back and running!

Which patch (of the 4 or 5 above) fixed it for you stonstad?

I think he is using your last patch.

@stontad could you please describe how you are setting up your cameras (how many, what depth order, clearing options etc) and if you are dynamically changing properties (clearing, depth).

I need to understand all the scenario to properly find a solution to this mess.

Ok, so I found a much better approach (aligned with the idea in 2.1) and also doing the needed optimizations for tiles architectures. I think this is the best solution.

Note that you still need to use Culling Mask se to None in cameras rendering only NoesisGUI (not rendering 3D). This is to avoid a bug in Unity that I am going to report later today. I was able to reproduce this issue even with 2.1

Could you please try it?

We are going to include this patch in the upcoming 2.2.2, we also added the following mention in the documentation

UNITY BUG

When using Camera Stacking (several cameras rendering to the same render target)

make sure the camera rendering the UI has the property 'Culling Mask' set to 'Nothing'.

This will avoid a bug in the latest versions of Unity.

NoesisView-5.cs works without issue using my two camera/view setup!

Please, reopen if needed

Thanks for the fix! Verified OK on Android and iOS