Question for devs on WebXR Multiview rendering

Help & Support
,
1

Hi Team,
I’m currently working on an implementation of multiview rendering for VR in a fork of playcanvas (because the quest 3 soc is a total potato about 1/4 the performance of the vision pro). Following metas example https://developer.oculus.com/documentation/web/web-multiview/ I of course need to update the vertex shaders to enable the new extension plus proxy in the specific matricies depending on the view.

My question is, what machanism would you recommend to do the switch on the vertex shader. My assumption was to add an #ifdef in the shader but then I’m not sure whats the best practice method to “activate” it so that it recompiles and switches to the new shader type when xr is enabled.

Thanks in advance

2

Hi … I assume you use the StandardMaterial under the hood.

I would add a property to the StandardMaterial, perhaps .multiVIew.

Then inside the standard-material-options-builder.js I would add a property with the same name and simply copy the boolean from the material.

The modify the transform.js which handles the use of the matrices.

In the lit-shader.js the transform chunk is added this way:
code += chunks.transformVS;
so you could add line like this just above to pass in the flag:

if (options.multiView) code += '#define MULTIVIEW\n';

and then inside the transform.js you could use #ifdef MULTIVIEW

Then lets assume you render normally, without XR. When you enter XR, you’d loop over all materials, and do:

material.multiView = true;
material.update();

when this is done, the existing compiled shaders for the material is dumped, and a multi-view variant would be compiled.

But personally, I’m not sure how much win you’d get from using this extension. Typically, a multi-view is rendered is two separate loops, and so you pay the cost of all set up twice. But play canvas uses a single loop, sets up all the state for the mesh one time, and then changes viewport (left or right), updates matrices uniforms only (left or right) and simply submits the draw call. So there is not a huge overhead from the multiview.

2 Likes
3

Thanks for the quick reply! I’ll let you know how we get one. Oculus claims about 20-50% improvement but I’ll take anything I can get right now, performance is awful even in simple scenes (cpu limited) and the profile isn’t revealing anything, its just rendering

4

How many draw calls do you have? Any way to lower that?

5

Yeah I’m working on that too but simple experiences that have never dropped frames perform pretty poorly which took me by suprise, really wasn’t expecting the quest 3 cpu to be so slow. Its a real shame theres no webxr support for webgpu (nothing you guys can do here its just not spec’d)

1 Like
6

I also have a gpu mesh instancing branch to call on and an lod system but the majority of this needs fixing in art

2 Likes