Texture not preserved on MeshLibrary generated from scene

[rcorre]

Godot version

4.0.2.stable.arch_linux

System information

Arch Linux

Issue description

When placing tiles on a GridMap, the preview shows the mesh texture, but the texture disappears as soon as I place a tile.

The tile with the wood texture is the one I'm currently placing. The gray tiles are ones I've already placed. This only happens in the Compatibility, not the Forward+ renderer.

Steps to reproduce

1. Create a scene in blender with a textured mesh
2. Open the scene in Godot, save as .tscn
3. Either choose "Scene > Export as MeshLibrary", or create a new MeshLibrary and select "Import from Scene"
4. Assign the MeshLibrary to a GridMap and try placing tiles.

Minimal reproduction project

example.zip

[smix8]

You activated vertex color in your material for a mesh that does not have vertex colors and the default vertex color is black.

The preview hides that problem cause the selection mesh uses a special unshaded material.

[rcorre]

Hmm, that's odd. I imported directly from blender and didn't change anything. Is there any way to import a material from blender and not enable vertex colors? The option vertex_color_use_as_albedo is checked but grayed-out.

FWIW, the scene looks normal if I view it directly (i.e. if I open the blend or tscn file as an inherited scene). The issue is only when used as a MeshLibrary.

[smix8]

Because your base scene uses a dedicated mesh which provides a lot of hand-holding and auto-fallbacks with missing properties or fills them with beginner expected defaults (just use albedo) instead of rendering defaults (black).

The GridMap scene with a MeshLibrary renders with a MultiMesh. MultiMeshes, to achieve their performance benefits, are very rigorous when it comes to material / mesh properties.

[rcorre]

Would it be considered a bug that the blender export/import sets vertex_color_use_as_albedo with no vertex colors?

[Calinou]

Would it be considered a bug that the blender export/import sets vertex_color_use_as_albedo with no vertex colors?

It wastes some performance to enable vertex color as albedo when the mesh lacks proper vertex colors (especially on complex meshes), but it's technically not a bug. When importing a glTF scene (which the .blend import uses under the hood), we can probably check if any vertex color is different from the glTF specification default before enabling vertex colors on a given material.

That said, I think we should fix the source issue – default vertex colors should always be opaque white, regardless of whether you're using Mesh or MultiMesh.

[smix8]

I think the material flag for vertex color should not be auto-set when it is not present on the imported asset.

I also remember this being a common issue in Godot 3 where Blender / GLTF imports would have completely unused or even wrong material properties for vertex color or transparency enabled all the time because it failed to make sense of a more complex shader node. I just got so used to never using inherited materials that I forgot this was still a common issue.

[uguu-org]

I just ran into this, and smix8's comment fixed it for me (uncheck "use as albedo" for mesh that is used in gridmap).

left = cursor for GridMap cell that is currently being placed. middle = placed GridMap cell. right = mesh not instantiated from GridMap.

Curiously, the missing texture only happens with Compatibility renderer. In Forward+ renderer they look identical.

[rcorre]

Curiously, the missing texture only happens with Compatibility renderer. In Forward+ renderer they look identical.

Ah, you're right. I forgot I was in Compatibility for this project. I can't repro in Forward+.

[bitsawer]

Thanks for the report! This seems to be a duplicate of https://github.com/godotengine/godot/issues/74111, so I'm closing this to consolidate the discussion into one place as that issue is the older one (and has a cool racetrack test project).

As noticed by users in both issues, disabling vertex_color_use_as_albedo should fix the issue in Compatiblity renderer. The issue seems to be caused by an implementation difference between OpenGL and Vulkan renderer MultiMesh.