Feature Request: allow ArrayCameras to opt in to multiview rendering

Description of the problem

When the OVR_multiview2 extension support landed (#16316), it was limited to running only in VR contexts (#17596). This was done, as I understand it, to prevent unexpected console warnings for all ArrayCameras, and was probably prudent as a risk mitigator anyway.

This is a request to open that up slightly, by giving ArrayCamera a way to explicitly opt in to multiview rendering outside of the vr.enabled scenario. This could be as simple as a multiviewEnabled or similarly named boolean property on ArrayCamera, which could then be checked alongside vr.enabled in the appropriate spots in WebGLRenderer:

if ( ( vr.enabled || camera.multiviewEnabled ) && multiview.isAvailable() ) {...}

This approach should have no impact on code that doesn’t opt in.

Three.js version

• Dev
• r110

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, …)

N/A

[lojjic]

@mrdoob That’s fair. This felt like a very simple enhancement to the current solution to me (I definitely wasn’t asking for a redesign of anything!) But if doing it correctly will indeed have cascading effects, like requiring a new frustum culling solution as @fernandojsg pointed out, then you have to decide if it’s worth that effort. I’m not sure I can prove that, especially given the current antialiasing situation.

FWIW, I do have a hacktacular workaround for my XR use case: overwrite all of WebXRManager’s methods with empty functions and set vr.enabled like normal so it triggers the multiview code paths but doesn’t do anything else. Gross but it seems to work.

[fernandojsg]

The thing is… I have yet to see an example where multiview solves a performance issue that InstancedMesh couldn’t 🤔

I don’t get that, even if you use instancedMesh in your app, you could still use multiview and you will be dropping the number of drawcalls the same way. For sure for an specific example as just using 1 drawcall to paint plenty of cubes you will probably won’t get a lot of improvement (still you will get something), but that’s not a common use case I believe.

Regarding adding multiview or not, honestly I thought that we would have antialias on MV way earlier, although Oculus browser has already an implementation on that and I know another browser vendor is working on that too so I’m hopeful that it will become a thing in all the browsers soon. Once we get antialias support in MV the current code and API will remain practically the same with just some few changes on the implementation.

And currently you could still give it a try with antialias off to determine your frame budget for whenever we will get the antialias MV so I’d vote for keeping while we wait for that to happen.