A background render is a second copy of Blender that opens a saved file with no window and renders it, and it is where the glitter in my Big Top short went missing. The glitter was a particle effect that looked fine in the open Blender session and was simply absent from the frames the background process wrote. This post is the render side of the build: the particle bug, rendering past the tool-call limit, why my review missed motion defects, and what happened when the connection dropped mid-render. The short is not finished or released. The MCP basics are in the first post, and the before and after of the characters is in the second, so I will not repeat either.
Why did the glitter vanish from the render?
The particle system existed in my live session, so the viewport showed it. The render, however, ran as a separate background Blender on a saved copy of the scene, and that process wrote frames with no glitter at all. The Blender manual says the particle cache fills during playback, which fits what I saw, but I did not isolate the exact mechanism, so treat that as a likely cause rather than a proven one. What did work: saving the simulation into the file before the detached render and then checking frames for glitter.
How do you render past a 60 second tool-call limit?
Each bridge call I observed ended at 60 seconds, and a render takes far longer, so the render has to outlive the call. Claude saves a copy of the scene, starts a second Blender on it through subprocess.Popen with a new session so it keeps running after the launching call returns, and writes output to a log. Short follow-up calls then poll the log tail. The Blender command-line render options cover the flags. Process liveness is not the finish signal: I wait for the log’s final “Blender quit” line and then run a frame-count assertion, which I first proved can fail by feeding it a deliberately short render.
Why did three still frames pass a broken animation?
My first review looked at three stills, and they looked fine while the motion was not. A still cannot show a foot sliding across the ground or an ear passing through a helmet between keyframes. So Claude audited the file with numbers instead: keyframe counts per object, overlap between the ear and the helmet, the particle emitter settings, and foot slide on the turtle. Then I built contact sheets, a grid of frames from across the clip, so a defect that lives between the first, middle and last frame has somewhere to show up. The lesson is that a sample of frames certifies the frames in the sample and nothing else.
What happens when the connection drops mid-render?
Partway through, the link between Claude and my computer dropped and Blender restarted. I do not know why [UNVERIFIED]. Because the render was a detached process writing to a log, the log and the output folder were the record of what had actually happened, rather than my memory of the session. Claude then scheduled its own follow-up checks instead of waiting on a connection that might not come back, and re-read the files before saying anything finished.
What changed in my Blender skill?
My private blender-ops skill is where these lessons go, using the same routing idea as my orchestrator post. The installed copy I last read says version 1.1.0, so the particle rule (save the simulation, then look for glitter in frames) and the measured-motion audit are additions I am writing in, not rules I can show as shipped [UNVERIFIED]. For the 2D route to video, see HTML in, MP4 out, and for why a rig comes first, rigging a cartoon mascot.
Not verified: the cause of the empty particle cache, the cause of the dropped link, and anything beyond one Mac running Blender 5.2.3. The characters live on the Lullen page, which also covers the new-tab extension. More builds are on the projects page, and the updates page has the running log.
Sources: Blender manual, command-line rendering · Blender manual, particle emitter cache.
Leave a Reply