Hi, i use the es6 modules of BabylonJS and Webpack to bundle my app. In my code i use only the PBRMaterial but the StandardMaterial is still included in my bundle. The StandardMaterial is rather big therefore i would like to remove it.
I analyzed the bundle and the StandardMaterial is imported from BabylonJS itself.
I use SSAO and therfore i have to enable the GeometryBufferRenderer. There is alot of material specific code here: Babylon.js/geometryBufferRenderer.ts at master · BabylonJS/Babylon.js · GitHub
It would be nice to refactor this somehow. If someone only uses the StandardMaterial for exmample he would also get the PBRMaterial.
In another app i also use the GLTF export. The export also imports the StandardMaterial and other Materials. Here it would be also nice to make the support for different materials optional.
I just tried to use the new PrePassRenderer for SSAO instead of the GeometryBuffer but the PrePassRenderer itself requires the GeometryBuffer 
The standard material is being used by the scene itself as the default material. It is also loaded by many different components that are probably in your dependency tree. The line you mentioned is probably one of the reasons.
We can consider moving constants out of the classes for better tree shaking, I agree. Would be a nice optimization 
We will need to keep a reference in the classes themselves, as we keep backwards compatibility, but I don’t see why not create a constant file per subdirectory in src (or even specific ones for classes like the mesh, which is filled with constants).
Its not only the constants. Just check the next lines: Babylon.js/geometryBufferRenderer.ts at master · BabylonJS/Babylon.js · GitHub
You are also accessing properties of PBR and StandardMaterial.
As GeometryBuffer is a core component maybe the Material itslef could provide the necessary logic here … someting like Material.prepareGeometryBuffer()
And this way you don’t have do extend the GeometryBuffer everytime you want to support a new material.
Sure, I totally agree with that
As long as we don’t backwards compatibility, we should do whatever we can to support proper tree shaking.
Regarding the line you pasted, I don’t see a reason to check for instanceOf. There are better (and more performant) ways to check if this is the right class.
Finishing with the sentence I started with - I totally agree with you We should hunt down all of those and make sure tree shaking works properly.
Do you want to create a github issue for this? It will not be addressed immediately, as everyone currently have important tasks on their plate, but it is something that will be nice to have for 5.0. And 5.0’s release is far enough for us to address it by then.
1 Like
Totally agree, this is something we are chasing down (while preserving backward compat). Ideally if you can list the places where you think we can remove the dependencies that would be lovely
(just checkboxes in the issue so we can add more in the future)