You paint two or three Color Attribute layers onto a mesh in Blender — one for grime, one for moss, one to mask a wear pattern for a shader — export to glTF, and only one of them shows up. The others come back pure white, in every viewer and every engine, every time you export. That's not a material setup mistake. Blender's glTF exporter currently writes real color data for only the last vertex color layer in a mesh's list; every other layer gets replaced with solid white the moment you hit Export glTF 2.0. It's a confirmed, open bug — issue #2758 on the glTF-Blender-IO tracker, filed September 16, 2026, reproduced on Blender 5.2.2 LTS — and the fix isn't landing in a stable release until Blender 5.3, expected this November.
The bug: only your last vertex color layer survives export
The repro is small: add two Color Attributes to a mesh (Object Data Properties tab > Color Attributes panel), paint each a distinct flat color so the failure is obvious, export as glTF 2.0 or GLB with Data > Mesh > Vertex Color turned on, then open the result in any glTF viewer or reimport it into a fresh Blender file. Every attribute except the last one in the list comes back solid white — not missing, not black, white, as if the exporter wrote valid white pixels instead of your data. It reproduces regardless of exporter settings, and it isn't platform-specific: the original report came from Blender 5.2.2 LTS on Linux.
Blender maintainer Julien Duroure opened a fix five days after the report (pull request #2760, branch `fix_vc`), but tagged it for the Blender 5.3 milestone rather than a point release. Anyone on 5.2.x, or building a pipeline around the current LTS, is stuck with the bug for the rest of this release cycle.
A repeat offender, not a one-off
This is the second distinct vertex-color export bug in two years, and the two are worth telling apart. Issue #2094, filed December 2023 against Blender 4.0, was different: Blender exported only one color attribute total, and not necessarily the one wired into your material — it exported whichever attribute happened to be active in the viewport, silently dropping the rest. That got fixed in early 2024 (PR #2100), which is presumably what enabled multi-attribute export at all. #2758 is what broke once multiple attributes started actually getting written: the pipe is open now, but everything except the last item through it arrives blank. If you last touched this workflow before 2024 and assumed it "just works" today, it doesn't — it just fails differently now.
Check which layer will survive before you export
Rather than guessing, ask Blender directly. List order in the Color Attributes panel is what determines survival — not which attribute is active, not which one your material actually references:
```python
import bpy
obj = bpy.context.active_object
attrs = obj.data.color_attributes
for i, ca in enumerate(attrs):
status = "exports intact" if i == len(attrs) - 1 else "exports WHITE"
print(f"{i}: {ca.name} -> {status}")
```
Run that in Blender's Python console with your mesh selected before you export, not after you've already shipped a GLB with a blank moss mask to your engine.
The workaround until 5.3 ships
If you only need one channel to survive intact, delete the attribute you care about and recreate it (Color Attributes panel > +). New attributes are always appended to the bottom of the list, which is the position that currently exports correctly — a one-minute fix for the common case of a single grime or AO mask.
If you genuinely need two or more channels to survive — a moss mask and a separate wear mask on the same mesh, say — reordering doesn't help, because only one position ever survives. Today the reliable options are baking each mask into a separate channel of a spare texture instead of vertex colors, or splitting the masks across separate mesh objects that each export their one surviving layer independently. Building Blender from the `fix_vc` branch works if you're already comfortable compiling from source, but it's not something to put in a shared team pipeline before 5.3 is actually stable.
What's still limited even after the fix
Getting multiple channels out of Blender intact doesn't mean your engine will use them. Per the glTF spec, only `COLOR_0` is guaranteed to act as a base color multiplier — `COLOR_1` and beyond exist for you to wire into a custom shader yourself, and most engines' built-in mesh data simply has no slot for a second one:
| Engine / pipeline | `COLOR_0` | `COLOR_1`+ |
|---|---|---|
| Unity (glTFast / UnityGLTF) | Imports to `Mesh.colors` | Not supported — Mesh has one color channel |
| Godot 4.x | Imports to `ARRAY_COLOR` | Not supported without a custom import plugin |
| Unreal Engine 5 (Interchange) | Imports to vertex color | Not supported — one vertex color set per mesh |
| Three.js (hand-rolled pipeline) | `geometry.attributes.color` | Only if you add a second `BufferAttribute` and read it in your own shader |
Practically: if a workflow depends on more than one vertex color channel surviving into the engine, budget for a custom shader or importer on the receiving end — it isn't a checkbox anywhere.
It's the same reason weathering on BitSoul's own catalog gets baked into a single Color Attribute before publishing rather than split across layers — Gold Dust Mossy Rock carries its moss coverage in `COLOR_0` alone, so it survives export intact on every engine in that table, bug or no bug.
If your export pipeline is dropping other mesh data too, the geometry-nodes and UV failures are worth checking next: Blender's Boolean and Geometry Nodes disable your UV maps, why glTF exports silently drop your LOD levels, and fixing Geometry Nodes instancing that exports empty or huge all share the same root cause: Blender's exporter making a silent assumption about which data you meant to ship.
---
*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.*