Hello, I’m trying to export from 3Ds Max using the babylonjs exporter to a .gltf file. All materials are converted to pbr material which makes my experience stutter in VR on the Oculus Quest. Even a simple box with no textures can reduce the performance to 40-50fps if it takes a large portion of the screen. My scene runs at 22-30fps, but I think this can be imporved if most objects would use the standard material and not the PBR.
I’d like to be able to export certain objects with a standard material, so they render faster and other objects (smaller things that don’t take too much space on the screen) as PBR.
I’m unable to figure out how to force the babylonjs exporter to export as standard material. Can you please help?
We only support exporting to the Babylon standard material when exporting as .babylon. Any glTF export is imported as PBR material due to the schema.
I understand. I’ll split the scene and use two exports, one via the babylojs exporter and another as an .obj export. I guess Oculus Quest is not fast enough for PBR materials.
Thank you Drigax.
Pinging @sebavan as well, maybe he knows a bit about improving performance on lower spec hardware like the quest.
@grigtod you claim that a simple box using rhe default material only renders at 40-50 fps? Thats a bit concerning
@grigtod, could you try after import removing all the materials on imported objects by a simple standard one ?
I am really wondering where the perf bottlenecks come from and would like to tackle it down if possible so first let see if standard fixes it ?
Hi sebavan, yes I tried the following and performance was 72fps:
var newSimpleMat = new BABYLON.StandardMaterial(“newStandardMat”, _scene);
newSimpleMat.diffuseColor = new BABYLON.Color3(1, 1, 1);
var imp1 = BABYLON.SceneLoader.LoadAssetContainer(_path,_file, _scene, function (container) {
var meshes = container.meshes;
container.addAllToScene();
for(var meshIndex = 0; meshIndex < meshes.length; meshIndex++) {
if(meshes[meshIndex] != null) {
meshes[meshIndex].material = newSimpleMat;
}
}
});
I also tried exporting and loading an obj and the result was the same.
This is actually related to another question I had a couple of weeks earlier: When shaded model fills the screen the fps drops - possibly due to normal map. Why?
could you try to force the pbr to be unlit ?
basically
var imp1 = BABYLON.SceneLoader.LoadAssetContainer(_path,_file, _scene, function (container) {
var meshes = container.meshes;
container.addAllToScene();
for(var meshIndex = 0; meshIndex < meshes.length; meshIndex++) {
if(meshes[meshIndex] != null) {
meshes[meshIndex].material.unlit = true;
}
}
});
???
Just to see if this works as it should do almost nothing 
Also, you make newSimpleMat, but assign putNewMat, which is null. This might give unexpected results if you continue like this for further test.
It looks like one of the feature used in the pbr is not going well on Oculus for some reasons.
If unlit works, we will try to pin down the broken part
Hi JCPalmer, yes I forgot to rename the material when I copied it to the forum. Just edited it.
I’ve set up a quick playground for testing: https://www.babylonjs-playground.com/#F41V6N#9
To test with PBR uncomment line 19.
I made a recording in VR: https://youtu.be/_FcM2J6Ivkk
I hope you can see in the video, even with a basic box the performance goes down quite a bit. When I did the test on my machine the box was exported from 3Ds Max and I think when it was taking larger portion of the screen it was slowing down things to 50fps. With the example in the playground performance drop is not as bad, but still significant.
sebavan, I’ll do the test you suggested now.
sebavan I tested pbr unlit and it doesn’t suffer from the performance issues.
Good, I am mostly just lurking, but I have more than just passing interest in PBR on Quest, so going to make sure some typo sends things off the wrong way. Inability to do PBR there would definitely affect my plans.
No worries. This is a playground with the PBR with unlit ticked and it’s running at 72fps stable: https://www.babylonjs-playground.com/#F41V6N#11
By the way the fps of the scene before jumping in VR is 72fps either way. This may or may not be a VR issue.
ThreeJS seemed to have encountered problems as well. This might give some clues https://github.com/mrdoob/three.js/issues/18338
Edit: they had the issue when the context parameter alpha is set to false. Not sure where we do that to construct a test
Is this at 60 fps (no ibl) : https://www.babylonjs-playground.com/#F41V6N#14 ?
and this (Env) : https://www.babylonjs-playground.com/#F41V6N#15
and this (DDS) : https://www.babylonjs-playground.com/#F41V6N#16
and finally this (No Float) : https://www.babylonjs-playground.com/#F41V6N#17
@sebavan I just tested all 4 playgrounds and all of them work at 72fps on the Oculus Quest in VR mode!
1 Like
ohhhhhh so it would be overdraw with the background material with is alpha blended
Basically do not use : const env = scene.createDefaultEnvironment();
But only use: scene.environmentTexture = BABYLON.CubeTexture.CreateFromPrefilteredData("/textures/environment.env", scene);
It looks like blending here on full screen might be the culprit.
Thank you for taking the time and figuring this out!
I just encountered another issue that’s probably very related. The controllers can change the app performance based on their rotation (you read that right, it’s ridiculous): https://youtu.be/Bo8zRi1ALFU
A solution to this is to add:
xr.pointerSelection.detach();
This will disable the transparent selection line.
More info can be found here: Optimize your scene - Babylon.js Documentation
So it looks more and more as an overdraw issue with transparency.
Adding @RaananW in case he is got more info ?