The Blender-to-Godot Pipeline That Actually Works

·7 min read
gaminggodotblender

The Blender-to-Godot Pipeline That Actually Works

Blender and Godot make a natural pairing, and most 3D assets I bring into a Godot project start life in Blender. Not because I'm ideological about open source — though it's nice that neither tool will ever email me about a licensing change — but because the two of them have quietly become one of the smoothest asset pipelines in game development. Godot 4 speaks glTF natively, Blender exports it natively, and once you know a handful of conventions, assets flow from one to the other with almost no friction.

Almost. There are gotchas worth knowing up front. Here's a pipeline that holds together.

The 30-second version

  • Export glTF 2.0 as .glb for anything going to a team or CI. Use direct .blend import for fast solo iteration.
  • 1 Blender unit = 1 Godot unit = 1 meter. Model to real-world scale and never fight it.
  • Apply your transforms (Ctrl+A → All Transforms) before export. Unapplied scale is the #1 cause of "why is my collision wrong."
  • Name things with import suffixes: -col, -convcolonly, -noimp and friends do real work at import time.
  • Stick to the Principled BSDF and image textures. Procedural node setups need baking before they'll survive export.
  • Never edit the imported scene directly. Use inherited scenes or extract materials so reimports don't eat your changes.

Why this pairing works

Godot's native scene format and glTF 2.0 are conceptually close — nodes, meshes, materials, skins, animations. There's no proprietary intermediate format, no plugin that breaks every engine update, no per-seat licensing math when a client's team grows. When Blender 4.x updates its glTF exporter, things generally just keep working.

The practical upside: I can hand a client a folder of .blend files and a Godot project, and they own their entire pipeline forever. That's a genuinely rare thing to be able to say.

Two import paths: .glb vs .blend

Godot 4 gives you two routes into the engine.

Direct .blend import. Point Godot at your Blender executable (Editor Settings → FileSystem → Import → Blender Path), then just drop .blend files into your project. Godot shells out to Blender's own glTF exporter behind the scenes. It's brilliant for solo iteration — save in Blender, alt-tab, Godot reimports automatically.

Explicit .glb export. File → Export → glTF 2.0, binary format. Slightly more ceremony, but the file is self-contained (meshes, textures, animations in one binary), imports fast, and doesn't require Blender installed on every machine that opens the project.

My rule: .blend files while I'm actively modeling, .glb once an asset stabilizes or the moment more than one person touches the project. CI runners and artists' machines shouldn't need matching Blender installs. If you do keep .blend files in the project but want Godot to skip some (reference files, WIP sculpts), add them to the import exclusion filter in Project Settings.

Scale and orientation: the boring stuff that bites

Blender is Z-up, Godot is Y-up. The good news: the glTF exporter converts for you (that's the +Y Up option, on by default). You almost never need to manually rotate anything — if your model comes in lying on its face, something else is wrong, usually an unapplied rotation.

The rules I follow religiously:

  • Model at real-world scale. Both tools treat 1 unit as 1 meter, and Godot's physics, lighting, and audio attenuation are all tuned for it. A door is ~2m. A crate is a crate-sized crate.
  • Apply all transforms before export (Ctrl+A → All Transforms). An object with a scale of 2.0 baked into its transform will export, but skinned meshes, physics shapes, and animation retargeting will punish you for it later. Armatures especially: apply scale on the armature before you animate, not after.
  • Face -Y in Blender for "forward." Blender's -Y forward maps to Godot's -Z forward, which is what look_at() and every character controller expects.

Materials: what survives the trip

glTF uses PBR metallic-roughness, and Blender's Principled BSDF maps onto it almost 1:1. Base color, metallic, roughness, normal, emission, and occlusion all come across as a StandardMaterial3D. Textures pack into the .glb automatically.

What doesn't survive: procedural shading. Noise textures, color ramps, fancy node math — none of that exports. If a material is procedural, bake it to image textures first (Cycles → Bake, one pass per channel). I budget for this early on stylized projects because it's tedious to retrofit.

One habit that pays off: in Godot's import dock (Advanced settings), extract materials to separate .tres files for anything you'll tweak in-engine. Otherwise your material edits live inside the imported scene and get flattened on the next reimport.

Collision suffixes: free physics setup

This is the feature I show every Blender artist I work with, because it moves collision authorship into the DCC where it belongs. Godot parses object-name suffixes at import:

Crate-col          # trimesh collision generated alongside the visible mesh
Crate-convcol      # convex hull collision alongside the mesh
Barrier-colonly    # invisible — becomes ONLY a StaticBody3D + collision
Barrier-convcolonly# same, but convex
Terrain-navmesh    # becomes a NavigationRegion3D
RefCube-noimp      # ignored entirely at import
Run-loop           # (animation name) imports with looping enabled

My standard practice: duplicate the visual mesh, decimate it hard, name it Whatever-colonly, parent it to the visual mesh, done. Artists can see and edit collision right in Blender. For dynamic props, -convcol on a simplified hull. For reference geometry and blockout leftovers, -noimp keeps them out of the engine without deleting them from the file.

Rigging and animation

Skinned characters come across cleanly if you respect the transform rules above. Each Blender action becomes a Godot animation inside an AnimationPlayer; I push actions to NLA tracks and export with "Group by NLA Track" so I control exactly what ships. Name animations with a -loop suffix and Godot imports them with looping already enabled — no per-clip checkbox clicking.

For humanoid characters, Godot 4's retargeting is worth learning: in the import settings, assign a BoneMap against the built-in SkeletonProfileHumanoid, and suddenly animations from one rig play on another. This saved me weeks on a project mixing Mixamo clips with custom-rigged characters.

The reimport loop, without pain

The golden rule: the imported scene is read-only in spirit. If you edit it directly and then re-export from Blender, Godot regenerates it and your changes vanish. Two safe patterns:

  1. New Inherited Scene (right-click the asset). Your scripts, extra nodes, and overrides live in the inherited scene and survive every reimport.
  2. Instance it and add behavior in code:
const CRATE := preload("res://assets/props/crate.glb")

func spawn_crate(at: Vector3) -> void:
    var crate := CRATE.instantiate()
    crate.position = at
    add_child(crate)

With either pattern, iteration becomes: tweak in Blender, save, focus the Godot window, watch it hot-reimport. On a recent client build, that loop was fast enough that the artist and I sat on a call adjusting silhouettes live against in-game lighting. That's the pipeline working as intended.

The takeaway

Blender and Godot 4 are a genuinely production-ready pairing, but the smoothness comes from discipline, not luck: real-world scale, applied transforms, Principled-only materials, suffix-driven collisions, and a strict "never edit the import" rule. Set those conventions on day one and the pipeline disappears into the background — which is exactly what a pipeline should do.

Building something in Godot and need an asset pipeline that won't fight your team? That's exactly the kind of thing Codebycandle helps with — get in touch.

← Back to all posts