Thank. I tried, but still get plain red.
Just a confirmation : If I initialized nbw=1 (out of loop) and remove the first bake from the batch, I will get the correct result. Thus the cause could be some deceiving code.
(Note to other readers: this is discussion about flaw in my own modification. It is not a bug of the add-on.)
I think the issue is with how you are using the driverā¦ Changing the value probably doesnāt cause the modifier visibility to update right away. Iām not sure what you can do to make it update.
I added a message that shows:
> Output: [ResultNotImportant.png]
> Pass: [Pass (DIFFUSE)] [Mesh Nodes (1)]
> Mesh: [Mesh] [Targets (1)]
Boolean is shown: False (nbw = 0)
> Output: [HasRedAndGreen.png]
> Pass: [Pass.001 (DIFFUSE)] [Mesh Nodes (1)]
> Mesh: [Mesh] [Targets (1)]
Boolean is shown: False (nbw = 1)
As you can see, the nbw value has been changed, but the visibility of the Boolean is still false.
Wow, you nailed down the cause.
The symptom comes from the optimization of Blender.
It is too expensive for Blender to update everything in dependency tree after a value of a driver-source changes. (They called what I am doing = āabuseā 
)
The fix is to call ownerOfTheDriverAttribute.update_tag().
active_scene.world["nbw"] = active_scene.world["nbw"]+1
active_scene.world.update_tag() #<== new line
Reference: https://developer.blender.org/T63793
It works now, thanks!
Good to know!
I have discovered an interesting thing about Drivers. Normally they donāt seem to update values in the custom node tree. BUT if you link any value from the node tree as a driver to an external property it suddenly starts working?!
External properties linked into the tree still donāt see to work though.
Example steps:
I do have one more small update to fix the subsurface pass in old node trees, make the preference categories collapsible, add the āEdgeā mode to āCavityā pass and include the tile size change for emit passes (in my tests this didnāt give as big a performance boost as in the video, but it was a little bit faster so seems worth). But I would like to wait and see if anyone can find more bugs before I drop itā¦
Iām also going to report the driver thing and see if someone at Blender will fix it.
Yes I had read that subsurface is no longer supported in 2.83 and it was removed from the baking. I had also deleted all files from the previous version of bake wrangler and installed rc5 and then build a node tree from scratch in a new test scene.
Therefore I was a bit surprised to see this error message again.
Yeah, itās because the setting is still saved in your .blend file. Replacing the Pass node will clear it, but I have fixed the problem in the latest build. Just waiting to see if there is anything else I need to fix.
Unfortunately my previous āfixā only half solved the issue while also making it worse. I made it so you canāt turn subsurface pass on, but that meant you also canāt turn it off it was saved previously as being onā¦
Actuallyā¦ I can give you a code snippet to run in blender to turn it offā¦
import bpy
for tree in bpy.data.node_groups:
for node in tree.nodes:
if node.bl_idname == "BakeWrangler_Bake_Pass":
node.use_subsurface = False
So Iām getting nonsense results for GPU baking on my 1080Ti. CPU works fine. Is GPU baking currently broken?
Also, what happened to the usual baking UI in the latest 2.90 builds?
There shouldnāt be any problems with GPU. Does it work when you render a scene normally in Cycles with GPU? The only issue I can think of is if your GPU isnāt set up in Blender or maybe if the settings werenāt saved. (Though if this is in b2.90, there could be any number of issues)
Iām not seeing any thing different in 2.90 to usual?
I have a 2080Ti and baking with GPU in Blender 2.83 works for me.
Yeah, normal rendering works fine on GPU, itās just baking thatās affected.
Also, anyone know a way to make Node Wrangler spit out the Curvature bake as a linear image directly? With neutral grey at 0.5?
Edit: ah, nevermind, found it.
All I can suggest is to make sure the GPU is configured in Blender and that the settings have been savedā¦ Though generally there isnāt much if any difference in performance between CPU and GPU for baking when I test. (maybe because I donāt have a super fancy GPU)
Hey, this is an amazing tool! But I think I found an issue:
I have a model with couple PBR materials applied to it and Iām trying to bake it to one texture set. But for some reason baking roughness maps results in a really smooth roughness map and the details are lost, which is kind of stange. Does anyone know why this happens?
I mean, yeah, itās no big deal, I was just wondering if I should report a bug. Seeing as itās in 2.90 which is alpha and with the traditional baking UI just removed, I think Iāll hold off.
There are a number of factors. Firstly, do you have an Alpha value on any of your Princpled BDSFās other than 1?
If not itās probably something to do with your āColor Spaceā and or image format. What output space and format are you using?
Yeah I used Alpha to setup a custom pass to render displacement maps from two texture sets into one. That model was out sourced, so it came with the textures already.
And yeah, It works now. I just need to think of a new way to setup custom passes 
Iāve been thinking of making some different passes for Principledā¦ Where it would ignore all the inputs other than that specific oneā¦
The thing is I donāt know if itās correct to factor the Alpha into Roughness, etc for PBR. Itās what Blender does, but Iām not convinced itās what it should do?
Iām loving the potential this addon has, only it always fails the bake for me, no matter what settings or objectsā¦ Using 2.83.1 and RC5, I donāt know why itās not working to be honestā¦
Nevermind, apparently it really doesnāt like non-blender colour configs. Even if said configs have the exact same Non-Colour transform.
Something Iāve noticed, is that GPU baking is slower for me than CPU baking. I have an R7 2700X with 3000Mhz ram, vs a Radeon VII. I honestly expected the VII to be way faster.
(sorry to bombard this thread) Iāve discovered that when baking diffuse etc, any meshes included can cast shadows on the other baking meshes, giving weird baking errors unless you hide said target objects from render view.
How does Bake Wrangler do the Curvature pass? Itās kind of inconsistent and noisy no matter how many samples you throw at it, like it were a sobel filter on a normal map bake or maybe one cavity map overlaid on an inverse one, with some areas darkened where they shouldnāt be. 
Also, can we have a pass that bakes the Viewport Color of the materials? Useful as a Material ID pass for use in Substance.