DEV Community: Zalogin Aleksei

My 3D tool turned a scanned face into a mess. The tool wasn't the problem.

Zalogin Aleksei — Mon, 02 Nov 2026 20:19:06 +0000

My 3D tool turned a scanned face into a mess. The tool wasn't the problem.

I wrote a button that rebuilds a 3D model with fewer polygons — a normal step
before a model goes into a game. Then I pointed it at a scanned head and got
something I wouldn't show anyone.

Three things were wrong, and none of them was the button itself.

1. The head wasn't one model

It was 93 separate pieces, and many of them were open at the edges. The button
treated all of them as one surface, pulled the new mesh onto that surface, and
the result came out smeared.

Now there is a Repair button: it merges duplicate points, removes empty
faces, and tells you how many pieces the model is actually in. The rebuild also
warns about a broken model before producing the result.

2. The "how many polygons" setting did nothing

5,000 and 10,000 gave me the exact same model. The method I used can only
double the detail, so the number you type in mostly doesn't matter.

Now the tool searches for the right cell size instead, and the budget lands
where you set it: 5,000 → 4,748.

3. The model was tiny and far away

It came in scaled 26 times and sitting 300 metres from the centre of the scene.
The tool tried to fit the new surface to the origin — the wrong place — and
every point collapsed into one spot.

Two fixes: the tool now keeps the model's position and scale, and it snaps
points to the nearest part of the surface instead of pushing them through it.

What's in 0.6.8

Repair — merges duplicate points, removes empty faces, reports pieces and open edges.
Exact budget — the polygon count you type in is the count you get.
Safer fitting — keeps the model's position and scale, and refuses to guess when the model is open.
Delete the unused — shows the materials and images it will remove, then asks.
The AI sees the buttons — a button's report now reaches the chat model.
Fixed: a missing import made the repair silently do nothing.

Source and releases

blender #gamedev #3d #indiedev #python #blenderaddon

Asset Assistant 0.6.6 — what I ran into while working on real assets

Zalogin Aleksei — Mon, 26 Oct 2026 17:16:28 +0000

I wrote about Asset Assistant before — it's my Blender add-on for game assets:
it audits what is broken and turns the repetitive parts of the pipeline
(unwrap, atlas, bake, pack, retopology, export) into one click each.

This release is not a feature dump. Every item below is something I hit while
working on an actual asset, and that is the reason it is in this version.

What I ran into

The export lost my texture mapping. A Texture Coordinate → Mapping → Image Texture chain never reached the file: Blender's FBX exporter hard-codes uvset = None, so the engine samples the first UV set whatever the material says. Now the chain is evaluated per face into one UV layer per object, and the scene is restored right after the export.
Baked albedo came out washed out. It was baked as COMBINED, so the light and the shadows went into the base colour map. Now it is baked as the base colour through an Emission — on a cube with base colour (0.8, 0.2, 0.1): (0.968, 0.627, 0.541) instead of the expected (0.906, 0.485, 0.349).
A sculpt of 211,618 triangles, with no UVs and no budget. Hence a mesh doctor (nine checks) and retopology under a triangle budget you type in — 3,632 quads in 2.4 s, 0.00 mm off the original surface — plus a LOD chain.
The panel had grown into a wall of buttons. It is now split by pipeline stage: Textures, Mesh, UV, Bake, Export.

The smaller ones

the export no longer crashes when the target is a .blend path
baking an already baked material no longer produces Wood_Dark_Bake_Bake
UV overlaps are detected by real geometry, not by bounding boxes
the tab labels show names instead of i18n keys

Unchanged

Every button works with no AI at all. The optional chat still runs on a local
model and calls the same 46 tools.

Blender 4.2+, tested on 5.2 LTS. 19 headless test scripts, 12 doctor checks,
19 presets, 28 chapters of documentation.

Releases page ·
Source

I built a Blender add-on that tells you which of your game assets are broken

Zalogin Aleksei — Wed, 21 Oct 2026 19:39:51 +0000

Blender is wonderful for making game assets and terrible for keeping them correct.

Nothing warns you that the normal map is in sRGB instead of Non-Color. That the texel density on one island is twice that of its neighbour. That the texture file you linked two weeks ago is no longer on disk. You find out when the engine complains — or, worse, when it doesn't.

The routine I wanted to kill
Every asset went through the same sequence, and every step was manual:

unwrap it, and check that the texel density is even;
hand the layout to an external painting program and bring the result back;
bake the procedural material into real textures;
pack the textures so the project survives being moved;
find out it is still not ready to hand over.
And the part that actually hurt: with a hundred objects in the scene, finding the badly configured one is no longer a five-minute job.

The doctor
That last problem is what the add-on is really about.

AI → Material Doctor reads the whole scene and reports what is broken: the wrong colour space, a normal map wired straight into Base Color, a missing texture file, a mesh with textures but no UV, absolute paths, unpacked textures, a shader the exporter cannot express. It says which object, which material, how serious it is, and what can be repaired safely.

Twelve checks, and the safe ones are fixed for you. Nothing is deleted.

What works today
The buttons — no model needed, they just do the work

PBR from folder — a folder of maps becomes a material, assigned, with the right colour spaces.
Doctor / Fix — the audit above, and the safe repairs.
UV — unwrap, even texel density, a shared atlas with padding, and a UV kit: the layout as a PNG plus a manifest, to paint in Aseprite or Krita and bring back, without the UVs ever being touched.
Bake — procedural material to textures, written next to the .blend, with a plain material on the object. The file names can follow the game convention (_col, _nrm, _rgh).
Textures — pack into the .blend, relative paths, relink lost files, fix colour spaces.
Export — GLB and FBX with the axes and modifiers the engines expect. The readiness check runs first.
Presets — 16 procedural recipes and 4 hand-written layered materials to start from.
The agent — the same tools, plus a chat that sees your scene

Every request carries a snapshot of the scene, focused on what you are looking at right now, and a section of problems the model cannot see.
The model can call any of the 40 tools by name, and reads back what actually happened instead of guessing.
8 skills carry the knowledge it should not improvise — the exact socket names of Blender 4.x/5.x, colour spaces, PBR wiring. They attach to your own words, and every code sample in them is executed in Blender by a test, so an instruction cannot quietly drift away from the API.
When no tool fits, it writes the code; the Run code button executes it in the scene, with Undo.
Destructive tools never run on their own: it asks, and the chat shows a Run / Cancel block.
Tools 40 — each one a button, a model call, and a headless test
Doctor checks 12, 4 of them repaired automatically
Skills 8, with runnable code samples
Headless checks 16 scripts that run the real code in the real Blender
Needs Blender 4.2+ and a model (local via Ollama, or an API key) — only for the agent half
Where it is going
More around the agent, because right now it does not do that much, but it can already help with analysis and information:

the result of "Run code" back into the model's context, so it can check its own work;
a doctor check for "this is a flat BSDF, not a procedural material" — the piece that lets a small local model learn to build materials;
the preset buttons calling the tool directly;
the presets as node groups, so they live in the .blend like any Blender asset;
the model driving other add-ons.
And around the pipeline: ORM packing, a preview render, and material generation by the model as a separate step once (2) exists.

Try it
git clone https://github.com/SickSect/BlenderAgent.git
python tools/build_addon.py # -> dist/asset_assistant-.zip
Edit → Preferences → Get Extensions → ▾ → Install from Disk, pick the zip, enable Asset Assistant.

The buttons need no model at all. For the agent, run Ollama locally (ollama pull qwen2.5-coder:7b) or point it at any OpenAI-compatible endpoint.

If the doctor has ever found a broken asset you did not know about, that is the feature I would like to hear about.

Blender forbids Python threads. So my AI add-on talks to itself through two JSON files

Zalogin Aleksei — Mon, 19 Oct 2026 09:36:01 +0000

The pivot
I spent the last months building a local multi-agent CLI code generator - planner → coder → tester → executor → reviewer, running on open models via Ollama. It closed the loop: it wrote code, ran it, tested it, and fixed it.

It worked. And that's exactly the problem: it solved a problem I don't have. Writing code for files on disk is a solved niche - I was competing with every other code-gen tool for a user who already has one.

What I actually do all day is 3D. So the project became something else: an AI assistant that lives inside Blender and holds real tools for working with models, not just a text box that emits code.

What works right now
The add-on is called Game Asset Assistant, targets Blender 4.2+, and ships as a proper extension zip.

Chat where you work

Docked in the 3D Viewport sidebar (N → AI tab)
Also opens as a standalone floating window with Ctrl+Alt+A
Streamed responses, message history, stop/clear buttons
It knows your scene

Every request carries a compact snapshot injected into the system prompt:

Blender 4.2.0
Scene: Scene | fps=24 | units=METRIC | render=CYCLES
Objects: 12

Cube [MESH] loc=(0.00, 0.00, 0.00) rot_deg=(0.0, 0.0, 0.0) scale=(1.00, 1.00, 1.00) verts=8 edges=12 faces=6 | uv=UVMap | materials=Steel | modifiers=SUBSURF Selected: Cube Active: Cube | mode=OBJECT So when you ask "how many polygons does the active object have?", the model answers about your object - by name.

One click from answer to action

When a reply contains a


python block, it appears in a box with two buttons:

Run code - executes it in the current scene on the main thread, captures print() output and tracebacks, and pushes both back into the chat. That closes the loop: the model writes, Blender executes, the model sees the error and fixes it.
To Text Editor - saves it as a text datablock for manual review.
Backends

Local (Ollama, e.g. qwen2.5-coder:7b) or any OpenAI-compatible API - switchable in preferences, no code changes.

The part that broke my brain: Blender forbids threads
Here's the non-obvious bit worth the whole post.

Blender's API docs say it plainly: Python threads that outlive the script cause hard-to-diagnose crashes in Blender's own drawing code. So the obvious approach - "spawn a thread, call the LLM API, update the UI when it returns" - is off the table.

The add-on therefore never blocks and never spawns a thread. Instead:

Blender (main thread)              worker process            network
┌────────────────────────┐         ┌──────────────┐
│ operator appends a     │commands │              │
│ JSON line ─────────────┼────────→│  worker.py   │──HTTP──→ Ollama / API
│                        │         │              │
│ bpy.app.timers,        │events   │              │
│ every 0.1s, reads new  │←────────┤              │
│ lines ─────────────────┤         └──────────────┘
└────────────────────────┘
Commands are just JSON objects appended to commands.jsonl.
Events (chunk, done, error) are appended to events.jsonl.
A bpy.app.timers callback pumps events every 0.1 s - and a timer is not a thread, it's a callback Blender invokes on the main thread between frames. That's the only legal way to do background work.
Side effect: the whole add-on ships without any third-party dependency, and the protocol already has room for tool-call requests in a later phase.

What's not there yet
Being honest about the gaps:

No structured tool-calling - the model emits a code block and we exec() it
No confirmation for destructive operations (the prompt asks the model to warn; that's a request, not a guarantee)
No undo grouping - one Ctrl+Z won't roll back a whole script
UV, rigging and texturing exist only as chat advice, not as one-click tools
Scene snapshot is blind to UV islands, texel density, weights and armature pose
Roadmap
Phase   What    Why first
0   Richer snapshot, undo-push, destructive-op confirmation Cheap, unlocks everything after
1   Tool-calling over the JSONL channel, executed on the main thread with a registry + JSON schemas The reliability jump: from "80 lines of text that may fail" to named calls
2   Texturing: PBR material presets, texture assignment, packing, bake helpers  Stable API, high daily value
3   UV: quick unwrap/pack/texel-density, seam-by-angle, and a UV diagnostics report (overlaps, density) Most repetitive work; the report lets the model read the result and propose fixes
4   Auto-rig: metarig → Rigify, auto-weights, weight validation, export checks    Hardest - errors are silent, so diagnostics matter more than generation
5   One-click pipelines: GBC Prep, Char Prep, PBR Bake, Game Export Combines 2–4 into buttons
6   Teach the model: tool catalog in the prompt, domain recipes, few-shot examples  Ongoing, parallel
Integration with other Blender add-ons (delegating to UV packers, for example) is on the list - but the final roadmap is still open. I'd rather ship phases 0–3 and let real usage decide what phase 4 looks like.

The plan from here
Post progress as it lands. If you're working on AI × 3D pipelines, or you've wrapped a DCC tool for an LLM - I'd love to compare notes.

Repo link in the comments.

#blender #ai #python #gamedev #3d #showdev