Freeze when baking several lightmaps

[Gpinchon]

I've got a scene with 5 or 6 lightmaps and when I try baking them it freezes Blender with 30% CPU usage and 0% GPU usage, I've let it run for 3 days now and it's still frozen, I think it's safe to say it's frozen for good....

[Naxela]

That sounds strange - Are you baking with the GPU or the CPU? It shouldn't take that long for anything to bake. What resolutions, settings are you using? Could you provide a copy of the scene?

[Gpinchon]

I am baking with GPU with various resolutions up to 1024x1024 I am using a system featuring an [email protected], 32Go of DDR3 RAM and a GTX 880M 8GB Yes, I will edit my answer to include the .blend, this is a small scene I am using for learning purpose, do you want the textures too ? [EDIT] Here is the file with needed textures and used modules

[Naxela]

Hi, I just tested with the file and the baking itself didn't take very long time, but the unwrapping too a surprisingly long time, especially the pipes with the lightmapping unwrapping took quite a while. Are you using Blender 2.91 or earlier? If you turn on the verbose option and toggle on the blender/system console, are there any specific objects that it takes a long time with baking?

The fact that you say that CPU is used instead of the GPU means that the culprit could be either an issue with the unwrapping process or the denoising process (which also took quite a while on this end.)

[Gpinchon]

So the culprit might be the pipes ? I tried baking yesterday without redoing unwrapping and it worked well but the pipes texturing was indeed all broken, I'll take a look, maybe this mesh is too complex... It was made out of nurbs, which tends to generate pretty heavy meshes from my experience... Also, when I enable Lightmapper on the semi-transparent curtains, it seems to take a lot more time... I grabbed the mesh from there to try and redo the lighting. I am wondering something, does LightMapper generate UV if no UVMap_LightMap is found when "repace UV MAP" is unckecked ? [EDIT] After decimating the pipe's geometry with a factor of 0.5, the baking is now really fast, but as soon as I try baking on the semi-transparent curtains, it seems to be freezing Blender (or at least to take a VERY long time)

[Naxela]

It could be, but in general I don't recommend using the lightmap unwrapping algorithm, since the algorithm in Blender is quite slow and despite the name doesn't seem to work too well. I recommend either manually unwrapping, using the Smart Project algorithm or installating Blender-Xatlas (blender-xatlas), and using that option, since it does a great job.

Also, I'm not really sure which property you're referring to with "replace UV Map", do you mean "Remove Lightmap UV"?

[Gpinchon]

Also, I'm not really sure which property you're referring to with "replace UV Map", do you mean "Remove Lightmap UV"?

Yes that one, sorry for the confusion.

Imma try installing Xatlas just to see as default UV unwrapping methods are never quite right.

Also, did you try enabling LightMapper on the curtains and baking ? When I do it seems to freeze indefinitely...

[Naxela]

Oh I see, then I think it should generate a new UVMap_Lightmap channel.

In general, the UV unwrapping is an area where Blender could easily be improved. Also, I did try enabling it on the curtains, and while the result wasn't great (due to lightmap uv), it did finish within a reasonable time. Does it still freeze if you decrease the quality to Exterior Previz and set the resolution scale to 1/4 or 1/8?

[WhiplashD]

I'm not sure if i should open my own issue but I'm having the same problems. Sadly I cannot get your lightmapper to work on any scene more complex than a few simple objects out in the open. It seems to randomly freeze on lightmapping one of a few dozen objects in my current scene with little rhyme or reason. I thought it had something to do with lightmapping glass shaders or emissive shaders but it still freezes.

Specs: i7 11700f, 16 gigs of ram, gf rtx 3060. Specs don't seem relevant here as the program almost immediately freezes and stops utilizing system resources.

I'm not sure where i can upload my blend file but its something to take a look at maybe.

[Naxela]

Hi,

If you turn on verbose in the general settings panel, and look turn on the system console from within Blender before you bake the lightmaps, does it say anything?

Additionally, if you don't mind, you can zip your blend file and just attach it here, and I'll take a look

[WhiplashD]

I've been watching the console log and sadly it'll get to a material and simply freeze after reporting the elapsed and estimated time. Here's the file

dance floor 2.0.zip

[Naxela]

It's really strange, sometimes it seem to be able to get stuck at the first texture, sometimes it manages the first 10 objects before it gets stuck. I seem to be able to get the same freezes when baking manually too. Not entirely sure what happens underneath in Blender, but it seems that it might be the same symptoms as what has already been reported here:

https://developer.blender.org/T82483

It seems to crash both with CPU and GPU mode, although I often get a little longer with CPU, do you get the same? In any case, I'll try to keep investigating

[WhiplashD]

Yup, tried doing 1 at a time, tried disabling some. Tried 1/8th resolution, etc etc etc and it only seemed to push where it failed further down the line.

It would crash in either mode for me as well. The GPU lasted long for me

[Naxela]

It does indeed seem to be some issue related to: https://developer.blender.org/T82483

I tested the scene out with Blender 2.83 and baked it with CPU, and it seemed to be able to bake it until the end without any errors or freezing, so most likely somewhere along the version 2.90 to 2.93 some kind of bug was introduced in Blender which causes this kind of error to occur.

I was wondering if you wouldn't mind trying out your scene with 2.83: https://download.blender.org/release/Blender2.83/ and see if you are able to bake the scene with either CPU or GPU (I wasn't able to get it working with my 3070, I don't know if there's some driver or kernel issues there).

[Naxela]

Digging a bit deeper into the problem, I found out that it might be related to an issue related to how Blender stores textures internally, that was changed in 2.90+. If I go through each and every material and delete the unconnected texture node, and unpack the packed images, it seems to be able to make it through to the end with Blender 2.93:

I guess I technically could make some sort of batch script/function which does this for you for each material, although it doesn't solve the underlying issue in Blender, it is symptom fix of sorts. Not to mention that you might actually want to use those textures later in some cases.

[WhiplashD]

Works like a charm, I'm surprised having loose texture nodes was causing it.

It seems like I spoke to soon, same blend file, when I get near the end of the lightmapping process I receive a new error - attached

I'm going to try using a fresh blendfile and play around with the materials, I think it's having issues duplicating materials cleanly when they're shared by so many objects? And it might be having issues sampling really small objects? I'm just guessing at what could be throwing out the too many samples error. I'd also get the same exact error thrown out in CPU rendering as well.

No error when using a single clean mtl in a fresh blend. I'll have to clean up material assignments I suppose .

• Wrong again lol, so if you build your lightmaps more than once your lightmapper will go crazy with material replacing and eventually cause the "X not found" error as the naming conventions start to bug out

[Naxela]

Hi,

It's good to hear that the initial error is gone/evaded, the rest of these errors seems like they might be "solvable" on my end.

I think the error with the naming convention is that there's both the original materials (they're hidden with a dot prefix and a _Original postfix, so like .Material_Original). Plus, the objects themselves has a reference to these materials, in a property called TLM_PrevMatArray, which has to be removed if you want to reset. So if you want to remove them manually, but reset by hand you can run this script - this might solve it:

import bpy

for obj in bpy.data.objects:
    if "TLM_PrevMatArray" in obj:
        del obj["TLM_PrevMatArray"]