Rigging and animating a bulkhead door in Blender
I like to move it
Move it! By rigging and animating the door, or learning how to do it first. After part one, creating the mesh; and part two, texturing the bulkhead door; I was ready to finally animate the door in Blender. Looking at what I've got so far I've … wait a second, I did the main door wrong.
On closer inspection of Ron Cobb's sketch, my wife pointed out that the shadows on the door, what I thought are extruded parts, are actually insets.
Does that mean I have to redo parts of the door? I didn't think so, at first, but the ever growing whisper of doubt crept into my ear. I cannot un-see it, I will always know the mistake I made. In the first part of this article series I wrote:
And this is what I will set out to do indeed.
New year, new … door?
Looking at the drawing again, I found another oversight — a small inset running around the edge of the main frame of the door. With the extrusions on the door, that are actually insets, this makes two mistakes I have to correct.
Taking this as an opportunity, and applying all I learned throughout last year, I wanted to recreate the main door and change the frame. While on it, I will also rework parts of my topology and fully redo my, as I know now, horrible UVs*.
Adding the inset around the main door-frame's edge was quickly done. The actual door I rebuild from scratch, this time having inset parts on the surface of the door, similar to the inner barrier doors. I also reduced the segment count on all bevels, decreasing the overall poly-count, as I want to use the door in a game engine.
Here the final version, both with extracted barrier doors and the main door closed.
Happy, knowing I did what I could to finally recreate Ron Cobb's drawing as close as possible, I was able to move on, as I already did twice in the previous articles of this series.
Stop! Render time.
While texturing the door, even though happy with the workflow provided by Fluent: Materializer, there was one thing that kept me worried: my render times. Every single render I did from the door took roughly 15 to 25 minutes on my machine, an Apple MacBook Air with M1 chip. This was due to the procedural materials and limitations of my system, so I assumed.
A reasonable fix should be by baking the procedural materials to static textures. Even though Fluent: Materializer comes with baking support, this never really worked for me. The main issue was that I was only able to bake one material at a time. In the end I wanted to have one texture for everything.
One way I could solve that is by baking every material, one at a time, and with some image processing software combine those images into one texture. Thinking about an efficient workflow, this did not struck me as a scalable approach.
Simple bake, with SimpleBake
The Blender add-on SimpleBake got my back — no affiliation, just a happy user. To use it I had to prepare some things. For one, I needed to ensure that my UVs do not have any overlapping islands; after my last rework this was easy enough and already done.
Second and last I needed to configure SimpleBake; give it a list of objects to bake, what textures to create, texture resolution, how to export, and if a copy of the objects with the applied textures should be created inside the project.
After having this set up once for the project, I can bake and re-bake textures with one click. The results were amazing — my render times went from extremes like 25 minutes to 1 minute max with the static textures applied.
Being now able to quickly render the door, my worries baked away, I could continue with rigging.
Bones and Drivers
Before I found the Drivers Master Class for Blender video series from Level Pixel Level I thought armatures and drivers where pure magic. Now that I went through that playlist, getting myself familiar with drivers, it still feels like magic, but right at my fingertips. Applying what I've learned, I threw some bones, or armatures, on my door.
The plan then was to "drive" those bones through a controller, keeping everything together by a set of constrains. Starting of by right-clicking on the bones y-location to add a driver.
In the Drivers panel I defined the "scripted expression", connected it to my controller, and added limits to the movement of the bone to drive.
For the controller I created an arrow out of a plane, to which all bones are connected by there respective driver. The arrow also gets an object constraint to limit the movement, just for my own convenience.
Moving the arrow on the y-axis will move all bones of the door, as defined by the driver expression.
All in all, drivers felt somewhat natural — with functions and properties, resembling programming to a degree, giving me a kind of familiarity.
Having the door-rig ready, I used the controller to drive the animation of the door. I know there are many ways to do this, but this way felt like a solid choice for me at the time.
Watching my animation too many times left me feel somewhat unsatisfied. I looked at a lot of reference doors, tried to tweak the animation timing, made it that parts of the door animate at different times; all to get a more natural feel of the door moving.
I'm not quite there yet, but will continue nonetheless. Maybe future me has some good ideas improving the animation further.
Door rigged, animation set up, time to hit export. For this I export an image sequence I then combined to a movie through Blenders Video Editing view.
I took the final movie of the animation into DaVinci Resolve 18, using it to make some slight color corrections.
And this is it, here is my final render of the bulkhead door animation.
What comes next?
After having the basics of rigging, animation, and drivers covered, I want to deepen that knowledge — getting more modelling experience can't hurt either. Therefore, my next step will be to model a hallway incorporating the door, add some slight VFX, and animate a camera moving through the environment.
But that will be in part 4 of the project. Until then 👋🏻