#lunaticsproject — Public Fediverse posts

Film making is a constant tug-of-war between "artistic perfectionism" and "get it DONE!"

Sergei's lip-sync in LA-6-A is maybe a little too subtle. I could go back and increase how much his jaw moves... ​:unsure_fry:​

Or, I could say "eff that, print that baby!" ​:kermit:​

https://tv.filmfreedom.net/w/r5KusHQtedmZgjRWVXq4gy

#LunaticsProject #Animation #Blender3D #OpenMovie

And if we ever make it to episode 5, we'll be joined by our scientist character, of the Lunar Field Geologist variety, Dr. Sarah Allison. Also noted for her experience at lunar EVAs and spacesuit testing.

This was all supposed to go so much faster in 2012... Ah well... the woes of no-budget production.

#LunaticsProject #OpenMovie

https://lunatics.tv

Hiromi Lerner was a musician and a medical student. Now she's a paramedic and a nutritionist for a Moon Colony.

And a Mom, as we see in the pilot episode of "Lunatics!"

Re-rendered to (I hope) loop properly, and with simple text wartermark.

#LunaticsProject #OpenMovie #Blender3D #NPR3D

lunatics.tv

Worked on the Project History articles for the last 2-3 days.

I found this timeline I had made in 2016, but didn't seem to have posted. So, I've posted it now. As with the rest of the "Summary" category articles, I back-dated it to the time it applies to, rather than when I actually posted it, which was just now.

I waffled over how to handle that, but I think the back-dating is the right way -- it's less confusing. I always give the back-dated articles times in the last few minute of the last day they apply to -- usually 23:55 (originally I used 00:00 but that technically put them on the next day, which confused matters, so I changed them).

I'd like to have a coherent record of all this. Documentation is part of the point of the project.

https://lunaticsproject.org/2016/01/10/lunatics-project-timeline-2009-2015/
#LunaticsProject #ProjectHistory #Timeline #OpenMovie

The truth is, not only is there the matter of simplification for easier telling, there's also the point that I don't always remember the correct order, or the various dead ends along the way.

I actually have a pretty compartmentalized memory of these things. I guess it's a little like the "method of loci" / "memory palace" thing -- if I'm in the right place in the project, I can recall the history of that piece. But not always pinned to realtime dates, and so it can be hard to remember whether character A existed before set B or not.

But I guess that's a good reason to be writing this stuff down! #LunaticsProject #History #ProjectHistory #OpenMovie #FilmMakingForLunatics

There is a lot to be said for the simpler approach. But there is also value in showing that it wasn't really that neat in practice.

There were plenty of false starts and ideas that I scrapped along the way.

Also, although Andrew Pray left because of other commitments, and I decided to get more fussy about staying on model-sheet after that, his model of Georgiana's spacesuit is still with us!

#LunaticsProject #History #ProjectHistory #OpenMovie #FilmMakingForLunatics

It is kind of hard to force a history into a comprehensible story.

I made this slide of the development of the character "Georgiana Lerner" in 2015 for a presentation. But there was a bit of a lie here for the sake of simplicity.

Prior to commissioning Daniel Fu, I tried out MakeHuman, with predictably uncanny results.

And before Bela Szabo made the model in the progression slide, there was the version of Georgiana that Andrew Pray created during the Summer 2012 Sprint, which we ultimately scrapped, for various reasons.

#LunaticsProject #History #ProjectHistory #OpenMovie #FilmMakingForLunatics

Writing a personal project history, with all the ups and downs is pretty emotionally draining. I relive the whole roller coaster ride of successes and failures. But I do think it's important to record it.

I have now published four of the proposed seven-part series on the history of the "Lunatics!" project, which will probably become the backbone of a book I plan to write about it, to be called "Film Making for Lunatics":

1 - Inspirations & Origins
https://lunaticsproject.org/2023/07/05/project-history-1-origins/

2 - Vision
https://lunaticsproject.org/2023/08/06/project-history-p2-vision/

3 - Launches & Misfires
https://lunaticsproject.org/2023/09/06/project-history-3/

4 - Fixed Media Publishing
https://lunaticsproject.org/2025/10/12/project-history-4/

As you can see from the dates, it's taking me awhile.

I've started on part 5, "Soldiering On", but it was just an empty page, so far! In this one, I plan to document the initial attempt to continue the project without funding, running on vapor, as it were.

Part 6, "After the Fire' is to be exactly what it says -- picking up the pieces and continuing after a fire damaged our premises and my computer in 2013.

and Part 7, will hopefully cover the final stretch to releasing Episode One. Which is hopefully going to happen Real Soon™
So that'll probably be the longest time period covered, although not necessarily the longest article.
#LunaticsProject #History #ProjectHistory #OpenMovie #FilmMakingForLunatics

I've gotten bogged down in NLA Editor mechanics, so I've decided I'm going to have to do a little simplified learning project to make sure I understand how the various settings on action strips interact.

Tutorial time!

Going to actually make some effort to film & screencast this one better. Basically a tutorial, but it's going to be kind of unscripted and open-ended, because I'm not sure how it's going to end, either!

Should be exciting. Or at least interesting.
​:huh:​​:ani_dunno:​

I think I have a plan. Going to start setting up for it tomorrow.

I guess this could also count as my "monthly project", so a return to that, too. #LunaticsProject #Tutorial #Blender3D #NLA #Animation

Worked on the Lunatics release page CSS a little.

I had noticed that the page works very poorly on e-ink devices like my InkPad 3 Color reader's browser, because of the animated background effect, which I'm still pretty attached to.

It moves pretty slowly, but it still created updates with constant flickering as my e-reader tried to keep up.

Of course, the page is really designed to distribute or stream video, so it's normally intended for full-motion video browsers. The video is never going to work right on an e-reader.

But there's also credits and other text information on the site.

So, I looked up methods to fix this with CSS media queries, and I think it's fixed now.

It now only animates if the browser reports media type "screen" and feature "update: fast".

And this correctly suppresses animation now on my InkPad 3 Color e-reader. If you happen to have a similar device or other oddball browser, I'd be interested if the page is working for you.

Still working on honoring other parameters like "prefers-reduced-motion", "prefers-color-scheme", and "prefers-contrast". I would like to get those working as well.

Ultimately, I may add a Javascript button to change the behavior manually, but the page currently is HTML and CSS only to keep it lighter weight.

I did also test it in a text-only browser, w3m, where it looks pretty correct. Haven't tried other ones.
#LunaticsProject #WebDesign #CSS #MediaQueries #Testing

Timing is so critical in animation.

And visual storytelling in general, I guess.

I've decided I want to let the length of the episode grow slightly, but how best to use the extra time..? Without tripping up the pacing..?

🤔

I did feel that the mission control room was being underused a bit. So I'm giving it 20 or 30 more seconds in this edit, with a couple of moving camera shots to take in a bit more. Of course, that will also require retiming the audio again. #LunaticsProject #Animation #Directing #Timing

I'm still working on editing the files for May, so that'll be awhile. I decide to backdate the summaries to the end of the month they apply to, rather than when I post them (which was today!). #ProdLog #LunaticsProject #Summaries

And then April, where I tackled the enormous tangle of the "Suiting Up" scene, which has been a worry for me for years now. The new version is much more complete and closer to the original concept.

https://lunaticsproject.org/2025/04/30/april-2025-summary/
#ProdLog #LunaticsProject #Summaries

And March, which continues the compositing madness, as well as fixing a troublesome set, recovering some lost animation, and putting that all together.

https://lunaticsproject.org/2025/03/31/march-2025-summary/
#ProdLog #LunaticsProject #Summaries

Catching up on my project / production summaries for my production log, I just added February 2025, which features me figuring out how to do the compositing, and, in particular, to get rid of unwanted lines from Freestyle that show up occasionally.

https://lunaticsproject.org/2025/02/28/february-2025-summary/


#ProdLog #LunaticsProject #Summaries

Well. This is acceptable. The ceiling texture really wasn't all that important, anyway.

I think this was the main problem keeping me from using 2.79 for the "Press Conference" and "Suiting Up" sequences.

Tomorrow I'll animate a "Set Tour" as a test, and then move on to checking/fixing the shot files.

G'night! #Blender3D #LunaticsProject #BugHunt

Specifically, the texture controls "Geometry Normals", and turning that off makes the problem go away -- although it also trashes the appearance of the ceiling. I'll have to find a different way to do it.

So basically, I've got to the bottom of the mystery. Though I don't know why Blender 2.79 triggers a memory allocation error when processing geometry normals. I would've expected that to be a tested feature.
🤷 #Blender3D #LunaticsProject #BugHunt

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. ​:success:​

I suspect it's because of this:

Switching to fully guarded memory allocator.

#Blender3D #LunaticsProject #BugHunt

So, no. It DOES sometimes happen on the first try. It's probably random. Does seem to only show up when a Freestyle pass is evaluated -- doesn't seem to matter whether that's on a separate RenderLayer or not (tried both ways, no noticeable difference in frequency of crashes -- but if Freestyle is disabled, it will go at least 20 tries without failing, which I'm calling a negative result, because that's about the limit of my patience).

I've started using the "--debug" flag, and I always see lines like this right before the crash:

DM_generate_tangent_tessface_data: Updated tessellated tangents of dm 0x7fa59907e038

I have only the vaguest notion of what this actually means. I think it's preparing the mesh for rendering, somehow.

The hex number is not consistent between renders, but there are usually multiple lines referring to the same number. I assume this is a memory address for the affected object. It doesn't seem to be a fixed reference in the Blender file, though, because it's not the same between renders.

Is this a Freestyle thing? It kind of sounds like a shader thing, but IDK. When I had "--debug-all", there would be a "FREESTYLE" banner before it, but with just "--debug" I don't get that. Not sure which setting determines that, but "--debug-all" produces a LOT of output.

The failure is typically very early in the render. I don't think it is actually associated with the duplicate edges warnings -- in fact, I think those were left over from the previous successful renders. I don't see them in the cases when it crashes on the first try.

​:huh:​

So, I'm going to start trying this on the command line, rather than with the GUI. See if it still happens.

Initially, I'm just going to render with "-f +0". That should render just one frame at a time in the same process. If it happens randomly there, then that's pretty good evidence it is indeed random.

If it's a cumulative problem, then running short animations with "-a" should trigger it, because then it would be running in the same process. This would support the "cleanup bug" theory, but I'm not sure I haven't already disproved that.

🤔 #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! ​:ani_dab_l:​
#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

Hunting the frumious bandersnatch...

SOMETIMES, this shot crashes Blender 2.79. Sometimes it does not. I was careful this time, and made sure to save the camera angle prior to rendering.

Freestyle is on, so far, but it seemed to happen prior to running Freestyle. No change in PoV.

What invisible monster lurks in this rather plain looking set...?

The most problematic thing I can see is that the camera is clipping a foreground object.

I had two crashes in about 8 tries, so call it 1/4 of the time.

I need to fix something, but what..?

After a few tries I get a crash and a backtrace:

# Blender 2.79 (sub 0), Commit date: 2018-03-22 14:10, Hash f4dc9f9d68b

# backtrace
blender279(BLI_system_backtrace+0x20) [0x1a6c700]
blender279() [0x1078395]
/lib/x86_64-linux-gnu/libc.so.6(+0x38dd0) [0x7f7d3e25ddd0]
blender279(BKE_mesh_tangent_loops_to_tessdata+0xcb) [0x180992b]
blender279(DM_generate_tangent_tessface_data+0x246) [0x17416d6]
blender279() [0x13e643b]
blender279() [0x13e9134]
blender279() [0x13ebf8d]
blender279() [0x13ec652]
blender279(RE_Database_FromScene+0x1b1) [0x13ed4f1]
blender279() [0x1404802]
blender279() [0x1404d18]
blender279() [0x140814a]
blender279(RE_BlenderFrame+0xbe) [0x140879e]
blender279() [0x134a121]
blender279() [0x10887ba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7) [0x7f7d3ea4cea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f7d3e320acf]

​:blender:​👀
Unfortunately, this means very little to me.

Maybe see if it crashes with Freestyle turned off... #Blender3D #LunaticsProject #BugHunt

Editing this latest batch of screenlogs is a chore (just about halfway through December, now). I worked a lot of longer days, so there's a lot of footage. Also, when I'm doing a lot of rendering, there's more task-switching, so more edits to make to summarize it.

But these will among the most valuable ones for estimating my maximum real output.

I'm hoping to get a useful number for estimating production time on episode two, then follow through with that and see if I can't actually get it done in the predicted time.

It'd be a real confidence builder if I could. #LunaticsProject #Management #Screenlogging #Estimating

I added two more cameras last night.

I could create a separate scene in the file for each camera/shot, but when I did the (very complex) "Press Conference" sequence, I minimized the waste by using the VSE to select only the shots I wanted to render -- the intervening spaces just got filled with black.

That was important, because each fully-rendered frame takes minutes of time, so if it's not going to be in the show, then I probably don't want to burn the cycles rendering that.

But the empty black frames, while they do take up some space, are a simple way to keep the frames in alignment, which saves effort during the editing phase.

OTOH, if you cut too close, then you eliminate the ability to make directing choices in the editing phase. So it's kind of iterative.

Not sure how many total I'm going to create, or if I'll use the same approach. The multicam really shines when you're doing dialog and you need to cut back and forth between shots of the participants in the dialog. #LunaticsProject #Blender3D #Multicam

If you're really curious about the multicam thing, I did one of my 2015 "Two-Minute Tutorials" about it:

https://tv.filmfreedom.net/w/sVUpiXLXm7gERi2xJkHqZn

#LunaticsProject #Blender3D #Multicam #TwoMinuteTutorial

(I am NOT actually asking for help to solve this, and I haven''t given enough information in any case. I'm sure I'll manage. This is just to give you a peek at what I'm working on).

However, if anyone feels a desire to chime in with an explanation of why the Blender Internal "Shadow" pass generates intense colors like this red, that might be helpful. I have never understood what's going on with that!

Also, this clearly shows that the shadow pass is the culprit. It seems to be because these are "shadeless" objects. But it's not what I would expect it to do. I would expect those areas to have no shadow, or possible for the alpha layer from the shadow pass to mark them as 'transparent' so that it would have no effect.

But if I break out the alpha from the shadow layer, it's all 100% opaque. So IDK. 🤔 #Blender #Compositing #InkPaint #NPR3D #LunaticsProject

I just rendered a better example. And I have some breakdown for it.

The first image is the "pre-composite" -- that's a PNG image that I spit out of the rendering process to give a quick look at the way things are going, using the default ink+paint compositing.

The 2nd image is the "base color" image. This has some of the render passes (shadow, in particuler) missing, because they are stored in separate layers in the output EXR image.

The 3rd image is the base "ink" image, against a white background for clarity (the ink layer is actually transparent). There is some compositing magic that removes the ink lines for stuff that should be "behind" the billboard characters.

The "real" output from my renders is a "Multilayer EXR stream" -- that is, a long series of numbered EXR image files. This format can store multiple image layers that can then be tweaked and assembled during the compositing phase.

What I normally have been sharing are the "pre-composite" PNG images, which are really just a preview I generate during rendering, using a default compositing setup.

#Blender #Compositing #InkPaint #NPR3D #LunaticsProject

I lost some intermediate data awhile back, so I'm having to re-render some shots to get started on my next sequence, before I can finish more improvements, but it's getting closer.

Some more work-in-progress test renders.

#LunaticsProject #OpenMovie #Blender #NPR3D #InkPaint

Although there is still animation and rendering to do, I am starting to think about my compositing pipeline.

Our basic look design is based on "ink" (rendered by Blender-Freestyle) over "paint" (rendered by the Blender Internal "Toon" Renderer), simulating the appearance of celluloid animation.

The Blender Internal renderer is why we're still using Blender 2.79. This will probably be replaced by Eevee in later episodes, once we've worked out a good appearance.

These will be put together, but both processes are subject to some errors that I would like to clean up -- ideally being able to work on ink and paint layers separately.

And there's also the possibility of adding some 2D flare to certain shots. For example, it should be possible to put an "antique" effect on the paint layer, or simply fade it, for effect. This could even be done with a mask to create a "vignette" look. Or we could alter the color of the ink layer (perhaps to improve contrast with dark shots, etc).

These will likely be done with a combination of traveling-matte masks created with Blender's "Movie Clip Editor" and drawn-on animation with "Grease Pencil".

I don't know much about Grease Pencil... yet. So that's on my agenda for this month.

https://tv.filmfreedom.net/w/eNw5Nq6qEFpHtUk8SboHBF
#LunaticsProject #OpenMovie #Blender #NPR3D #InkPaint

Taking a little break after a whole lot of IT work on the new "virtual studio" platform for the project. I'm now doing some long-awaited hardware maintenance and cleaning up my workspace.

The Project source repositories are now back online, in a much more accessible way, via Gitea:

https://src.filmfreedom.net/LunaticsProject

It's no longer necessary to go through hoops to get your browser to go there -- I have a proper HTTPS certificate setup, as opposed to the self-signed arrangement I had with our SVN/Trac site before.
#LunaticsProject #OpenMovie #Blender3D #VirtualStudio

Finishing up our 2022 "Virtual Studio" site launch this week!

The whole year will be a bit of a shakedown, but the major elements are in place, now, with the hub (which uses Wordpress) at

https://lunaticsproject.org

And of course, you're already reading our main point of contact with the Fediverse, using Misskey.

We also have a Gitea server for production source files and a PeerTube server for releasing our video content, so we are mostly back to self-hosting again. I do intend to cross-post videos to Vimeo for the time-being, just in case there are performance issues with our PeerTube site.

#LunaticsProject #OpenMovie #Blender3D #VirtualStudio