StandardMaterial needs to be imported

[peterimg]

Hi

I’m working on BabylonJS v 4.2 and I do not want to use StandardMaterial at all in my project. To limit bundle size. But I’m starting to have this error.

The surprise is that I need to import StandardMaterial to not use it at all cause All is done using NodeMaterial.

import '@babylonjs/core/Materials/standardMaterial';

This import sorts the problem out but I will not use this material at all.

Also, I can import it rebuild and after the error is gone, remove this import, and app works just fine for some time. And then it’s again starting to show up.

How to fix the fact that I will not use it on the Ground with a displacement and primitive meshes created with a MeshBuilder.

Refgards
Peter

[RaananW]

Hi Peter,

this is explained here - Babylon.js ES6 support with Tree Shaking | Babylon.js Documentation , and is sadly part of the side effects of porting from UMD to es6.

The standard material is the scene’s default material, so by importing the scene you are actually using it.

[peterimg]

But if I do not want to use it?

Can I remove it during the build? so have like lazy loading if it’s NODE_DEV=‘development’ and then removed it from the final build? Or will I have an error?

Regards
Peter

[peterimg]

And also if I do not need it as it said here:

I’m not importing it fine. But I got an Error that stops my code from execution.

What to do with this?

Regards
Peter

[RaananW]

You will need to make sure all meshes have a material right after they are created (or pre-render), otherwise the standard material will be initialized. Technically you would need to make sure that defaultMaterial is never accessed.

[peterimg]

OK. A gotcha moment.

This:

const box = MeshBuilder.CreateBox('Box',{size: 1}, scene);
box.position.x = 100;
box.position.y = 100;
box.position.z = 100;
[...]
box.material = material;

should be like this:

const box = MeshBuilder.CreateBox('Box',{size: 1}, scene);
box.material = material;
box.position.x = 100;
box.position.y = 100;
box.position.z = 100;
[...]

and the error is gone. Would be nice to put it in that FAQ URL for reference in the future for other lost souls

Regards
Peter

[peterimg]

Hi @RaananW

I told you I will be back with this

I moved to version 5.4 and I still get StandardMatarial bundled in and bloating my size, but I moved everything to NodeMatarial so I do not use it at all.

And it works without any imports as long as 1st line after creating a mesh I setup the material to be node material, so this is all good.

But I cant bundle it out in any way cause its used in other classes that I use but I do not use them with StandardMaterial, like:

/node_modules/@babylonjs/core/Maths/math.vector.js
/node_modules/@babylonjs/core/Maths/math.color.js
/node_modules/@babylonjs/core/Misc/typeStore.js
/node_modules/@babylonjs/core/Misc/decorators.js
/node_modules/@babylonjs/core/Misc/smartArray.js
/node_modules/@babylonjs/core/Misc/typeStore.js
/node_modules/@babylonjs/core/scene.js
/node_modules/@babylonjs/core/Particles/solidParticleSystem.js
/node_modules/@babylonjs/core/Materials/material.js
/node_modules/@babylonjs/core/Materials/materialFlags.js
/node_modules/@babylonjs/core/Materials/Textures/texture.js
/node_modules/@babylonjs/core/Materials/materialHelper.js
/node_modules/@babylonjs/core/Materials/materialDefines.js
/node_modules/@babylonjs/core/Materials/effectFallbacks.js
/node_modules/@babylonjs/core/Materials/pushMaterial.js
/node_modules/@babylonjs/core/Materials/prePassConfiguration.js
/node_modules/@babylonjs/core/Materials/material.detailMapConfiguration.js
/node_modules/@babylonjs/core/Materials/materialPluginEvent.js
/node_modules/@babylonjs/core/Buffers/buffer.js
/node_modules/@babylonjs/core/Materials/imageProcessingConfiguration.js
/node_modules/@babylonjs/core/Shaders/default.fragment.js

/node_modules/@babylonjs/core/node_modules/tslib/tslib.es6.js

So all of this is importing it but I never use it.

How to get rid of it?

Regards
Peter

[RaananW]

This might be because of the scene’s default material (which is the standard material). Are you able to share the project?

[peterimg]

@RaananW

No. Unfortunately. But this is this. How we can not import it at all? You got now have options to choose from, and I’m choosing NodeMaterial.

There are other Packages that I never use as well like: Bones, Lights, ParticleEmitters, Procedural Textures and more that I do not use at all but they are in the bundle.

But surprisingly to add engine views methods I need to add one more import to make them work

So why not add import next to your scene to make a choice of your default and maybe only material? Like this:

[RaananW]

That’s because of the way we build, import, and separate modules. We are trying to decouple as much as possible, but it is sometimes not possible.

I am not sure which one of the modules you are importing is using the standard material. we are doing our best to minimize the amount of unneeded packages you are using, but sometimes it requires a major overhaul of architecture, which might be an issue.

If you can share a reproduction project it would be great. I will be able to help better if I knew what packages you are importing and how we can fix that

[peterimg]

I just got the scene. But all the rest mentioned above are also there.

I do not have any light and I got it. I do not have any imported Mesh But I do have Bones.

I was thinking this modular thing will be separating the stuff we do not use.

I like the idea of having an initial boilerplate depending on what you will use I do not mind.

But now I got imports that I was not aware I’m bundling in even.

There is a way to get down to gzip 120kB apparently but I can’t get any lower than 340kB. But I see in my bundle stuff that I definitely now use at all.

What to do with this?

Regards
Peter

[RaananW]

Have you read our tree shaking documentation and the caveats?

Yes, it should work as you describe, but since we are backwards compatible, and always backwards compatible, it is hard to change the architecture without breaking things.

We are planning on creating a new package (esm) that will be independent and support full tree-shaking. Until then, these are the limitations of the packages we provide.