You upgrade a Godot project from 4.4 to 4.5 or 4.6, hit Reimport on an old `.blend` or `.glb`, and meshes suddenly carry a "2" in their names with materials replaced by Godot's pink error checkerboard. Nothing in the source file changed. The cause: `.import` files written under 4.4 or earlier never stored a `gltf/naming_version` key, so Godot 4.5 and 4.6 default it to `0` on reimport — the legacy 4.0 naming scheme, which appends a number whenever a child mesh shares its name with the file itself. It's a confirmed regression, tracked as Godot #112405, and the fix takes under a minute.
Why Godot 4.5 renames nodes and drops materials
The bug is a regression of an older naming fix from PR #80270, first flagged in November 2025 against 4.6.dev and confirmed back to 4.5. The exact trigger, per the reproduction steps on the tracker: a project started in 4.4.1, containing a `.blend` file where a mesh shares its name with the filename — `robot.blend` with a mesh node also named `robot` is a common pattern when following a straightforward Blender-to-Godot export pipeline that keeps Blender's object names intact. An inherited scene gets a material assigned by hand. Then the project opens in 4.5 or 4.6, the file reimports, and because the old `.import` never recorded which naming scheme it used, Godot falls back to the 4.0-era behavior and appends "2" to the colliding node.
Godot's current stable is 4.7, but plenty of long-running projects are still on 4.5 for stability, and that's exactly where this bites. The source `.blend` or `.glb` on disk is untouched — this is purely Godot's import cache reinterpreting the same file differently. But every scene instancing that mesh needs its material reassigned once the node name shifts underneath it, and on a project with a few hundred imported assets, that's not a one-click fix.
Fix it: set Naming Version, then reimport
Select the affected file in the FileSystem dock, open the Import dock, and click Advanced… to open Advanced Import Settings. Find Naming Version under the glTF options and set it explicitly instead of leaving it on the inherited default, then click Reimport. That single change is confirmed on the tracker as the fix — Godot stops guessing and stores the version going forward.
Before mass-reimporting an old project, it's worth finding out which files are actually at risk rather than reimporting blind. A short editor script flags any top-level mesh whose name matches its own filename — the exact condition that triggers the bug:
```gdscript
# Editor > Debugger > New Script, paste, run once (EditorScript)
extends EditorScript
func _run():
var dir := DirAccess.open("res://")
for file in dir.get_files():
if not (file.ends_with(".glb") or file.ends_with(".gltf")):
continue
var packed: PackedScene = load("res://" + file)
var root := packed.instantiate()
for child in root.get_children():
if child.name == file.get_basename():
print("At risk: ", file, " -> node '", child.name, "'")
root.free()
```
Only the files it prints need the Advanced Import Settings pass. Everything else reimports safely.
The second gotcha: textures extract on every import
A separate, more common friction hits every glTF or GLB import regardless of project age. Godot's `embedded_image_handling` option defaults to Extract Textures, pulling any embedded PNG or JPG out into loose files next to the imported asset the moment it imports. There's no Project Settings → Import Defaults override for Scene/glTF imports the way some other importers get one — flagged on the tracker as Godot #89379 — so a project pulling in a batch of free GLBs ends up with each file's texture handling set individually, or just accepts the extracted-file sprawl.
It's easy to see on a single download. Grab BitSoul3D's Scrapyard Bounty Hunter model, drag the `.glb` into the FileSystem dock, and Godot extracts its embedded textures into loose PNGs before a single settings panel is even open. Before dropping an unfamiliar GLB into an aging project, a quick pass through BitSoul3D's 3D Studio — the same in-browser tool covered for checking poly counts — also lists node and material names, which catches a same-name collision before it ever reaches Godot's importer.
Batch-fixing a folder of GLBs at once
Neither gotcha has to be handled one file at a time. Multi-select every newly added `.glb` or `.gltf` in the FileSystem dock — click the first, shift-click the last — and the Import dock shows the shared options for the whole selection. Change Embedded Image Handling to Embed As Basis Universal (or whatever the project's pipeline wants) once, click Reimport, and it applies across every selected file in a single pass instead of file-by-file.
| Bug | Triggers on | Symptom | Fix |
|---|---|---|---|
| Naming version regression (#112405) | Reimporting a project started in 4.4 or earlier, under 4.5 or 4.6 | Mesh renamed with a "2" suffix, material lost | Set Naming Version explicitly in Advanced Import Settings, reimport |
| Embedded image handling default (#89379) | Every glTF/GLB import, any version 4.3 and up | Textures auto-extracted to loose files, no global override | Multi-select files in FileSystem dock, set once, Reimport |
The same multi-select trick works for any other shared glTF option — compression, LOD generation, skin naming — any time a batch of assets needs the same treatment. Delete the `.godot` folder and let Godot reimport from a clean cache fixes the naming issue for a single stray file, but it re-extracts every texture and rebuilds every LOD project-wide, which is slower than just fixing the files the script actually flags.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*