Rigging and animating a bulkhead door in Blender
I like to move it
Move it! By rigging and animating the door, or at least 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, which I thought were 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 unsee it; I will always know the mistake I made. In the first part of this article series I wrote:
And this is indeed what I will set out to do.
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 edge was quickly done. The actual door I rebuilt from scratch, this time with 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 is the final version, both with the 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 I was 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 the M1 chip. This was due to the procedural materials and limitations of my system, so I assumed.
A reasonable fix would be to bake the procedural materials into 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, combining those images into one texture. Thinking about an efficient workflow, this did not strike 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 were pure magic. Now that I have gone 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, at my door.
The plan then was to "drive" those bones through a controller, keeping everything together with a set of constrains. Starting off by right-clicking on the bone's 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 their respective drivers. 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 the bones of the door, as defined by the driver's expression.
All in all, drivers felt somewhat natural — with functions and properties resembling programming to a degree, giving me a kind of familiarity.
With 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 feeling somewhat unsatisfied. I looked at a lot of reference doors, tried to tweak the animation timing, and made 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 I will continue nonetheless. Maybe future me has some good ideas for improving the animation further.
Door rigged, animation set up, time to hit export. For this, I exported an image sequence, which I then combined into a movie through Blender's 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 modeling 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 👋🏻