I was examining the model made by another person in 2.7 something. The materials were made in modular fashion, with a bunch of Mix Shader nodes used to layer glossness to diffuse and so on. It turns out that at some point while increasing node tree complexity, Cycles just fails to display the shader in 4.2. Only shows solid color. Did you observe similar effect? Cannot entirely blame it on the user, since I recall that stacking Mix Shader was a go to workflow before Principled was a thing.Did modern Cycles became worse at complex node tree support?
2.7 is pretty darn old now, and most of the nodes etc… are likely incompatible with modern cycles, which has essentially had a complete overhaul since then.
The most likely answer is that Cycles no longer supports the nodes used from that time.
I forgotto mention that file was resaved in 4+ before it got to me. And there aren’ t nodes marked red
(Surprisingly, Eevee handles this material like a champ.)
I need to stress test Cycles by stacking a bunch of Mix Shader nodes, I guess.
Some nodes continue to exist.
And it seems that nodes that have been changed since a certain version are automatically applied.
If it works well in EEVEE but not in Cycles, make sure the Material Output is not fixed to the EEVEE.
Add…
As a simple test, I used a file saved a long time ago.
It’s a bit of a complex node group, and it’s a node for pottery
There was no problem with the test. (blender 4.2)
The changed node seems to have been converted well.
On this node, the difference is a small difference in material output.
No other nodes have been examined in detail.
※ I think it might not work if there are any removed nodes or user-created nodes that are not currently in use.
And because blender 2.79 does not use EEVEE, there is no separate setting for EEVEE. 
It shouldn’t be a problem to use mix shaders. I haven’t experienced any issues with that myself even though I rarely use Principled BSDF.
It’s very easy to overuse them though. You don’t need different shaders for different properties of similar materials and it makes sense to mix whatever you input to control those properties of a single shader. You should only mix shaders when you need different kinds of shaders, not different properties of the same shader in my opinion. If it’s a complex material, chances are there is just some problem in your nodes. Can you show the nodes?
This is my guess, but you might want to examine every node with a viewer. There were couple moments where the math inside nodes changed a little (usually to fix precision errors with very low or high values) - and this can cause a node to go completely black or white. And I don’t mean Mix nodes here, rather all other. Once you discover which node is causing problems you can correct it in all materials.
I cannot share the model because owner doesn’t allow me. However, I did my best to systematise it. Setup is bizarre to say the least. Curiously enough, it works in 3.6 still, but 4.3 flat out discards some nodes.
Worst decisions are: 1) mixing together a diffuse and glossy shader by a value of a specular map to set specularity, instead of modifying Roughness of a single shader by specular map. (Changing this fragment made everything display correctly in 4.3) 2)Mixing 2 diffuse shaders + custom rust metal nodegroup, then mixing with main shader again, just to get some color details. Instead of modifying the color texture before plugging it into any shader. This did not break 4.3 Cycles, but I guess this affected performance. There are about 8 Mix Shader nodes total.
I don’t think the mix shaders are a problem. Maybe the problemscome from changes of some nodes in newer versions. Recreating the nodetree should work. But yeah, it’s a mess. Mixing same kind of shaders with different properties makes no sense, those can be replaced by mixing the input controlling those properties.
Since it is divided into three, I think we can check if there is a problem by connecting the material output to each part.
And those nodes are in groups. You can open them with Tab.
The rest doesn’t seem to have anything special.
Add…
Isn’t the displacement map the cause of the problem.
Displace wasn’t the problem. The rust shader custom nodegroup either. I already found out that it was a cluster of nodes in the “west” which is labeled Specular. The one which mixes the glossy and diffuse by spec map. Strangely enough, it was the only Mix node removing which stopped the issue. Simplifying other parts of the tree didn’t do much
I think that’s failed conversion of the data between versions. This never just happens if you use the same version for the project.
FWIW I’ve found 4.4.3 to be quite unstable, lots of crashes. 4.2.11 is an absolute workhorse though. Whenever I get a scene that just won’t render, it’s always fixed it. LTS for a good reason!
Do you mind testing it out against a complexity check? I had a similar problem a while ago, where any addition to the node setup would make the whole thing go black. Also, for no sensible reason at all. But it was a complex setup using several node groups and shading components that was there for flexibility. I don’t remember, but I don’t think I was using any Diffuse shaders in it, only a Principled with a custom Top Coat node group on top.
As it was deprecated in the first place, I have since updated it and it’s long gone.
I might try just stacking Mix nodes or something until Cycles gives up. I had an issue with custom parallax and interior mapping shaders becoming black in Cycles (while Eevee displayed them just fine). There seems to be the limit for shader operations in Cycles