3D Pinball
- Samuel Farmer

- Dec 15, 2025
- 2 min read

This pinball machine began as a concept for the landing page animation. I was able to find the dimensions for pinball machines thanks to a robust network of DIY pinball builders and enthusiasts. Everything here is to scale, including the 6.5 degree tilt of the game board itself.
As for the animation, I wanted the movement to be grounded in physics. The ball, tabletop, pop bumpers, flippers, and plunger are all rigid bodies with default gravity and the friction set to 0. The pop bumpers proved a bit more challenging. I'm not 100% happy with my solution. I set a Field Force with a cylindrical field around each pop bumper set to "change direction." Rather than collide and bounce away, the ball tends to circle the pop bumper once before being repelled. I'd spent too much time simulating and re-simulating the scene, so I moved on for sake of my own sanity. There is a repel force but it only works with box fields and that wouldn't accurately simulate the cylindrical shape of those pop bumpers.
The animation was cached then baked as an alembic.

For the decals on the tabletop itself I turned to After Effects. I could've designed these layers in Illustrator or Photoshop, but my comfort in After Effects won out. A path is a path.
For inspiration, I went back to the 1988-1989 era of Lego boxes. With the exception of the wireframe blackhole, the elements were creating using shape layers and stroked paths. The blackhole was created in C4D using a lathe nurb and toon shader which was rendered and then brought into After Effects.
All the various materials were saved as .PSD and then brought onto a texture node in Redshift.

One final issue appeared during export. I had a target tag set to the ball so that the camera would track the movement. Due to a long export, I had to pause halfway through. Upon resuming at frame 280, the render kept snapping back to frame 0. No matter what I did—manual frame range, cutting the timeline to start at frame 280, updates to both C4D and Redshift—nothing would allow the render to begin at 280. Not even rendering just the current frame seemed to make a difference.
After submitting an error ticket to Maxon, it occurred to me that the target tag might only work from frame 0. No idea why. Unlike physics sims, it doesn't need frame zero to generate data. No matter, I set an arbitrary keyframe at frame zero, then used the timeline function menu to bake the camera. Once the new key framed camera was available, the rest of the sequence rendered from frame 280 without issue.
Frustrating as these problems may be, I've come to embrace them because I tend to learn more from problems than when everything works perfectly. It's difficult to be that zen in the moment though.


Comments