If I had not decided to rebuild / integrate / toss out the failed experiments of my entire stack from Blender Source Generation all the way to the end as sort of a years resolution, I would be testing this! Things are a bit taken apart at the moment.
BabylonJS:master ← rgerd:xr-proj-multiview
opened 08:10AM - 24 Jan 22 UTC
This change hooks up the `XRProjectionLayer` to our existing xr multiview render… ing implementation. The `"texture-array"` texture type in `XRProjectionLayerInit` is designed to be used with the multiview WebGL extension, and so we use multiview rendering whenever `"texture-array"` is specified as the texture type.
Before:
<img height="300" alt="scene-render-no-mv" src="https://user-images.githubusercontent.com/4724014/151077741-3f9e842b-9aec-437d-89a5-665e53daef11.png">
After:
<img height="300" alt="scene-render-mv" src="https://user-images.githubusercontent.com/4724014/151077735-1ec81825-c3bd-4ec8-919e-5ae1acc1518a.png">
Taking performance profiles on an Oculus quest with a playground rendering 400 default-fidelity spheres (https://playground.babylonjs.com/#F41V6N#705), I got the following per-frame times for multiview turned off and on:
Multiview off
- scene.render: 59-62ms
- GPU time: 5ms
- renderFunction (the entire frame): 61-72ms
Multiview on
- scene.render: 30-32ms
- GPU time: 3ms
- renderFunction: 32-40ms
Exported profiles from Chrome DevTools:
[xr-multiview-profiles.zip](https://github.com/BabylonJS/Babylon.js/files/7937993/xr-multiview-profiles.zip)
So we got some significant performance wins on both the CPU and GPU, as would be expected. With scene.render taking up around 95% of the entire time for the frame, cutting the time for that function down in half just about doubled the overall FPS.
Even with one sphere, I'm still seeing around a 10% decrease in frame time (40% in scene.render) and about a 20% decrease in GPU time.
fixes #10767
Was a long time in coming. This is not a request for anything, but I did not know where to classify this.
4 Likes