Mac (Intel) + Eeeve/Metal : Possible "ignoring" of the 2nd UVmap on faces #110162

New Issue

folays · 2023-07-16T09:25:52+02:00

folays commented

2023-07-16 09:25:52 +02:00

System Information
Operating system: Macbook Pro Intel (the latest before M1)
Graphics card: Intel Iris Plus Graphics 1536 Mo

Blender Version
Broken: 3.6.0 (latest)
Worked: n/a

Short Description
On a Mac Intel, when using Eevee + Metal backend ; (does NOT happened with OpenGL backend) ;
On a mesh plane (mostly rectangular, representing a terrain evolution, 174 k vertices, 348 k triangles).

I have 2 textures, with each its own UVmap ;
I checked the content of the UVmap, they are correct, and I was careful to assign the correct UVmap to the correct texture.

The 2nd UVmap :

Eevee + Metal : seems to be "ignored" (and the 1st UVmap is used instead)
Eevee + OpenGL : works okay
Cycles : works okay (Cycles is not configured to use "Metal" since it's not a M1/M2)

I think that for UVmaps, "second" means nothing, since there should be no particular order and/or the "order" is hidden from the user when using only shading "nodes" (except in the case of a bug being triggered...)
Especially since I explicitly specify the "UVmap node" for each "image texture" node.

Yet, the order in which I created/imported them seems to have an impact here.

By "second" UVmap, I mean the second material and/or second UVmap in the list of Object Data's properties UV maps.
(Selecting another UV map in the Object Data's properties has no effect, since I explicitly specify the UV map to use in the "nodes").

Steps to Reproduce

Open attached file
Switch to EEVEE render in viewport

bug.blend

bug	no bug

Original Report

The scene is the most simple : a mesh, and 2 materials + 2 UV maps.
I then created an empty 3rd material, being careful to apply all faces to this 3rd material.

The shading "nodes" of this material is the most simple, in reverse order :

default "material output" node
default "Principled BSDF" node
a single "Image Texture" node
a single "UV map" node (of course linked UV<->Vector, and "from Instancer" disabled)

The 2 terrain textures which I have do not cover the same mesh area (partial overlap) :

One of the textures cover the whole mesh (no more, no less) : a satellite picture (an orthophoto)
One of the textures cover a small part of the mesh : an architect plan
The UV maps correctly reflects that ;

Whatever Texture/UVmap I import first and then second, the second one seems to always be drawn with the UV map of the first, despite the fact that I explicitly select the second UV map.

Hint : If I link the UVmap "UV" output directly to the "material output" node, it seems to correctly draws the 2nd UV map colors (some square-y green + yellow + red texture, optionally some black if the texture does not cover the whole mesh).

The catch is that the problem only occurs with Eevee + Metal. It does not happened with Eevee + OpenGL nor Cycles.

I would guess maybe some bug in the Metal implementation and/or Metal shaders?

Exact steps for others to reproduce the error

Well, I used blenderGIS to import a DEM (digital elevation map : a point cloud) + some trinagulation which yield a mesh.
Then I used blenderGIS to import 2 terrain textures (one covering 1:1 the mesh, one way smaller).

Whichever of the 2 textures I import 1st, it will always be the 2nd that has its UVmap seemingly ignored.
Note : I checked the UV map content in the UVmap editor.
Note 2 : I use QGIS since 2019, I made sure that the CRS (projection) are the same for all 3 datas (DEM + geotiff textures).

Based on the default startup or an attached .blend file (as simple as possible).

My best guess

A bug in the Blender's Mac implementation of Eeveee Metal (and or /shaders) ?

Please note that my 2 textures have different coverage of the mesh, and so the UV map reflects that. Possibly the bug only occurs when it's the case.

**System Information** Operating system: Macbook Pro Intel (the latest before M1) Graphics card: Intel Iris Plus Graphics 1536 Mo **Blender Version** Broken: 3.6.0 (latest) Worked: n/a **Short Description** On a Mac Intel, when using Eevee + Metal backend ; (does *NOT* happened with OpenGL backend) ; On a mesh plane (mostly rectangular, representing a terrain evolution, 174 k vertices, 348 k triangles). I have 2 textures, with each its own UVmap ; I checked the content of the UVmap, they are correct, and I was careful to assign the correct UVmap to the correct texture. The 2nd UVmap : - Eevee + Metal : seems to be "ignored" (and the 1st UVmap is used instead) - Eevee + OpenGL : works okay - Cycles : works okay (Cycles is not configured to use "Metal" since it's not a M1/M2) I think that for UVmaps, "second" means nothing, since there should be no particular order and/or the "order" is hidden from the user when using only shading "nodes" (except in the case of a bug being triggered...) Especially since I explicitly specify the "UVmap node" for each "image texture" node. Yet, the order in which I created/imported them seems to have an impact here. By "second" UVmap, I mean the second material and/or second UVmap in the list of Object Data's properties UV maps. (Selecting another UV map in the Object Data's properties has no effect, since I explicitly specify the UV map to use in the "nodes"). **Steps to Reproduce** - Open attached file - Switch to EEVEE render in viewport [bug.blend](https://projects.blender.org/attachments/abfcaa55-1d97-49b8-bc21-6ff3a8a8b23c) | bug | no bug | | -- | -- | | ![image](https://projects.blender.org/attachments/dd2d24ea-ff56-44be-907e-2eb73a5432a7) | ![image](https://projects.blender.org/attachments/6c6daed8-81f2-4580-8440-af44371a4eae) | <details> <summary> Original Report </summary> The scene is the most simple : a mesh, and 2 materials + 2 UV maps. I then created an empty 3rd material, being careful to apply all faces to this 3rd material. The shading "nodes" of this material is the most simple, in reverse order : - default "material output" node - default "Principled BSDF" node - a single "Image Texture" node - a single "UV map" node (of course linked UV<->Vector, and "from Instancer" disabled) The 2 terrain textures which I have do not cover the same mesh area (partial overlap) : - One of the textures cover the whole mesh (no more, no less) : a satellite picture (an orthophoto) - One of the textures cover a small part of the mesh : an architect plan The UV maps correctly reflects that ; Whatever Texture/UVmap I import first and then second, the second one seems to always be drawn with the UV map of the first, despite the fact that I explicitly select the second UV map. Hint : If I link the UVmap "UV" output directly to the "material output" node, it seems to correctly draws the 2nd UV map colors (some square-y green + yellow + red texture, optionally some black if the texture does not cover the whole mesh). The catch is that the problem only occurs with Eevee + Metal. It does not happened with Eevee + OpenGL nor Cycles. I would guess maybe some bug in the Metal implementation and/or Metal shaders? **Exact steps for others to reproduce the error** Well, I used blenderGIS to import a DEM (digital elevation map : a point cloud) + some trinagulation which yield a mesh. Then I used blenderGIS to import 2 terrain textures (one covering 1:1 the mesh, one way smaller). Whichever of the 2 textures I import 1st, it will always be the 2nd that has its UVmap seemingly ignored. Note : I checked the UV map content in the UVmap editor. Note 2 : I use QGIS since 2019, I made sure that the CRS (projection) are the same for all 3 datas (DEM + geotiff textures). ***Based on the default startup or an attached .blend file (as simple as possible).*** ***My best guess*** A bug in the Blender's Mac implementation of Eeveee Metal (and or /shaders) ? Please note that my 2 textures have different coverage of the mesh, and so the UV map reflects that. Possibly the bug only occurs when it's the case. </details>

folays added the

labels 2023-07-16 09:25:53 +02:00

Iliya Katushenock added the