Your Boolean cut looks perfect in the viewport, you apply a material, and the new faces come back flat grey or checkerboard-pink while the rest of the mesh textures fine. Same thing happens after a Geometry Nodes setup: everything reads fine in Solid shading, then you flip to Material Preview and half the geometry has no texture at all. That's not a corrupted file or a bad material — Blender's Boolean modifier and Geometry Nodes can generate new geometry with its UV map attribute switched off, so the faces exist but carry no coordinates for the sampler to read.
That's the full diagnosis in one sentence: the UV data is either missing on the new faces or present-but-inactive on the object. Once you know that, the fix takes five minutes, not a re-model.
Why Boolean and Geometry Nodes disable UVs
![]()
A UV map in Blender isn't really a "map" — it's an attribute stored per face-corner, a 2D Vector (internally `float2`), usually named `UVMap`. Every operation that generates new topology has to decide what happens to attributes on geometry that didn't exist a second ago, and Boolean's mesh-intersection solver and the Geometry Nodes `Mesh Boolean` and `Realize Instances` nodes don't reliably carry that attribute through. Sometimes it's dropped outright. Sometimes it's rebuilt as a generic 2D Vector field that Blender's own exporter doesn't recognize as UV data because it was never flagged as the special UV type. Either way, the mesh keeps evaluating and rendering, so nothing in the interface throws an error — the faces just quietly stop carrying coordinates.
This isn't new and it isn't fixed. Blender's own tracker has logged it under at least six separate reports — T61426, T85962, T89357, T89744, T92384, and T93537 — spanning early Geometry Nodes builds through 2026, and it doesn't show up on the Blender 5.2 LTS changelog (shipped July 14, 2026, patched to 5.2.1 on August 25). Hit this on 5.2.1 and you're not on a broken install — it's the same attribute-handling gap developers have been chasing for years.
Walkthrough: getting the UVs back
![]()
- Apply the modifier first. Ctrl+A on the Boolean or Geometry Nodes entry in the Modifier Properties tab (the wrench icon), or Apply from its dropdown. Until it's applied, the result only exists at evaluation time and there's nothing solid to unwrap.
- Check Object Data Properties > UV Maps. That's the green-triangle mesh icon in the Properties editor. If your usual UV layer is listed but not the active row, click it — that alone fixes textures that "vanished" after a Boolean, because the object was rendering off an inactive layer instead of the one your material was built around.
- See it in the UV Editor. Switch to the UV Editing workspace tab, enter Edit Mode, press A to select everything. Faces with no real UV data won't show up in the UV Editor pane, or they'll bunch up at a single point instead of spreading across the 0–1 square — that's visual confirmation, not a guess.
- Re-unwrap. Select the affected faces, or just select all — after a destructive Boolean, the new topology rarely respects your old seams anyway — and press U for the Unwrap menu. Smart UV Project is faster for hard-surface cuts; manual seams plus Unwrap for hero geometry.
- Building the geometry procedurally? Add a `Store Named Attribute` node right after your `Mesh Boolean` or `Realize Instances` node — domain Face Corner, name matching your UV map (`UVMap` unless you renamed it) — so the attribute survives with the correct type instead of degrading into a generic field the exporter skips.
Checking every object by hand doesn't scale for a kit-bashed scene. This finds meshes missing an active UV layer and creates one so nothing exports with a null map — it won't fix garbage coordinates on already-disabled faces, that part still needs the re-unwrap in step 4:
```python
import bpy
for obj in bpy.context.selected_objects:
if obj.type != 'MESH':
continue
uv = obj.data.uv_layers
if not uv:
uv.new(name="UVMap")
print(f"{obj.name}: created missing UV layer")
elif uv.active is None:
uv.active_index = 0
print(f"{obj.name}: reactivated UV layer '{uv[0].name}'")
```
Run it with every affected object selected in the 3D viewport.
A hard-surface kit piece like the Brutalist Bunker — vents, hatches, and panel seams all cut with Booleans — reproduces this in under a minute if you want to see it on a real asset instead of a test cube. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).
| Symptom | Likely cause | Fix |
|---|---|---|
| New Boolean faces render grey/pink, rest of mesh fine | UV layer inactive after modifier apply | Object Data Properties > UV Maps, click to activate |
| Whole object loses texture after apply | Layer deleted outright, not just deactivated | `uv_layers.new()`, then re-unwrap |
| Geometry Nodes output looks fine in viewport, breaks on export | Attribute output as generic 2D Vector, not typed UV | `Store Named Attribute`, domain Face Corner |
| Only the boolean-cut faces are untextured | New topology never got coordinates | Select those faces, U > Unwrap or Smart UV Project |
Gotchas
Applying a modifier is destructive — duplicate the object (Shift+D) or keep a backup collection before Ctrl+A if you might need to tweak the Boolean operands later. Report T92384 specifically calls out the Fast solver as the more frequent offender for dropped UVs; Exact is slower but worth it on hero props where you can't eyeball every cut. If the object also has a Mirror modifier, apply Mirror before Boolean where you can — mirroring after a Boolean re-triggers the same attribute loss on the mirrored half, doubling your cleanup.
This is a different failure mode than Geometry Nodes ballooning your export size or shipping empty meshes — that's an instancing problem, not a UV one, and the fix is separate: Geometry Nodes exports empty or huge? Fix instancing in glTF. If you haven't touched seam placement fundamentals in a while, the full workflow is in UV mapping for game assets: a complete guide to game-ready unwrapping.
Before you export anything, sanity-check the result without reopening Blender: drop the GLB into 3D Studio and look at the UV/material inspection panel — if a face still shows as unmapped there, the re-unwrap didn't take, and you're back to step 4 instead of stuck debugging an engine-side import bug.
If you're racing a build for Steam Next Fest in October, fix this before you optimize anything else — a missing texture reads as a bug to a demo player, while a slightly high poly count usually doesn't. Polygon budget is the next problem once UVs are clean: cut your demo's polygon count before Next Fest without Blender.
---
*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.*