PluginMaterial Bug

There should be two boxes, but only one.

I can see warnings in the console:
[.WebGL-0x3c0582e900] GL_INVALID_OPERATION: It is undefined behaviour to use a uniform buffer that is too small.
image

I want to apply a material plugin to specific objects. So I clone the original material, apply the plugin manually. But it throws errors if I left a material without the plugin.

Some finds:

  1. Seems it throws errors only when implement getUniforms,even if I use meaningless name foo here.
  2. It may become normal if I changed the define BLACKANDWHITE value. In constructor or prepareDefines. Such as falsetruefalse0. But it overwhelmed my head and my mind is in a mess now. So cannot tell it preciously.
  3. Clone first then plugin the origin has no difference.

ps: Dev environment with auto-reload is convenient for this case. As you have to reload the tab to see the WebGL error once it disappears.

And what is the intended result when clone a plugined material?

cc @Evgeni_Popov

The code you inject in your material plugin must be conditionned by a specific #define name because in Babylon.js the shader code management is based on the #defines and their values: basically, the set of #defines used in a shader (and their values) is used as a key in a hashmap that retrieves the corresponding shader code.

In your PG, the cloned material will point to the same shader code than the first material (because their sets of #defines/values is the same), but because the plugins are not copied during the cloning process the “foo” uniform is not declared in the cloned material and you get the error you have shown above.

You should use the BLACKANDWHITE define as used in the example in the doc:

That will fix the error.

Regarding the plugins not being cloned when the material is cloned, I guess for the time being it is “by design” as it is how it behaves, but maybe it should be changed… I will let @Deltakosh / @sebavan decide about that one.

Sounds rational. So this two materials share the same shader code internally.

But even if I use the BLACKANDWHITE define in the fragment, once its default value is false, the error appears:

This PG is more like my real case:

I’m trying to animate objects looking individually. If I set directionReversed default to true, than I can get a box with plugined material and a box untouched correctly. But if I set the default to false, I lost one box. Don’t you think it is weird?
Though I can apply the plugin to all materials then control them later, I have to set the default value carefully. For example, the maskPosition should not be 0 here. Or it can still affect objects. Appling the plugin individually is more straightforward models.

On the other hand, maybe I should wrap all that logics with a #ifdef as a switch? But as I said, the ability to appling the plugin individually is more convenient.

Yes, there’s a problem with the plugin data injected into the uniform buffer that should be conditionned somehow.

I’m going to have a look.

1 Like

This PR will fix the problem:

2 Likes