Loading more than eight separate images in a material slot turns the material pink (MacOS problem) #88157

New Issue

Erik G. Riebling · 2021-05-09T21:01:01+02:00

Erik G. Riebling commented

2021-05-09 21:01:01 +02:00

System Information
macOS Catalina Version 10.15.7
MacBook Pro (16-inch, 2019)
Processor 2.3 GHz 8-Core Intel Core i9
Memory 16 GB 2667 MHz DDR4
Startup Disk Macintosh HD
Graphics AMD Radeon Pro 5500M 4 GB
Intel UHD Graphics 630 1536 MB
Serial Number C02F34R5MD6N

Blender Version
Broken: N/A
Worked: N/A

Short description of error
Even when the high-end graphics card on my MacBook Pro is used, I am only able to load up to eight separate images for one material slot in Eevee. After apply a ninth one to the node chain, the entire texture turns pink and is rendered unusable.

Exact steps for others to reproduce the error
It's as simple as creating a material slot and applying a bunch of MixRGB nodes. Once one MixRGB node is connected to the Base Color (for instance) of a Principled BSDF, keep connecting MixRGB nodes in a chain in one of the two color slots. For the vacant slot of each node, create an image texture node with the image of your choice loaded and connect it to the slot. Once you attempt loading a ninth one and connect it to the lengthy chain, the entire material turns pink.

This error is not present on other types of computer setups using different OS types (i.e. Linux) and graphics cards. Also, oddly enough, the material is rendered correctly in Cycles instead of Eevee.

**System Information** macOS Catalina Version 10.15.7 **MacBook Pro (16-inch, 2019)** **Processor** 2.3 GHz 8-Core Intel Core i9 **Memory** 16 GB 2667 MHz DDR4 **Startup Disk** Macintosh HD **Graphics** AMD Radeon Pro 5500M 4 GB Intel UHD Graphics 630 1536 MB **Serial Number** C02F34R5MD6N **Blender Version** **Broken:** N/A **Worked:** N/A **Short description of error** Even when the high-end graphics card on my MacBook Pro is used, I am only able to load up to eight separate images for one material slot in Eevee. After apply a ninth one to the node chain, the entire texture turns pink and is rendered unusable. **Exact steps for others to reproduce the error** It's as simple as creating a material slot and applying a bunch of MixRGB nodes. Once one MixRGB node is connected to the Base Color (for instance) of a Principled BSDF, keep connecting MixRGB nodes in a chain in one of the two color slots. For the vacant slot of each node, create an image texture node with the image of your choice loaded and connect it to the slot. Once you attempt loading a ninth one and connect it to the lengthy chain, the entire material turns pink. This error is not present on other types of computer setups using different OS types (i.e. Linux) and graphics cards. Also, oddly enough, the material is rendered correctly in Cycles instead of Eevee.

Erik G. Riebling commented

2021-05-09 21:01:01 +02:00

Added subscriber: @E-ManAnimates

blender-admin commented

2021-05-09 21:01:01 +02:00

#95891 was marked as duplicate of this issue

Jacob Merrill commented

2021-05-09 21:32:32 +02:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2021-05-09 21:32:32 +02:00

a temp work around is to bake all the textures to a single large atlas - this makes things render really really fast as well.

(you can bake them in 1 at a time to the same large image buffer)

a temp work around is to bake all the textures to a single large atlas - this makes things render really really fast as well. (you can bake them in 1 at a time to the same large image buffer)

Erik G. Riebling commented

2021-05-09 22:23:14 +02:00

You mean apply all the textures onto a single image texture and manipulate the UVs and/or mapping coordinates? I'm actually familiar with this method. In fact, another workaround I have in mind is using Keymesh to swap the material slot of the faces. I'd rather not use either of those methods yet for two reasons.

For the first one, I discovered this problem when I was setting up this low-poly model an acquaintance of mine provided me. I was only using the model for reference purposes and would actually apply a better system of changing facial expressions later. I just wanted to use a rudimentary system for the time being.

As for the second reason, this actually applies to my advanced facial rigging system. While I won't use completely different states for eye and mouth poses, my actual idea is constructing an eyebrow out of pieces and assembling them onto a polygonal face. The system greatly employs the use of MixRGB nodes and uses alpha maps. While I discovered that I could have multiple copies of a single image texture plugged into the node chain, I simply cannot have more than eight unique image textures for one material slot. While I realize that I could place the parts of the alpha map onto a texture atlas, the problem is that I need to figure out how to effectively clamp (as in X and Y clamping) certain parts of the single image for each element of the facial feature. Otherwise, I'll accidentally show parts of the atlas that aren't supposed to show, which will have an effect on the final alpha map I'll plug into the MixRGB node. With that in mind, keeping the elements of each part its own unique image texture (with the exception of instances I could easily duplicate) is the easiest strategy.

What's even more frustrating is that my problem isn't occurring on other computer setups owned by others. They told me loading more than eight images works just fine and suspected that the problem relates to my hardware. My last resort is updating my OS to version 11.3.1 (Big Sur). I'd rather not try that as updating my OS in the past does provide erratic results. With that in mind, I was hoping the team could look into my problem before I go through with this last resort.

By the way, if there are parts of my reply that are confusing, then I'll make a video that details what my problem is along with explaining my experimental facial rig.

You mean apply all the textures onto a single image texture and manipulate the UVs and/or mapping coordinates? I'm actually familiar with this method. In fact, another workaround I have in mind is using Keymesh to swap the material slot of the faces. I'd rather not use either of those methods yet for two reasons. For the first one, I discovered this problem when I was setting up this low-poly model an acquaintance of mine provided me. I was only using the model for reference purposes and would actually apply a better system of changing facial expressions later. I just wanted to use a rudimentary system for the time being. As for the second reason, this actually applies to my advanced facial rigging system. While I won't use completely different states for eye and mouth poses, my actual idea is constructing an eyebrow out of pieces and assembling them onto a polygonal face. The system greatly employs the use of MixRGB nodes and uses alpha maps. While I discovered that I could have multiple copies of a single image texture plugged into the node chain, I simply cannot have more than eight **unique** image textures for one material slot. While I realize that I could place the parts of the alpha map onto a texture atlas, the problem is that I need to figure out how to effectively clamp (as in X and Y clamping) certain parts of the single image for each element of the facial feature. Otherwise, I'll accidentally show parts of the atlas that aren't supposed to show, which will have an effect on the final alpha map I'll plug into the MixRGB node. With that in mind, keeping the elements of each part its own unique image texture (with the exception of instances I could easily duplicate) is the easiest strategy. What's even more frustrating is that my problem isn't occurring on other computer setups owned by others. They told me loading more than eight images works just fine and suspected that the problem relates to my hardware. My last resort is updating my OS to version 11.3.1 (Big Sur). I'd rather not try that as updating my OS in the past does provide erratic results. With that in mind, I was hoping the team could look into my problem before I go through with this last resort. By the way, if there are parts of my reply that are confusing, then I'll make a video that details what my problem is along with explaining my experimental facial rig.

Jacob Merrill commented

2021-05-09 23:02:15 +02:00

ahh - for animating facial sprites - you may want to look at baking to the big texture sheet like I said,
then set the uv to the bottom left image - and use 'vector math' add - object color - then you can keyframe object color using 'constant' mode and play the animation in the viewport

this is nice because it can work with multiple copies of a actor without multiple materials

ahh - for animating facial sprites - you may want to look at baking to the big texture sheet like I said, then set the uv to the bottom left image - and use 'vector math' add - object color - then you can keyframe object color using 'constant' mode and play the animation in the viewport this is nice because it can work with multiple copies of a actor without multiple materials

Erik G. Riebling commented

2021-05-10 00:40:30 +02:00

While a big texture sheet is a possible option for animating facial textures, especially since this is the case for video games, the problem is that I see this method as needlessly ridged. You can't exactly apply any frames to smoothly transition from a happy expression to a sad one using this method if you just have a couple of frames or so. As for the matter of adding more, customizing them for specific contexts is rather difficult along with the fact that I'll need a very large image texture just to accommodate all the frames. On top of that, adding more to the sheet provides its own sets of challenges, especially if I have to apply the right drivers to a rig control.

With that said, my method of of a facial rig actually provides a lot more versatility, while using no more than about twelve unique images at most. Even though it is possible to make do with up to eight, I feel like having at least four extra images at least is a safe number. The idea is that I take black and white images that are silhouettes of basic shapes and piece them together into an eyebrow for example. Then, I could apply basic transformations to the pieces using a mapping node (along with an empty) and shape the eyebrow into whatever expression I want. Since these images are black and white, they'll serve as an alpha map for a MixRGB node's factor and will allow a sort of layering effect in the material. While I will admit this is a bit impractical for photorealistic rendering, it's suitable for NPR situations. This setup will work regardless of my hardware because multiple copies of a single image texture is not effected by the eight image limit I encountered. Still, I wish I could figure out why this limitation exists on my current hardware, which is why I got this new computer in the first place (among other reasons).

I'm glad to show you what i mean for all of what I described as long as I'm permitted to provide a Dropbox link to my video.

While a big texture sheet is a possible option for animating facial textures, especially since this is the case for video games, the problem is that I see this method as needlessly ridged. You can't exactly apply any frames to smoothly transition from a happy expression to a sad one using this method if you just have a couple of frames or so. As for the matter of adding more, customizing them for specific contexts is rather difficult along with the fact that I'll need a **very** large image texture just to accommodate all the frames. On top of that, adding more to the sheet provides its own sets of challenges, especially if I have to apply the right drivers to a rig control. With that said, my method of of a facial rig actually provides a lot more versatility, while using no more than about twelve unique images at most. Even though it is possible to make do with up to eight, I feel like having at least four extra images at least is a safe number. The idea is that I take black and white images that are silhouettes of basic shapes and piece them together into an eyebrow for example. Then, I could apply basic transformations to the pieces using a mapping node (along with an empty) and shape the eyebrow into whatever expression I want. Since these images are black and white, they'll serve as an alpha map for a MixRGB node's factor and will allow a sort of layering effect in the material. While I will admit this is a bit impractical for photorealistic rendering, it's suitable for NPR situations. This setup will work regardless of my hardware because multiple copies of a single image texture is not effected by the eight image limit I encountered. Still, I wish I could figure out why this limitation exists on my current hardware, which is why I got this new computer in the first place (among other reasons). I'm glad to show you what i mean for all of what I described as long as I'm permitted to provide a Dropbox link to my video.

Jeroen Bakker commented

2021-05-10 13:43:08 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2021-05-10 13:43:08 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Jeroen Bakker commented

2021-05-10 13:43:08 +02:00

It feels like a hardware limitation and might not be considered a bug. Can you upload the system info.txt generated from blenders help menu to make sure that this is a hardware limitation?

Erik G. Riebling commented

2021-05-10 13:51:39 +02:00

Yes, I reckon it's the hardware that is at fault here. What's very frustrating is that, besides others loading more than eight image textures just fine, I have a graphics card that is an AMD Radeon Pro 5500M 4 GB. What's even more unusual is that I toggled off Automatic graphics switching, which means the Radeon should do the heavy lifting. The only thing I could think of is switching a setting in Blender to force the application to use the Radeon for Eevee rendering. Sadly, I haven't seen an option for that right off the bat. I could share screenshots to show you were i was looking and see if you could find something I missed.

In any case, I'll provide you that document you requested.

system-info.txt

Yes, I reckon it's the hardware that is at fault here. What's very frustrating is that, besides others loading more than eight image textures just fine, I have a graphics card that is an AMD Radeon Pro 5500M 4 GB. What's even more unusual is that I toggled off Automatic graphics switching, which means the Radeon should do the heavy lifting. The only thing I could think of is switching a setting in Blender to force the application to use the Radeon for Eevee rendering. Sadly, I haven't seen an option for that right off the bat. I could share screenshots to show you were i was looking and see if you could find something I missed. In any case, I'll provide you that document you requested. [system-info.txt](https://archive.blender.org/developer/F10075504/system-info.txt)

Clément Foucault commented

2021-05-12 15:52:31 +02:00

Added subscriber: @fclem

Clément Foucault commented

2021-05-12 15:52:31 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Clément Foucault commented

2021-05-12 15:52:31 +02:00

Well it is a "software" limitation as it is the OpenGL driver that is well bellow standard on MacOS. Only 16 textures can be used in the shader and EEVEE uses ~8 of them for internal purpose. So for the time being it is an expected limitation unfortunately.

Erik G. Riebling commented

2021-05-12 16:25:08 +02:00

That's certainly frustrating... While I would like to change operating systems, I just acquired this computer and I'm not interested in swapping them so soon. On top of that, I have no idea what would carry over should I switch. Perhaps this is something I'll investigate once I'm in the market for another computer again?

With that said, you mentioned that there's a 16 texture limit. Is that for all standard computers, or is it just a MacOS limitation? Regardless, this does mean that I'll have to employ something like a texture atlas for my project Thankfully, creating multiple copies of a single texture node is still on the table. I just need to employ either some clever math nodes to simulate X and Y clamping or an elaborate mask system.

By the way, are there any ideas to resolve this problem yet, or am I expected to wait until either a MacOS update or hardware upgrade?

That's certainly frustrating... While I would like to change operating systems, I just acquired this computer and I'm not interested in swapping them so soon. On top of that, I have no idea what would carry over should I switch. Perhaps this is something I'll investigate once I'm in the market for another computer again? With that said, you mentioned that there's a 16 texture limit. Is that for all standard computers, or is it just a MacOS limitation? Regardless, this does mean that I'll have to employ something like a texture atlas for my project Thankfully, creating multiple copies of a single texture node is still on the table. I just need to employ either some clever math nodes to simulate X and Y clamping or an elaborate mask system. By the way, are there any ideas to resolve this problem yet, or am I expected to wait until either a MacOS update or hardware upgrade?

Clément Foucault commented

2021-05-12 16:42:19 +02:00

With that said, you mentioned that there's a 16 texture limit. Is that for all standard computers, or is it just a MacOS limitation?

Most have a limit of 24 or 32 textures. This is without using bindless textures which we currently do not use for EEVEE (long term TODO).

am I expected to wait until either a MacOS update or hardware upgrade?

As far as I know, every GPU on MacOS is bound to the same limit due to their lack of support to OpenGL (since Apple write the drivers). Changing hardware most likely won't fix the issue. Also do not hope for Apple to improve this limit as they have deprecated OpenGL.

Porting Blender to Apple's Metal API is a possibility to fix this shortcoming but it is not in our plans yet.

>With that said, you mentioned that there's a 16 texture limit. Is that for all standard computers, or is it just a MacOS limitation? Most have a limit of 24 or 32 textures. This is without using bindless textures which we currently do not use for EEVEE (long term TODO). >am I expected to wait until either a MacOS update or hardware upgrade? As far as I know, every GPU on MacOS is bound to the same limit due to their lack of support to OpenGL (since Apple write the drivers). Changing hardware most likely won't fix the issue. Also do not hope for Apple to improve this limit as they have deprecated OpenGL. Porting Blender to Apple's Metal API is a possibility to fix this shortcoming but it is not in our plans yet.

Erik G. Riebling commented

2021-05-12 16:50:22 +02:00

Those sound very interesting. I wish you plenty of luck as you make advancements to Eevee along with trying Apple's Metal API! Hopefully, there will be an announcement for this one you make some progress! In he meantime, I'll experiment with some workarounds myself.

Omar Emara commented

2022-09-13 12:35:29 +02:00

Added subscribers: @Piergiorgio_PG, @OmarEmaraDev, @kevindietrich

Michael Parkin-White commented

2023-01-03 11:37:31 +01:00

Added subscriber: @Michael-Parkin-White-Apple

Michael Parkin-White commented

2023-01-03 11:37:31 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Michael Parkin-White closed this issue

2023-01-03 11:37:31 +01:00

Michael Parkin-White self-assigned this 2023-01-03 11:37:31 +01:00

Michael Parkin-White commented

2023-01-03 11:37:31 +01:00

Looking through old tasks, but this issue should have now been resolved by: [D15336 MacOS: Resolve purple rendering artifacts in EEVEE materials by increasing sampler limit ](https://developer.blender.org/D15336)
Please verify if this is indeed the case.

Looking through old tasks, but this issue should have now been resolved by: [[D15336](https://archive.blender.org/developer/D15336) MacOS: Resolve purple rendering artifacts in EEVEE materials by increasing sampler limit ](https://developer.blender.org/D15336) Please verify if this is indeed the case.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Loading more than eight separate images in a material slot turns the material pink (MacOS problem) #88157