Bake Wrangler - Node based baking tool set

[netherby]

Hi gurayg!

Changing the size of the image should work, even if there is an existing one of a different size. The steps to repeat the bug are bake at 1k RGBA targa then bake at 2K with same settings? I will try and see if I can replicate it.

The output color space should really work regardless of what the inputs are. I think the bake data is in linear space regardless, but it should get converted when saved. What image format were using for this? Targa? I think it works correctly for PNG, but I haven’t tested all the various format settings as there are a lot of possible combinations. If you set the output to SRGB and its saving in Linear then that is a bug!

As to the ‘Mask’, it allows you to combine multiple ‘bake pass’ nodes into one image output. For example if you had multiple objects that share the same UV space or perhaps if you needed different bake settings for different parts of a model. It just creates a really simple black and white ‘mask’ of the UV space and only updates pixels within the white area. There are a lot of possible reasons to use it, but it adds a bit of extra time to complete a bake.

The simple explanation is:
-No Mask = Bake replaces entire image
-Mask = Bake replaces just the pixels inside the UV islands of the low poly.

I do plan to write a user guide!

[gurayg]

Hi netherby,
I’ll write back about overwriting with different sized textures later.

I first shortly want to write about Color Space. The combination I found working is;
-Image texture that goes to bake is set to Linear (from Image texture node in material)
-“Space” is set to SRGB in “Output Image Path” node
-texture is set to Linear in resulting baked image.
Probably there are other combinations that work but this (somehow) gives results without image degradation.

I do understand the “Mask” feature now. Thanks

[gurayg]

The override texture file with different resolution error is like this.
First Output is set to targa RGBA with Albedo Bake Pass + AO Bake Passes all set to 1024.
Then you change the resolution of all bake pass and output nodes to 2048x2048.

Albedo’s Color output is feeding to Color of Output node.
Value output from AO Bake Pass is feeding the Alpha input of Output node.

Here is the console log

> Processing [Output Image Path (bakergba.tga)]
> Generating [2] passes for [2] input channels:
>  Input Meshes: 1
>   1/1: [Mesh (bake_1)]
>    -Baking ALBEDO pass: Completed in 0:00:11.517746
>
>  Input Meshes processed in 0:00:11.534746
>
>  Output Images: 1
>   1/1: [Output Image Path (bakergba.tga)]
>   - Using existing file
>   -- Resolution mis-match, scaling
>   - Writing pixels and saving image: ================================================================================
[Output Image Path (bakergba.tga)]: Background process ended
[Output Image Path (bakergba.tga)]: Bake failed after 0:00:20.068800

Error: Bake Failed

I can prepare a blend file if you need.

[unfa]

I’ve prepared a test project with a simple fully procedural material:

Barrel.blend (263.4 KB)

It’s divided into three sub-materials: Steel, Paint and Dirt. There are also two procedural masks for blending the materials together.

There are two Mix Nodes used here - one with a sharp cutoff (Paint Mask), and one with a soft roll-off (Dirt Mask).

Cycles will produce a best possible result, but this is not possible to do exactly like that with a single PBR material.

If I were to bake this for a game engine I would replace the Principled BSDF nodes with a custom Node Group, redirect each input to an Emission shader and bake Base Color, Roughness and Metallic using Blender’s Emit bake.

I’d also bake the Normals using Normal bake.

If Bake Wrangler could reproduce that result sparing the user the hassle of making the node group, reconnecting inputs etc - that’d be a huge win.

However maybe it’d be possible to extend the Mix Node or create a BakeWrangler Mix Node that’d allow extra control over how the materials are blended.

Substance Painter allows the materials to be blended as layers in different ways, I would not normally need that, but if it’s something that could be done to ease some work - that’s a big plus.

I can prepare a complete “Vanilla Blender” baking setup for this test project and provide it here along with the resulting maps for examination if that’ll be useful.

EDIT: I’ve just prepared a new version of the project to test and a lot of this stuff works as I’d expect!

Roughness and Normals work fine, producing correct results from the procedural materials and two mix nodes:

But Metallic and Base Color both produce a solid black bake:

Here’s the project file, I used Bake Wrangler 0.8 and Blender 2.81a:

Barrel 02.blend (272.5 KB)

Here’s the result of the baked maps put on the lowpoly mesh:

If the rest of the maps bake fine all I could wish for after that would be to be able to batch-bake all the passes with a single click, so I don’t have to wait until one bake finishes before starting another.
later possibly also batch-baking multiple Node trees.

The two maps that baked fine really produce an excellent result, so I think we’re on a good path here.

[Darknoodles]

@netherby
@unfa
Hey, i experienced something concerning Metallic and Diffuse/BaseColor.
The Color will render black if the material is metallic. The more metallic, the darker will be the color (up to totally black). You should use Albedo instead.

@netherby
I tried to bake with meshes sharing the same maps, but only the first is rendered, even with masks on. I tested each group separatly, and they render correctly, but no way to get them all on one map. Weird thing is that it works fine with Norma Map and Roughness, but not Albedo/Diffuse/Metallic

[unfa]

@Darknoodles I am not sure we’re talking about the same thing.

I think you’re confusing the legacy shading model (Diffuse/Specular) with the current one (PBR).

I think Blender Cycles under the hood translates the Principled BSDF into Diffuse and Glossy shaders - for non-metallic surfaces the Base Color becomes Diffuse Color, but for Metallic surfaces it becomes the Specular (Glossy) Color instead, with the Diffuse Color becoming black.

I think baking these layers from Blender Cycles would give just what you’ve described - it’s expected to work like that.

What I’m talking about is using the Bake Wrangler to bake the PBR maps instead.
In PBR we use Base Color (also known as Albedo). It’s not the same as the legacy shading model’s Diffuse Color or the Cycle’s Diffuse Color rendering pass. These are different things.

Since BakeWrangler is made fro baking PBR materials, it should handle this Base Color (Albedo) and Diffuse Color / Glossy Color confusion.

Did that make sense or maybe I have misunderstood you?

[Darknoodles]

Mh yeah i don’t know, i’m a bit tired and had to read your answer three times
Did you get you metallic working ?

[unfa]

I see
I didn’t expect any of that to work just yet - I’m testing if BakeWrangler can work with Mix nodes, not just a single Principled BSDF node. I am surprised that anything worked at all.

[sirmaxim]

left: supposed to be. Right: bake output from occlusion/rough/metallic on RGB.

Just mix rgb, math, and a color ramp to one principled bsdf. This workflow had my attention, but…

[netherby]

What output settings and file format do you have @sirmaxim?

That looks like a linear space vs sRGB space issue…

Also remember that your AO may bake differently, since Bake Wrangler will only evaluate selected meshes while the standard bake will take into account all visible objects in your scene.

Check each color channel and see which ones have a mismatch?

[sirmaxim]

png, linear. Both of those are set to linear as shown.
AO: there are no other objects in that scene, just the low poly shader ball I was testing with.
All channels have a difference. Metallic is darker than the binary 0 and 1 it should be.
Occlusion

Roughness:

Metallic:

BW setup:

[netherby]

Yep, so there is some sort of color space bug introduced with the 0.7 update. Pretty sure it worked correctly before that. I will look into it, I made a lot of changes in 0.7…

[netherby]

Actually I’m not sure there is a bug here… If you bake data as sRGB or Linear, then the values are going to get shifted.

Baking to Raw or Non-Color will give you the expected results…

I don’t think baking a value of 1 in a channel to sRGB should result in an image with 1 in that channel…?

[sirmaxim]

Ah. OK, so it’s supposed to be non-color. Understood.

Now, how about that albedo bake? Difference: shader it’s baked from is top half, bottom is baked.

Note: set to Linear it looks correct.

[netherby]

So in my tests:

Baking to sRGB produces a file where the values in each channel match the expected value, but when loading into Blender it looks too dark unless you change it to display as Linear.

Baking to Linear produces a file where the values do not match expected value…

But I don’t really understand what is going on, since color space management is handled by blender and converting between them can be fairly complicated. I’m not really sure what the correct output should be, but it seems to me that currently when you target sRGB, you get a linear file?

Do you happen to know what value some specific colors should map to in sRGB and Linear so I can at least know what the desired output is?

[sirmaxim]

You can set gamma nodes to 2.2 and 0.454 to convert inputs between them in the shader editor if that helps you figure it out.

like this:

[netherby]

Okay I see what is going on now.

Color Management -> Gamma value is getting applied to the image when it’s saved.

I have what I think is a work-around for the issue, please test this version: BakeWrangler_b0_8_1.zip

(The only way I am aware of to get all the advanced file format settings is to use the ‘save as render’ method, but using it applies the view transformation stuff which includes the gamma.)

[netherby]

@gurayg

The override texture file with different resolution error is like this.
First Output is set to targa RGBA with Albedo Bake Pass + AO Bake Passes all set to 1024.
Then you change the resolution of all bake pass and output nodes to 2048x2048.

I can prepare a blend file if you need.

Okay I have been able to replicate your error, I will look into it!

• The scaling of the loaded file wasn’t sticking, blender was resetting it to the size at load before the bake got to writing the pixels. Changing the order of a few operations seems to resolve it.

Thanks a lot for your bug report!

[sirmaxim]

Test successful! Thank you. Good to know what it was, too. I didn’t think of color management since that normally doesn’t affect baking outside of perhaps a lighting bake, which isn’t very… PBR .

As noted by others, the Mix Shader would be nice to have (and probably expected to work by most interested parties) – color and metallic bake null presumably due to not having bake types to leverage like roughness does.

One slightly annoying UX thing that probably is just saving a prop somewhere, the nodetree always starts empty when you select it in a view even though there’s only the one in the file. It does save and remain in the file, even without a workspace having it active, in which case when you open the file it says it has 0 users. Normally, 0 user data is removed from a blend file, so I’m not certain if that is a bug, intended, or what so I thought I’d mention it just in case you hadn’t encountered it in testing. Unsure what the best way to handle that is with a custom node tree like this.

[netherby]

I will look into dealing with mix nodes… So long as it’s just a combination of principled shaders and mix shaders it should be possible.

I am aware of the the UX thing you mention. I spent a little bit of time looking for a fix, but one wasn’t obvious so I decided to just get on with other stuff. It does need to be fixed, since at the very least the zero reference trees can get removed from the file when you didn’t want them to currently (though you can use fake user to stop that).