"Add some padding" is the most repeated sentence in game art. It is also the least useful. Nobody says how much, or why.
There is a real number. It comes from two things: the 4x4 compression block, and how many mip levels your engine streams.
What I actually measured
I built a 2048 map with two UV islands on it. The islands are two of my own material renders, a copper and a clay, so the texels are real content.
Then I varied the gap between the islands and the export dilation. I built the mip chain by averaging 2x2 texels, which is what the GPU does. Every version was compressed to real BC1 and decoded back.
Every number below came out of that test.
The 4x4 block sets the floor
BC1 compresses in blocks of 4x4 texels. Each block stores two endpoint colours and two blends of them. Conn Buranicz's breakdown has the layout: 64 bits per block, 4 bits per pixel.
If one block holds texels from two islands, both islands have to share those endpoints. Epic says the same on its lightmap page. Their wording: "a minimum of four texels is usually required to avoid all bleeding artifacts".
Here is my count. With a 1 or 2 pixel gap and unlucky alignment, 226 blocks along one island edge held both islands.
Error inside those blocks was 5.63 on average and 66 at worst, out of 255. That is a visible smear.
At a 3 pixel gap, no block straddled, at any alignment. Same at 4, 6 and 8 pixels. Error fell to 1.07 average and 7 at worst, identical to a block with nothing near it.
So the honest floor is 3. You use 4 because it snaps to the block and you will remember it.
Padding halves with every mip
This is the part the advice never mentions. A mip is a half-size copy, so your gutter halves too.
An 8 pixel gap at 2048 becomes:
- 4 pixels at 1024
- 2 pixels at 512
- 1 pixel at 256
- 0 pixels at 128
Below the 128 mip there is nothing between your islands. The neighbour's colour is now inside your island's edge texel.
What the bleed costs, in numbers
I measured contamination on the island's outer texel against a clean reference.
With no padding at all, exported onto a black background, the error was 21.77 on average at mip 2. By mip 6 the worst texel was off by 39.7.
With 4 pixels of dilation it was 0.00 down to mip 2. Then 0.24, then 0.79, then 1.86, then 3.84.
The pattern is exact. Padding of D pixels survives log2(D) mip drops and not one more.
One export setting deletes the whole problem
Painter's export window offers five padding options:
- No padding (passthrough)
- Dilation infinite
- Dilation + transparent
- Dilation + default background color
- Dilation + diffusion
Dilation infinite stretches every island until it meets a neighbour or the texture border. Adobe's own padding page says padding "is very important for mipmaps".
I measured it. With infinite dilation the error was 0.00 at every level, down to 32 by 32.
Not small. Zero.
It still does not save you from the block
Infinite dilation fixes the mip chain. It does nothing for the 4x4 block.
Those 226 straddling blocks were measured with infinite dilation switched on. The island's own texels still shared a block with the neighbour.
The two rules are separate. Four pixels of gap for the compressor, infinite dilation for the mips. You need both.
The rule I use
Set export padding to Dilation infinite. Then the pixel gap only has to clear the block, and 4 clears it at every size you ship.
Keep a finite number only when the background must stay transparent or a flat colour. Then double the 4 for every mip you stream. From 2048 down to 128 is four drops, so 64 pixels.
That is a lot of UV space. It is also why infinite dilation exists.
What I did not test
BC7, because I could not encode it on this machine. It gets 128 bits per block and more endpoint modes, so it should not be worse than BC1.
I also did not test what Painter picks by default. Open your own export preset and read it. Mine says Dilation infinite on every product I ship.
It is a UV decision, not a texture decision
Padding is set when you pack, not when you export. The unwrapping course spends more time on packing than on cutting seams for this reason.
If you pack in RizomUV, the margin is given in pixels against a stated map size. That is what the live link keeps in sync for me.
In Blender the bake margin and the pack margin are two different numbers. Easy Bake is where I keep mine matched.
Check the bake before you paint anything. Mesh maps decide the texture, and a bad margin poisons every generator sitting on top.
Four pixels, infinite dilation. That is the whole answer, and now there are numbers under it.