It’s possible your problems are related… I’m not sure that duplicate named inputs can lock it up, but it seems plausible.
As to how you get the messed up nodes, that would happen if the auto node tree update ran on a node tree that was already the current version. Which shouldn’t happen, but obviously there is a case where it does (in your case it is renaming the R input to A and moving it to the bottom). Can you work out exactly what sequence of events causes that to happen?
Can you try replacing any of the ‘corrupt’ nodes with freshly added ones and see if that fixes the hanging issues?
I’m actually currently rewriting most of the post baking stuff to support the new output node and make space for further post process options.
You did an incredible job, making a baking system that is very handy and clean.
If I may ask, it would be nice have a node to trigger a certain baking from the compositing tree (something like “Render Layers”).
I have a quite complex scene and I’ve implemented BW in it, removing the old “bakery system” I’d made (which was a series of collections with annotations on how to bake them, very annoying method).
So, as I said, I did a lot of copy an paste, to create something like 15 baking recipes all quite similar each other.
I’ll definitively go back one by one, checking carefully all the nodes and making sure that everything is OK. I’ll let you know how it goes.
so ive recently had this problem with the plugin where it just bakes black to everything after i reopen a blender file
the node tree itself works but after a restart everything just bakes a black texture.
as far as i know this only happen in version 1.1.1 and never happend in hte previus version i had
the only way for me to fix it is to remoove all node trees and close and reopen blender again and remake the node tree.
and even that sometimes doesnt work.
the only difference i can notice is that the bake times change to like less than half a seccond wen it bakes.
That sounds pretty bad! I will need to see your log files and probably a .blend which is having the problem. I am currently working towards the next release, which changes a lot of how the nodes work. I hope to have a ‘beta’ of that up pretty soon.
In the mean time I will make v1.1.0 available to download again, if that helps…
that would help i think.
so far the problem looks like its baking a default value to the image instead of the color data and for the normal map it paints the default blue everywhere except on the actual uv islands
witch is wierd since uvmaps dont have a black value i think.
tried testing on a new blend project and still got the same resoult.
im rendering on a 2080 if that might have something to do with it and there is no difference between trying with cuda or optix
log file sinc i cant upload stuff:
down grading worked and the post where i tried to post the log files got flagged as spam.
the log files didnt realy say anything other than it not likeing optix but the resault was still the same if i use CUDA.
i use a 2080 for rendering if that helps and got 32gb of ram so i doubt the process is running out of ram
what it currently looks like to me is that i fails baking and writes a default value to the uv island area. since it makes uv masp black(ecsept the area outside the uv island) and smoothness white albeido rughness, Aoc, and the normal blender ones also turn black.
Oh, I think you might be getting the Optix background rendering problem. Does changing the bake device to CPU fix it?
If so I’m not sure exactly how, but blender seems to get ‘stuck’ in some mode that breaks background rendering when you set it to Optix. Setting it back to CUDA doesn’t fix it once it gets ‘stuck’, even if you restart.
I wrote a script to run some tests on the bug, but it turns out the script actually ‘unsticks’ it. To do so, set render to CUDA then exit blender. Unpack the script to your current blender folder and run ‘bg-test.bat’. After that, things should start working in blender again.
I need to note this somewhere, and I’m pretty sure it’s a bug in Optix… Here is the file: bg-test.zip (111.4 KB)
Of course if setting to CPU has the same problem, then ignore all that
damn thats wierd. that might explain why it sometimes work when i restart it tho i guess it just randomly gets unstuck. but baking on the cpu does not work either btw
but i guess il just stick with v1.1.0 for now only need it to do sipmle texture bakes so its fine for now.
but without it it would have taken a few houers so im happy that downgraing worked
Hi, I bought your addon and got it to work. In the beginning I had some problems which I blieve were due to the UTF-8 issues I read about above. I run it on a German Windows and this has caused similar issues elsewhere before. But then I got it to work after removing and restarting a couple of times.
I didn not get it to run on the new Blender 2.91.2 but I guess the addon is not updated for that yet.
Anyway, if anybody is wondering why it is not working you might have to downgrade to 2.91.
The crash in 2.91.2 is not a simple issue (at least to find). Sometimes it even completes the bake without crashing and it doesn’t crash in a consistent place within Bake Wrangler. So it’s happening in a thread separate to BW.
Is BW doing something to make it crash? I guess so… But it’s going to be rather difficult to find what is doing it.
So after spending 6 or so hours trying to find the cause of the crash I’m not really any closer to a solution. Avoiding ever doing something that causes the scene to update appears to maybe work, but that isn’t really viable.
This is seeming like a problem in the blender 2.91.2 release…
The thing is, a bake will sometimes complete before it crashes. So it can do everything in the script without crashing. But some other process will cause it to crash a bunch of the time before it can complete.
Hey, why is the default sample value for all maps 1? I noticed that for AO and especially thickness maps you need at least 64 samples before it becomes usable. Changing these values does also does not increase the total bake time significantly (at least for me), so maybe its a good idea to se the sample values for these maps to something higher?
There are a couple of reasons (mostly because I found people were using many more samples than they needed and the majority of passes only need 1)…
But also, the current node interface isn’t where I want it to be. So I didn’t spent a lot of time on things that I didn’t think would be that relevant to the work flow in the future. It’s also difficult to say what a good default value for samples is when talking about light path stuff.
In the next version there is a lot less messing around with settings on individual nodes. I really should have made something available by now on that front. I have something that’s mostly ready. But then 2.91.2 has crippling bugs in it and I need people to actually buy it to fund development and I have other stuff with specific deadlines to complete -_-
It’s most likely that you aren’t setting up the necessary things. For example a Diffuse pass requires lighting. If there is no light, the texture will be completely dark.
Texture baking that involves lighting is slightly more complicated and often it’s not even what you wanted to do. Many people will bake ‘diffuse’ to get the surface colour, thinking that is what it is. But it’s not.
When you bake your diffuse in Blender, it will automatically apply lighting from the any ‘world’ texture you have, materials with an ‘emission’ component as well as any lights. You can think of the diffuse texture then as the mixture of all your lighting on the surface where it would produce a ‘diffuse bounce’. This isn’t the surface colour of the object at all. It also doesn’t factor in any ‘glossy bounces’, in fact if your surface is very shiny the diffuse output will also be completely black as it didn’t produce any ‘diffuse bounces’.
Bake Wrangler is interested in producing only the texture information you actually want. So, unless you specify things that should contribute lighting to the bake (using the ‘Scene’ input) it isn’t going to include any lighting. Which means you will always get a completely black texture if you have nothing in your ‘Scene’ input and try to do a pass that captures lighting information.
The actual surface colour of the object is ‘Albedo’ (again many people confuse albedo and diffuse as being the same thing) and contains no lighting information.
Any way, if you want to just do a test bake either include lights via ‘Scene’ input or use a pass that doesn’t bake lighting data (all of the ones listed as PBR).
Making the lighting stuff more intuitive, improving the documentation and probably making some video tutorials are all things somewhat on my radar.
