Great great. Now I can do all of them with one line of code
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.
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?
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
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?
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)