I’m trying to figure out the exact value, if any, for the pixel margin to set when packing UV maps.
If I have a texture size of 4096x4096, what pixel value should I set for the island margin?
In the UVPackmaster addon, I saw that you can set the pixel value for the marines as desired. But what is the correct value to set based on the texture size (1024, 2048, 4096, etc.)?
Does it also depend on the textel density (px/cm)?
What is the correlation and how is it calculated?
This is “somekind of simple” when thinking about the reason why this feature was added. When having no pixel margin then the color of a texture pixel near the edges of the UV’s will “particpate” in the colorization of the face. So it’s easier to have some space between the UV-islands and paint or texture across/over the island borders so that the color does match “better”.
When two UV-islands have totally different colors a margin with only one pixel might be not enough because it may colorbleed. If having similar texture (for example the same stone, sand, skin texture) then this might be not so important. Then again one pixel might be a little to less at all…
So for more low poly models with more unique different texture areas you might use relative big values (8?) but for bigger texture sizes one usually does us more “realistic” textures and so they are very simialr in color. So the bigger they get you might not have to make them also even bigger or even less (or only 4? or 6 and not 16 or 32).
You now might thing this does not answer you question but therefore us wrote: “somekind of simple”… there is no “correct”… if the texture does not bleed into another UV-island then it’s okay.
( One might have even the idea to uses different margins between different UV-islands… depends of “the need” to optimize everything. )
As i said… it depends… you simply may try and paint neighboring uv-islands in different colors and have a look at the model… so (also) dpending on the textures you wanna use if there is colorbleeding then you have to choose more…
Also i now remember: in other apps this is called padding… so you may take a look here:
Following what it says at the link you indicated, it would seem that for a 4096 map 32px of margin is needed.
Aren’t there too many? Or I didn’t understand well…
This may especially apply to a game model in a game engine with mip-mapping as explained in the article…
(Again… ) This may depend on the use case; there is no general perfect rule. So everone has to make ones own experiences… and so sometimes developes a new trick.
I would like to add another reason we have margins is for mipmaps which are basically downscaled versions of your texture and are to optimise rendering and reduce aliasing but the downscaling also blends neighbouring pixels so having more padding between the UV shells reduces texture bleeding. The best thing is to experiment with different values and you will improve with experience.
Sometimes this is necessary and it depends on the contrast between the neighbouring shells pixels. For example if you had 2 pixels padding on a 4K texture and everywhere else where there isn’t a shell was flooded with black pixels. You will see black edges everywhere you have a seam pretty quickly as the mipmaps take effect with distance from the camera. This is why applications like Substance Painter have dilation which expands the pixels from the borders of your shells until they hit each other in the centre. You can think of tileable textures and trimsheets also where you don’t have any margin or padding because there’s no need.
If I’m uniquely unwrapping anything by default I use 2 at 512, 4 at 1024, 8 at 2048, 16 at 4096 and 32 at 8192 but this can be changed depending on the projects needs.
Honestly I’m not sure, maybe there’s an addon but I’ve never checked. I found certain features to be lacking or missing in blender so I found other applications to pickup where blender is lacking. Don’t get me wrong blender is great especially for a free application and I’ve used it for over 10 years but I don’t bother with addons usually.