Testing the shot itself. I've moved characters around a bit, and will probably do more, and then animate the camera operators following the action inside.

Lot of nitpicks though -- interference patches, for example. Need to update the mask modifiers in the character files to fix that. And I see the clock in this shot, so I should probably check what time it should be reading.

Fun question: are the cameras too big? It's supposed to be 2040, but which will win? The voracious appetite for super-high-fidelity, high-resolution imagery? Or miniaturization of electronics and optics?

But in the end, what wins is I want you to see they have cameras... #LunaticsProject #Blender #WIP

Oops. There was supposed to be a caption on that second image:

Input is the original ink from the render. "Ink" and "Thru-Ink" have the same style. They have a "Fast Gaussian" blur added to smooth them out.

From these, I extract only the alphas ("Separate RGBA" nodes).

The "Thru-Ink" has a "Dilate/Erode" node use to shrink the ink away from edges.

Each then goes through a respective "Alpha Over" node that provides the color.

The end result is a good approximation of the originally-intended Freestyle Ink Styles. #Blender3D #LunaticsProject

Okay, I think I have salvaged the render! This is a pretty good replication, just using compositor nodes to correct the ink color and thickness. ​​

Whew!

Of course, there IS something else wrong here, but I'm hoping no one notices... #Blender3D #LunaticsProject

IT DOES NOT LIKE THIS CEILING!

Wow. Weird. It'll render if debug mode is not on, at least some of the time. But in debug mode, it consistently crashes, even if this is all I include.

I wonder why..?

Frustratingly, I can't get it to crash without the "--debug" flag, even after a couple dozen tries. With or without Freestyle. Odd. Must be a load condition that triggers it? Maybe how much RAM has already been allocated?

I think this still has to be it, though. #Blender3D #LunaticsProject #BugHunt

And another thing: now it doesn't matter if Freestyle is enabled. It still fails without it -- as long as I'm in debug mode. So maybe this is NOT Freestyle issue after all.

Repeatable crashes are SO much easier to test!

As a control, I tried rendering the default cube and then a random other file of mine with Blender in debug mode, to make sure that didn't just make it always crash.

But nope. Only this file. Also, the shot angle isn't that important. Even if I move the camera around, I still get the crash.

So NOW, I'm disabling Blender model layers. Let's see which particular things need to be there to cause the crash. I should be able to narrow it down. #Blender3D #LunaticsProject #BugHunt

Okay. PROGRESS.
If I use the "--debug" flag, it fails consistently every time!
Yay. Reproducibility. ​​

I suspect it's because of this:

Switching to fully guarded memory allocator.

#Blender3D #LunaticsProject #BugHunt

Okay. One thing I notice is that it has never crashed on the first attempt. It's always after 2 or 3. I had assumed this was just random chance, and it might still be, but I'm thinking it might be some kind of failed cleanup.

It only happens when the previous render used Freestyle, but I'm not sure if it matters that the current one does (should test that, maybe?).

The backtrace is consistent -- it's always this same message. It looks like the actual error occurs in libc6, from a call by "libpthread" which seems to be "POSIX Threads". So perhaps it's trying to grab a thread to run the render in and failing?

I know that Freestyle is unusual in Blender in that it always runs single-threaded, so perhaps there's some awkwardness in switching between threading models (???)

But of course, the nature of the bug itself isn't really want I want. I'm stuck with the software. So it's really a matter of figuring out what part of my Blender file triggers this bug.

Is it an oddball mesh of some kind? That was my first assumption.

I'm going to start hiding layers and see if I can narrow down which element of the set is triggering this (assuming it is due to a single mesh).

Troubleshooting. It's like science, but without the prestige! ​​
#Blender3D #LunaticsProject #BugHunt

Does seem to be a Freestyle thing. I rendered about 20 X w/o Freestyle and no problem. Then about 4-5 with Freestyle and it crashed again.

Also the console shows Freestyle was processing edge problems:

Warning: edge 168 - 160 appears twice, correcting
[... many lines like this ...]
Warning: edge 160 - 159 appears twice, correcting
Warning: edge 122 - 125 appears twice, correcting
Warning: edge 180 - 179 appears twice, correcting
Warning: edge 177 - 178 appears twice, correcting
Writing: Building254_AqRm-Int--279test.crash.txt
rmdir: Permission denied
Segmentation fault

Most of my renders generate some of these warnings from Freestyle. I don't really understand why, but I've come to regard them as harmless. But maybe not so harmless after all?

The weirdest thing is that it isn't quite repeatable. Suggesting something like a dangling pointer or uninitialized variable at fault. Some kind of loose cannon like that.

Also, no idea why THIS set should be sensitive.

Maybe I'll start taking out pieces of the set and seeing if that effects it.

Wish it was more repeatable. #Blender3D #LunaticsProject #BugHunt