Not loading add-ons was one of those things I always thought seemed like a good idea, but wasn’t sure if it would break something. But there are quite a few add-ons now that cause Blender to fail when run without a main window, so not loading them is the better default action to take I think.
If you can find an example of parts missing I would like to see it… It’s certainly possible if multiple passes are being combined into an image, or multiple objects, that data could be go missing. It’s probably not a bug in the add-on, but rather a problem with memory management and what happens to textures in memory when you run out of memory… I would have to save each texture to a temp file in that case.
Been using the updated version for a few days and I noticed a possible bug. When I use 32 Bit Float and 16 bit depth values my textures do not have their RGB values baked properly. If I uncheck 32 Bit float the baked RGB values match what I expect (even with 16 bit depth). I also tried manually making 32 Bit image textures and baking to them, and that works as expected, so I’m trying to figure out why using 32 Bit images in Bake Wrangler is causing issues. Any ideas?
In digging around the code, I found that post_color.use_generated_float = solution.format['img_use_float'] is possibly the reason. If I manually make that False in the code than it works as expected (none of the other use_generated_float needed to be changed). Plus I’d imagine that means the actual bake textures are no longer 32-bit.
I’ve also discovered that if I use the Open EXR Multichannel format that this bug does not occur.
Hmm, I would say it’s most likely the file format being the issue… If you set the post_color to not use float then it wont have to convert 32bit colours down to whatever the format supports which will give more consistent results visually.
I think if you bake to a 32bit image then save it to a format that doesn’t support 32bit and reload it from the saved file, you should see the same value changes happen…
OpenEXR is one of the few formats that actually supports 32bit channels, so no conversion or compression has happen when you save to that format.
I think that if you could see the image the addon produced before it got saved it would look correct, then after saving to whatever format and loading it the values have been shifted.
What add-on versions are using? Just a note that blender 2.93 requires you to use addon version 1.2.4, while blender 3.x requires addon version 1.3 as changes to cycles caused a number of settings to become incompatible between versions.
Thanks for the files I will try them out and see what I get!
@Jaydead I’m not totally clear on what you want to do. Do you mean you want to have each material slot get output to a separate file? So you would have obj-slot1.png, obj-slot2.png, etc?
Ah okay, that’s not really directly supported. Since there can be a lot of materials on an object…
The material ID map should always result in the same color being assigned based on the materials name. The idea is to use that map to separate materials, but given you want to split them into colour channels, I guess they occupy the same UV space and end up on top of each other?
If they aren’t on top of each other you could use the material ID map and compositor to split them into channels. If they are on top of each other then I don’t really think there is a solution…
The problem I’m seeing is when you have the target also in the scene, it messes it up (which didn’t happen in previous versions of blender for some reason). Which is easy enough to fix…
