Hello good people!!
I’ve started this PR:
Performance mode by deltakosh · Pull Request #12954 · BabylonJS/Babylon.js (github.com)
And here is the doc:
Documentation for scene performance priority by deltakosh · Pull Request #638 · BabylonJS/Documentation (github.com)
I would like to get some thoughts from the community about it. Should we add more features to each modes? if yes which ones?
Great great. Now I can do all of them with one line of code 
Maybe
mesh.doNotSyncBoundingInfo = true
too,… if not picking. Sorry if it is already included 
Yes, I think you are asking about changing defaults in a backwards compatible way, Right?
mesh.picakable is one I am switching now in the Blender exporter. Thing is, you have to actually do something (like assign an action) in order for it to be even useful. Otherwise, every frame, it needs to be checked that it being picked.
On XR, if you turn on picking from 2 controllers, you have to pay for the checking twice.
Good one!
Yes within an user actionable flag. So backward compatibility is still by default
isPickable is definitely in
More awesomeness as always @Deltakosh !
Have you thought or looked at how this should operate with regards to the SceneOptimizer?
Separately, I’m wondering how much content in my book will be outdated by the time it gets published 
Next time, you could write a book about the handling of WebGL by Apple. You will likely not have to worry about updates until you are retired 
The book would only have one page tho? 
Shot 
Chaser 
You guys kill me! I’m dead
see that as an opportunity to write a second edition!!!
SceneOptimizer is somehow the opposite 
It will try to add perf whereas with this new property you will have to remove optimizations
Ha yes indeed 2nd edition talk already 
Well yes of course that’s one mode of operation for the scene optimizer, but there’s two things:
When the SO operates in perf improvement mode, shouldn’t it have a strategy to toggle “glam” vs “fast” mode on/off, or do the individual optimizations already get covered with existing strategies?
Similar consideration for the SO operating in “make me look good” mode, but reversed
That’s a good tactic! Putting more load on the dev of the tool will certainly give you more time before you need to consider the change… I can see you 
I am in the process of making my entire process multi-scene capable (everything is once again broke for the 2nd time this year), & I saw this line I had commented out in a mesh sub-class with an added a comment:
// this.doNotSyncBoundingInfo = !isButton; DOES NOT work on Quest
I remember putting the line in while going thru the optimizations documentation. I am sure it initially worked on a desktop, as I also never develop directly for XR, except for things like hands.
Not just for you Marian, including myself, but thought I should report this (a little late). Once I am operational again, will un-comment to get more details.
It might have something to do scene.onPointerObservable.add(func). I was trying to have a material editor that handles multiple material even works in XR. You cannot get picking information using scene.pick() on XR.
in both mode, SO will try to reach (top down or bottom up) a given fps by toggling glam vs perf (on way or the other).
For instance in perf mode, shadow could be turned off to reach the required fps. In improvement mode, shadows can be turned ON while we stay at the given FPS
The main difference with the new performance priority mode is that SO is iterative. It will work across several frame to adapt to the current scene/hardware.
Performance priority is more “brutal”. From the ground up, the scene will focus on perf first
That’s a clear way of putting it
In the case where a scene somehow has both present and operating at odds with each other, the brute glam starts things off and then goes away at frame 0, with the SO kicking in over the next hundreds to thousands of frames. If “that brute” overdid it and fps is flagging, the SO will gradually degrade individual aspects that might comprise parts of the priority mode config.
Did I get that right?
Totally correct!
I did this demo for people to evaluate this new way of working:
Performance priority demo | Babylon.js Playground (babylonjs.com)
(Beware this is a stress test demo so it is not meant to run on mobiles)