repro: Babylon.js Playground
This stemmed from my integrating multi-view in my own app. The top portion are codes of the default playground. Pls comment and uncomment
engine.registerView(canvas2, camera2);. Observe that the default canvas view is affected by the position of camera2. I’m not 100% sure how multi-view is supposed to work. I was expecting canvas2 to show camera2’s view while the default canvas remains unaltered.
Is this wai ?
Yup it is exepected as in this case the main canvas is a working canvas only. From the doc:
Using Multiple Canvases | Babylon.js Documentation There is also some tricks in the doc to help with perfs and such
ok, so that was what the working canvas warning meant. hmm…its time for me to ask for help!
This is what I want:
This is a ss of a retro game: theme hospital. The top right ui displays the a patient’s location and stats in 2d.
This is what I have now, using multiview:
The bottom left blue bordered view uses multi-view. It allows the user to spy on their AI character assets via camera tracking and following. The ui is toggleable and movable. The perf in ffox dropped from somewhere around 50fps to 30fps from the moment the view was enabled. In Chrome, its a little better (60fps to 45fps). How can I achieve the spy effect w/o the perf hit ? Should I be using multi-view ? or is there a better recommendation ?
So if I get the idea right… What about the camera that renders a specific region of the game into a RenderTexture?
You basically make the camera draw into a texture that resides in a GPU so you avoid all the heavy instructions on CPU that get dispatched when you render into different contexts, in your case - canvases, so no need for OS → browser sandbox → webgl → canvas etc. thus performance improve
Here’s a good example of it https://playground.babylonjs.com/#69DRZ1 , you just need 2 cameras rendering and pick an optimal RenderTexture resolution so you don’t take more GPU memory than you need
You can read more about it here: https://doc.babylonjs.com/divingDeeper/postProcesses/renderTargetTextureMultiPass
On top of that you also get an ability to apply various post processing to your render texture such as black and white effect or blur or whatever you like, really, you can even rebuild the depth and do something with it in RT so the possibilities are endless
Hey, RTT is a nice idea! So I mocked up a quick test: https://playground.babylonjs.com/#YICJXI#3
On chrome, it still doesn’t feel smooth. There is the occasional stickiness when panning the camera, guessing
DumpData is consuming bandwidth. It could work if there was a blazing fast way of getting the pixel data from the RTT every frame.
edit: ehehe, found a faster way: https://playground.babylonjs.com/#YICJXI#4
Oh you don’t need an extra canvas anymore, like I mentioned above rendering to the canvas is the expensive part because of moving data back and forth so yeah it looks like your 2nd playground is the one
I would totally remove the second canvas to help perf as the gui part occludes most of the game
For completeness and for future users who might stumble upon the same need, I present moving dude PG. So far, works well in ffox and Chrome. Marking as solved, thanks everyone for helping !