OK, it's just happened for the second time today. It seems to be happening more frequently with yesterdays build of Blender 4.1.
Here's the error:
bpy.data.scenes[settings['Scene_Name'…ps, I'm not sure if it's related to the bug, but the final render in 4.1 took 37 minutes, whereas in 3.6 the identical file/settings took 23 minutes to render (1000 samples no adaptive sampling)
skipping which step resolved the bug please?
Hi, sure I'll try again, the crash log is already attached by the way 👍
OK, I found the cause. The file was designed for Blender 3.6, I first tested in 4.1 as I understand scene's are always forward compatible (usually), I forgot I'd saved it before trying in 3.63,…
Incidentally, the next two times I try and start Blender, it takes AGES to start, third time it's back to opening immediately. I notice this is usually the case after a Blender hard crash.
by the way, if you add a breakpoint prior to the line that throws the error, checking the render layer node for scene.001 will show you that there is a socket present with name 'Vector' and also…
OK, I've been wracking my brain cell, and no matter what I do, I can't replicate the issue from script which is run from Blender's script editor.
So to demonstrate the problem, I've cut down…
I'm wondering if it might be an issue if the blend file was originally created in a different version of Blender. I can't remember if I had done that or not.
This is extremely strange.
I'm now not getting the issue with virtually identical code in the attached blend file, but I'm still getting the problem in the blend file I originally attached…
hmm, perhaps it previously was evident in the UI but python was still able to access the sockets. I'll do some further testing and create a new example file if necessary.
Hi, thanks for looking. Yes I can confirm that the issue has never arisen prior to my first noticing it with 4.1.0. If it's now happening with 3.65 then that would indicate whatever code change…
ah, so it's a black and white heat map then, rather than a sample count map. got ya. No way to use it to find the sample count 👍
Cool, well hopefully the sample pass being wrong below 16 samples will be considered a bug so someone looks at it. Thanks again👍
ah thanks. Why can't the samples before the first adaptive sampling noise check contribute to the debug samples pass? Guessing it must still know how many samples it's done prior to that?
I suppose the real question is, why is it now necessary to add a transparent BSDF to prevent the volume rendering black if there's an AOV node, when it wasn't needed in 3.6.