Mac (Intel) + Eeeve/Metal : Possible "ignoring" of the 2nd UVmap on faces #110162
Operating system: Macbook Pro Intel (the latest before M1)
Graphics card: Intel Iris Plus Graphics 1536 Mo
Broken: 3.6.0 (latest)
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
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.
Hello there, could you provide us a file that replicates the issue?
There could be a problem with metal, but also these graphics APIs all have limitations on how many sets of vertex attributes it can send to the GPU, although unlikely having a second UV map exceeds that, a driver could behave abnormally. Could you check if your graphics driver is up to date? Thanks!
Attached is an exemple file ; (don't forget to activate the "Viewport shading")
Also are attached "bug.jpg" and "no bug.jpg"
Sorry for the ugly blue halo, I edited in the "Texture paint" the embedded texture (a confidential plan).
The orthophoto (satellite picture) is supposed to cover the whole mesh.
The texture/uvmap named "spanc" is supposed to cover only a small area (no bug.jpg).
That's the same setup I described in OP, I just MixColor'ed the 2 "image textures" node outputs (that what my initial goal)
Below the 2 pictures are from the same file, but bug=Eevee/Metal whereas nobug=Eevee/OpenGL.
I have a rather old MacOS version (11.6.2 from December 2021), but at this date my underlying MacBook Pro was already 18 months old.
I mean, I would doubt that such a common vertex attribute would have a problem persisting after 18+ months.
Anyway, I will update MacOS today or tomorrow to eliminate this possibility.
I checked with update, and the same bug happens on :
- MacOS 11.7.x.* latest (= 11.7.8)
- MacOS 13.4.1 (c) : the most up-to-date release
On those, Eevee+Metal exposes the aforementioned bug (but not Eevee+OpenGL).
ALSO : I think that before upgrading macOS, I could not select "Metal" for "Cycles Render Device" (under Blender Preferences).
(reminder : that's not an M1/M2, I have the latest Intel pre-M1, a rather beefy one at that)
Now, I am able to select (under Blender Preferences) for "Cycles Render Device" : Metal + only enable the GPU ("Intel Iris Plus Graphics") and disable the CPU ("Intel Core i7-xxxx ...")
Using Cycles with this configuration works (whilst still having "GPU Backend" = "Metal") in Blender Preferences.
In Resume, in the following configuration :
- Cycle Render Device : Metal (+ subselection of only the integrated Intel Iris Plus Graphics being enabled, and CPU disabled)
- GPU Backend : Metal
Then, the following happens under those "Layout / Viewport Shading" methods :
- Solid : has the bug
- Material Preview : has the bug
- Rendered, under Render's "Render Engine" :
-- Eevee : has the bug
-- Cycles : DOES NOT has the bug
The problem seems to revolve around Eevee + Metal.
Maybe a bug in the code of the Blender's Metal's shader implementing the shading node functionality (especially when using a 2nd UV map) ?
cc @Michael-Jones Could you take a look at this? Thanks!
=== Blender 3.6.3 (2023-09-20) (Release Candidate ?)
- Preferences / System / Cycle Render Devis = Intel Iris Plus Graphics
- Preferences / System / GPU Backend : Metal (exhibits bug !) or OpenGL (no bug)
- scene's Render Engine (it doesn't impact the occurring of the bug):
- or Cycles (with ANY combination of sub-settings :
- Feature Set (Supported/Experimental)
- Device (CPU/GPU Compute)
- Open Shading Language
=== Blender 4.0 Alpha
- Same setting than above, excepted :
- Preferences / System / GPU Backend : /!\ WARNING : This setting DISAPPEARED /!\
Same observations than before.
Excepted that up to 3.6.3 2023-09-20 RC I had the possibility to set Preferences/System/GPU Backend=OpenGL which alleviated the problem.
Starting from 4.0 Alpha, this setting disappeared (probably implying Metal) and I can no longer alleviate the problem.
This is somehow a regression considering that I can no longer choose OpenGL which did not have the problem.
Thanks for your concern,
[edited above : This is GPU Backend=OpenGL which alleviates the problem. Not Metal]
This is somehow a regression considering that I can no longer choose OpenGL
OpenGL support has been removed from blender for mac:
Not a regression :)
Re: bug mentioned in the report.
I'm not able to replicate it on Windows (blender 3.6.3 and 4.0).
I've updated the report to match the actual problem.
@Michael-Parkin-White-Apple hi, can you check?
Thanks for the report, I can take a look into this. For interest, is this reproducible only on Intel-based Mac's, or is this also occurring on Apple Silicon?
As soon as I get to see my friend (under a week) which has a M1, I will test if it's occurring on Apple Silicon.
Hi, I tested on a friend's iMac M1 w/ macOS Ventura 13.2.1
I tested all three versions (3.6.3, 3.6.4 candidate, 4.0 alpha).
The problem does NOT appears in any configuration (I've nearly tested every combination of same settings than on my Apple Intel's)
/// P.S. regarding scene's render engine = WORKBENCH :
By the way I observed a different behaviour between 3.6.4 candidate VERSUS 4.0 alpha, regarding scene's render engine = WORKBENCH
This observation is when running those two Blender versions directly from the downloader .dmg, without modifying ANY setting.
The scene's render engine = WORKBENCH display different things on the two platforms :
- 3.6.4 candidate display display some "redness"
- 4.0 alpha display everything "white"
Frankly regarding this part I have no idea what I'm doing, I did not checked other settings.
- Maybe 4.0 alpha has a different "default" setting.
- Or maybe there is a problem in one of the two versions.
I just thought I would mention this.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?