Podcast Summary: Blender and Godot in Game Development with Simon Thommes
Podcast: Software Engineering Daily
Episode: Blender and Godot in Game Development with Simon Thommes
Air Date: December 25, 2025
Host: Joe Nash
Guest: Simon Thommes, Lead Technical Artist at Blender Studio
Episode Overview
This episode explores how Blender Studio—a creative division of the Blender Foundation—leverages open source tools to produce 3D animation, short films, and now games. Joe Nash is joined by Simon Thommes, Lead Technical Artist at Blender Studio and a developer on the game “Dog Walk.” The discussion centers on the workflows, technical challenges, and unique pipeline developed between Blender and the Godot game engine during Dog Walk’s production.
Key Discussion Points and Insights
1. Blender Studio: Mission and Operations
- [00:00]–[03:54]
- Blender Studio has existed for around 20 years, primarily producing open projects (mainly short films) to both push the limits of Blender and directly inform its development.
- Projects function as real-world test labs for Blender’s features; the team always works on the latest main branch.
- The Studio is committed to a fully open source pipeline—including Blender, Krita (concept art), Kitsu (production), and Linux. All assets and production files are shared openly for public learning and use.
- Quote ([01:52], Simon):
“The whole concept of the Blender Studio is to support the development of the Blender software by actually testing out the features that are being developed as they're being developed.”
2. Project Cadence and Focus on Open Sharing
- [03:54]–[05:45]
- Typically, the Studio completes one main project per year due to team size and the time required for sharing resources and educational content.
- There's a recent push toward shorter iteration cycles—aiming for four projects a year, including games and reusable character rigs.
- Quote ([04:13], Simon):
“…sharing that is also something that you need to actually actively put time into.”
3. Simon’s Role as Technical Artist
- [05:45]–[07:47]
- Technical artists bridge the gap between programming and art, addressing creative problems with technical solutions.
- Involved in shader creation, tool development, and feature design/testing—particularly with Geometry Nodes in Blender.
4. Motivation and Challenges: Transitioning to Game Development
- [07:47]–[09:14]
- Blender Studio wanted first-hand experience in game development, recognizing Blender's strong presence in game asset creation.
- The project aimed to refine the interoperability between Blender and game engines, specifically Godot.
5. Dog Walk: Game Concept & Artistic Direction
- [09:14]–[13:41]
- Game Overview ([09:21]–[10:31]):
- “Dog Walk” is a short, 20-minute microgame where players control a dog guiding a child through snowy woods, focusing on relational interaction and simple mechanics.
- Quote ([10:00], Simon):
“To create these moments where people maybe accidentally at first or just find out how you really affect the emotion of the kid running around with your behavior. That's one of the main core aspects.”
- Art Style Decision:
- The team opted for a “papercraft” look, balancing stylization with the practicalities of a physically-based rendering (PBR) workflow for easier asset transfer via GLTF.
- The intention was to keep most work in Blender, maintaining focus on pipeline challenges over intricate graphics replication in Godot.
- Quote ([13:13], Simon):
“Papercraft is kind of a natural answer…it is like physically based. It's supposed to look realistic…but at its core it's still very stylized.”
- Game Overview ([09:21]–[10:31]):
6. Blender-to-Godot Pipeline: Goals and Implementation
- [13:47]–[19:11]
- Pipeline Vision:
- Artists should operate almost entirely within Blender, relying on established asset organization (collections, nesting) and only using Godot for validation.
- Focus on asset hierarchy “nesting” (assets built from sub-assets) that translates cleanly to Godot.
- Quote ([14:14], Simon):
“The artists…on the Blender end only really needed to touch Godot for validating that what they did actually looks the same.”
- Technical Extensions:
- Developed custom Blender add-ons and GLTF exporter extensions for richer metadata (e.g., collision meshes).
- Implemented user-friendly UI in Blender for collision objects, which are then mirrored in Godot via metadata.
- Quote ([17:16], Simon):
“It was very easy for us to just write metadata to the individual export nodes about the collision…write them as metadata, attach them to the node on export, and all that would happen automatically.”
- Pipeline Vision:
7. Contributions Upstream and Custom Tooling
- [19:11]–[22:21]
- Many improvements (bug fixes, GLTF exporter features) already landed in Blender 4.5; other complex upgrades (e.g., export API) are still in progress.
- Some custom code remains unique to Dog Walk and is openly published—even if not production ready, it’s available for community use and experimentation.
- Quote ([22:07], Joe):
“...you did release the source of the pipeline that you have currently...so the game itself, the code, including also the pipeline is all online for people to dabble around.”
8. Why GLTF (Not Blend Files) as Exchange Format?
- [22:31]–[24:43]
- Although Godot technically supports importing .blend files, it does this by converting to GLTF under the hood with little user control.
- An explicit GLTF export empowers the studio to manage the data and introduces a deliberate “publishing” step, which suits production workflows.
- For independent developers, direct use of Blend files might remain convenient, but for team-based projects, explicit control is invaluable.
9. Differences in Studio Workflow, Animation, and Collaboration
- [24:43]–[26:37]
- Differences in team workflow centered around animation: in games, animation must work from any viewing angle and at variable frame rates.
- The pipeline for asset creation remained mostly unchanged; most asset work was still confined to Blender.
10. Godot: First Impressions and Open Source Development Model
- [26:37]–[29:49]
- Simon and much of the team were new to Godot but found it familiar, especially due to GDScript’s Python-like nature.
- Godot’s open source development is more “democratic” and agile than Blender’s, with a larger proportion of code from community contributors.
- Blender’s development is more centralized, with most code written by employed developers.
- Quote ([27:11], Simon):
“The way they do open source development is maybe a bit more democratic…They try to solve problems if necessary several different ways with like a slightly different flavor. While we at Blender try to like keep things a bit more streamlined.”
11. Selecting Godot and Dismissing Blender Game Engine Fork
- [28:23]–[30:59]
- Chose Godot due to team interest, accessibility, and relevance in the open source game dev community.
- Considered—but ultimately passed on—the Blender Game Engine fork (UPBGE), aiming instead for a solution aligned with broader open source adoption.
12. Surprising Features & Extensibility in Godot
- [31:07]–[34:41]
- Godot’s extensibility for tooling impressed Simon: you can write game or editor tools using GDScript and integrate natively.
- The engine’s “signals” system (event hooks) extends deeply, even to the editor’s file system.
- This level of customizability for workflow and automation was not possible to the same degree in Blender.
- Quote ([32:37], Simon):
“I've been really surprised how extensible Godot is also for tooling…writing tools for Godot for the actual development is kind of the same thing as writing the game code itself, which is absolutely true and it's a brilliant concept in my opinion.”
- Quote ([34:03], Simon):
“It opened up a whole new world that I didn't know about before...in Blender, I would have never been able to do this amount of customization.”
Memorable Quotes & Timestamps
-
On Blender Studio’s mission:
“[We] support the development of the Blender software by actually testing out the features that are being developed as they're being developed.”
—Simon ([01:52]) -
On game-to-movie animation differences:
“Animating for a game is going to be very different than animating for a film...With a game, you can't [cheat]. The player will see immediately when there's something cheated.”
—Simon ([24:57]) -
On pipeline philosophy:
“The artists…on the Blender end only really needed to touch Godot for validating…if the pipeline worked perfectly, they wouldn't really need to touch Godot at all.”
—Simon ([14:14]) -
On GLTF’s benefits:
“Having the Blend files as direct input to Godot wasn't actually very useful for us because we would make a custom pipeline anyways...for us as a studio working on this, it meant giving us more control, which was actually very valuable.”
—Simon ([22:54]) -
On Godot’s extensibility:
“I've been really surprised how extensible Godot is also for tooling…which is absolutely true and it's a brilliant concept in my opinion.”
—Simon ([32:37]) -
On open source development culture contrast:
“The way they do open source development is maybe a bit more democratic, I would probably say, and more loose in terms of adding features...most of their code is actually written by contributors…at Blender it's the opposite.”
—Simon ([27:11])
Timestamps for Important Segments
- 00:00 – Blender Studio overview, open projects, public sharing
- 03:54 – Project cadence, team workflow, educational content
- 05:45 – Technical artist role and Blender feature development
- 07:50 – Motivation for Dog Walk and game-focused pipeline testing
- 09:21 – “Dog Walk” game premise and mechanics
- 11:13 – Art style motivations and pipeline-relevant decisions
- 13:47 – Pipeline vision: asset nesting, working almost entirely in Blender
- 17:16 – Custom GLTF exporter extension for collision metadata
- 19:54 – Upstream improvements vs. custom code in pipeline
- 22:31 – Rationale for GLTF export over Blend files
- 24:57 – Animation and workflow differences between film and games
- 26:37 – First impressions of Godot and open source project culture
- 28:32 – Choosing Godot over Blender Game Engine fork
- 31:22 – Godot’s extensibility for tooling, signals, code integration
- 34:41 – Reflections and episode wrap-up
Conclusion
This episode provides an in-depth look at how open source tools can be combined and extended for small-team game development. Blender Studio’s Dog Walk project serves as a case study in building robust, artist-friendly pipelines, sharing knowledge and resources, and contributing back to the open source ecosystem. Simon Thommes’s reflections highlight both the technical decisions and the cultural practices that make collaborative, open source creative production possible.
Explore further: