[BUG] Unusual behavior of Material.setPbrMaterial() when used inside external NPM module

[MetaverseUnknower]

Issue Description:

• setPbrMaterial() works as expected from the host project
• setPbrMaterial() works as expected when using a video texture (Material.Texture.Video()) from within the library.
• setBasicMaterial() also works as expected with a common texture (Material.Texture.Common()) from within my library.

However, when using setPbrMaterial() with Material.Texture.Common() from within the library, the albedoColor gets blown out and causes a lens flare

This seems to have something to do with the metallic and albedoColor attributes. When albedoColor is changed, the lens flare changes in color. When metallic is exactly 1, the lens flare disappears. Every other number will cause the lens flare, including 0.999...

SDK:

• [ ] SDK6
• [x] SDK7

Tool:

• [x] Editor
• [ ] CLI

CLI Version:
@dcl-sdk/utils@1.1.3 @dcl/ecs@7.3.28 Node Version: v16.20.1

Steps to reproduce:

1. Create an external library and use it in an SDK7 project (clone github.com/virtuallandmanager/tree/sdk7 to use the library this was discovered with)
2. Create an entity with a plane mesh
3. Add a Material using Material.Texture.Common() and Material.setPbrMaterial()

Expected behaviour:

An image created by the NPM module shows with the correct texture settings, matching an image created within the host project

Current behaviour:

An image created by the NPM module shows a lens flare:

If bloom is disabled, image is only a white plane:

In the Mac desktop client, there is no lens flare but the image appears black even when albedoColor and reflectivityColor are set to white and emissiveColor is set to black.

Reproduction rate:

Always

Code Snippets:

Texture Options (metallic <1, albedoColor = Red):

Texture Options (metallic === 1, albedoColor = Black):

Platforms:

• [ ] Windows
• [x] Mac
• [x] Not platform specific (possibly)

Browser:

• [ ] Google Chrome
• [ ] Microsoft Edge
• [ ] Firefox
• [ ] Desktop
• [x] Brave
• [ ] Safari
• [x] Not Browser Specific (possibly)

Environment:

• [x] production - web client
• [x] production - desktop client
• [x] local preview
• [ ] web editor
• [ ] desktop editor

Evidence:

Results:

metallic <1, albedoColor = Red

metallic === 1, albedoColor = Black

Additional Notes:

Contact me on Discord at unknower for discussion or reproduction of the issue

VLM creates images through services. The MaterialService class utilizes the Material import.

The implementation can be found below:

First we build the texture options, parsing an object from an external server: https://github.com/virtuallandmanager/vlm-dcl/blob/df2551b5c7fdceb60d10c634cd538bc640c479f0/src/components/VLMImage.component.ts#L58

Then we apply the material through the material service: https://github.com/virtuallandmanager/vlm-dcl/blob/df2551b5c7fdceb60d10c634cd538bc640c479f0/src/components/VLMImage.component.ts#L218

Texture options are set within this method: https://github.com/virtuallandmanager/vlm-dcl/blob/df2551b5c7fdceb60d10c634cd538bc640c479f0/src/services/Material.service.ts#L60

Material is applied within this method: https://github.com/virtuallandmanager/vlm-dcl/blob/df2551b5c7fdceb60d10c634cd538bc640c479f0/src/services/Material.service.ts#L17

[MetaverseUnknower]

@pravusjif brought to my attention that this is actually the result of using '0' in the object's scale. In my case it was on the Z axis. So a workaround is to use something slightly higher than 0.

My observation about this being related to code within a library was incorrect. This is actually true both for objects created within a library or directly within a host project.

[nearnshaw]

@MetaverseUnknower I'm closing this issue, as it's related to the renderer and to having models with z axis = 0 We've now added a warning about this in the docs