UV: unwrap. Margin size is not related to any useful measure #90782

New Issue

Vyacheslav Kobozev · 2021-08-19T22:24:50+02:00

2021-08-19 22:24:50 +02:00

System Information
Operating system: Windows-8.1-6.3.9600-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.41

Blender Version
Broken: version: 2.93.4 Release Candidate, branch: master, commit date: 2021-08-18 12:30, hash: 63559a779c

Try to unwrap and tune 2 pixel margin for example.

It is not related to anything I can count and predict.
Expected: relation to pixels (biggest size), if texture loaded to editor, or relation to UV 0—1 to have ability to enter 1/resolution

2021-08-19_23-16-58.mp4

untitled.blend

p.s. honestly I always use side-packers, so I can tune paddings in pixels. But it will be nice to have it out of box.

**System Information** Operating system: Windows-8.1-6.3.9600-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.41 **Blender Version** Broken: version: 2.93.4 Release Candidate, branch: master, commit date: 2021-08-18 12:30, hash: `63559a779c` Try to unwrap and tune 2 pixel margin for example. ![28275821.png](https://archive.blender.org/developer/F10294418/28275821.png) It is not related to anything I can count and predict. Expected: relation to pixels (biggest size), if texture loaded to editor, or relation to UV 0—1 to have ability to enter 1/resolution [2021-08-19_23-16-58.mp4](https://archive.blender.org/developer/F10294405/2021-08-19_23-16-58.mp4) [untitled.blend](https://archive.blender.org/developer/F10294410/untitled.blend) p.s. honestly I always use side-packers, so I can tune paddings in pixels. But it will be nice to have it out of box.

Vyacheslav Kobozev commented

2021-08-19 22:24:50 +02:00

Added subscriber: @Vyach

Eugene Du commented

2021-08-20 16:34:47 +02:00

Added subscriber: @APEC

Eugene Du commented

2021-08-20 16:34:47 +02:00

or at least if you change Display - Pixel Coordinates, margin value should also be consistent.
So if I type Margin = 1, it should be 1 pixel value, but not this unknown value

or at least if you change **Display - Pixel Coordinates**, margin value should also be consistent. So if I type Margin = 1, it should be 1 pixel value, but not this unknown value ![margin.png](https://archive.blender.org/developer/F10296064/margin.png)

Philipp Oeser commented

2021-08-24 08:38:25 +02:00

Added subscribers: @brecht, @lichtwerk

Philipp Oeser commented

2021-08-24 08:38:25 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2021-08-24 08:38:25 +02:00

This is from code:
(so margin is dependent on island area)

    /* Logic matches behavior from #param_pack,
     * use area so multiply the margin by the area to give
     * predictable results not dependent on UV scale. */
    margin = (margin * (float)area) * 0.1f;

I assume this is in order to not have much space "wasted" on many small islands (but this is just an assumption)
Does it make more sense now?

@brecht: do you think a way to set an "absolute" margin would make sense?

This is from code: (so margin is dependent on island area) ``` /* Logic matches behavior from #param_pack, * use area so multiply the margin by the area to give * predictable results not dependent on UV scale. */ margin = (margin * (float)area) * 0.1f; ``` I assume this is in order to not have much space "wasted" on many small islands (but this is just an assumption) Does it make more sense now? @brecht: do you think a way to set an "absolute" margin would make sense?

Eugene Du commented

2021-08-24 09:42:46 +02:00

New research:

texture size 512x512, one square = 0.0625 in absolute length (1/16)	the same in pixels, one square = 32 pixels
if we use UV Pack Islands and set Margin to 0.0625	if switching to pixels - nothing changes in value (should also switch to pixels)

so Margin not related to any of this values.
Ideally it should shift our UV Island from borders exactly on 1 square length.

New research: | texture size 512x512, one square = 0.0625 in absolute length (1/16) ![UV_Absolute.png](https://archive.blender.org/developer/F10317615/UV_Absolute.png) |the same in pixels, one square = 32 pixels ![UV_Pixels.png](https://archive.blender.org/developer/F10317634/UV_Pixels.png) | | -- | -- | | if we use UV Pack Islands and set Margin to 0.0625 ![UV_Absolute_Margin.png](https://archive.blender.org/developer/F10317640/UV_Absolute_Margin.png) | if switching to pixels - nothing changes in value (should also switch to pixels) ![UV_Pixels_Margin.png](https://archive.blender.org/developer/F10317642/UV_Pixels_Margin.png) so Margin not related to any of this values. Ideally it should shift our UV Island from borders exactly on 1 square length.

Vyacheslav Kobozev commented

2021-08-24 09:57:07 +02:00

In #90782#1210538, @lichtwerk wrote:
(so margin is dependent on island area)

No point to have this kind of margin IMO.
It is inconsistent, impossible to predict, hard to control and I wonder why it was made this way…

> In #90782#1210538, @lichtwerk wrote: > (so margin is dependent on island area) No point to have this kind of margin IMO. It is inconsistent, impossible to predict, hard to control and I wonder why it was made this way…

Philipp Oeser commented

2021-08-24 10:08:12 +02:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Philipp Oeser commented

2021-08-24 10:08:12 +02:00

By definition, this is not a bug since this is working like intentionally coded (even with comment).
Not totally sure what to read from the "not dependent on UV scale" in said code comment though.

No point to have this kind of margin IMO.
It is inconsistent, impossible to predict, hard to control and I wonder why it was made this way…

Like I said before, I can only assume this was made to not "waste" space around many, many small islands.

Unsure how to classify (personally, I would not consider this a bug, but a request for improved behavior -- which is not tackled here), but will pass on to module devs to decide.

By definition, this is not a bug since this is working like intentionally coded (even with comment). Not totally sure what to read from the "not dependent on UV scale" in said code comment though. > No point to have this kind of margin IMO. > It is inconsistent, impossible to predict, hard to control and I wonder why it was made this way… Like I said before, I can only assume this was made to not "waste" space around many, many small islands. Unsure how to classify (personally, I would not consider this a bug, but a request for improved behavior -- which is not tackled here), but will pass on to module devs to decide.

Vyacheslav Kobozev commented

2021-08-24 18:14:36 +02:00

@lichtwerk Yup. but such things are «workflow bugs» and they can be even worse, because they look as working code but work strange way or confuse ppl.
Papercuts usually more obvious

I can only assume this was made to not "waste" space around many, many small islands.

I tested. Blender produces average margin
So it is consistent, but still hard to control on Hipoly (where live margin change can be very slow and it is hard to catch proper size of pixels)

I remember, that once it was per individual islands and it was bug. Sorry for misleading about it.

@lichtwerk Yup. but such things are «workflow bugs» and they can be even worse, because they look as working code but work strange way or confuse ppl. Papercuts usually more obvious >I can only assume this was made to not "waste" space around many, many small islands. I tested. Blender produces average margin So it is consistent, but still hard to control on Hipoly (where live margin change can be very slow and it is hard to catch proper size of pixels) ![29002504.png](https://archive.blender.org/developer/F10319487/29002504.png) I remember, that once it was per individual islands and it was bug. Sorry for misleading about it.

Eugene Du commented

2021-08-24 18:39:25 +02:00

at least give us example how to calculate 1 pixel with margin between islands?

Vyacheslav Kobozev commented

2021-08-24 21:22:15 +02:00

Added subscriber: @1D_Inc

Vyacheslav Kobozev commented

2021-08-24 21:22:15 +02:00

In #90782#1210909, @APEC wrote:
at least give us example how to calculate 1 pixel with margin between islands?

I made 2 tests and it is totally unpredictable: it is relative to average island size BUT! for smaller islands it makes bigger margins…
@lichtwerk so it looks like it counter-proportional to island size… It is just wrong and should not work like this.
So the minimal request is fixed UV-relative size where 0.01 is 1% of UV.
OFC no hurry and low priority because no one will pack with vanilla packer for production.

@1D_Inc look here, you will «like» such weird thing. How do you call it? Workflow bug?

> In #90782#1210909, @APEC wrote: > at least give us example how to calculate 1 pixel with margin between islands? I made 2 tests and it is totally unpredictable: it is relative to average island size BUT! for smaller islands it makes bigger margins… @lichtwerk so it looks like it counter-proportional to island size… It is just wrong and should not work like this. So the minimal request is fixed UV-relative size where 0.01 is 1% of UV. OFC no hurry and low priority because no one will pack with vanilla packer for production. @1D_Inc look here, you will «like» such weird thing. How do you call it? Workflow bug? ![29031613.png](https://archive.blender.org/developer/F10319959/29031613.png) ![29042513.png](https://archive.blender.org/developer/F10319961/29042513.png)

Vyacheslav Kobozev commented

2021-08-24 21:22:53 +02:00

In #90782#1210909, @APEC wrote:
at least give us example how to calculate 1 pixel with margin between islands?

there is no way to count it as far as it "work" this way

> In #90782#1210909, @APEC wrote: > at least give us example how to calculate 1 pixel with margin between islands? there is no way to count it as far as it "work" this way

Paul Kotelevets commented

2021-08-24 22:48:17 +02:00

In #90782#1210961, @Vyach wrote:

@1D_Inc look here, you will «like» such weird thing. How do you call it? Workflow bug?

I would call this a gamedev workflow issue, or better - a gamedev workflow limitation.
Such problems are not bugs, but they represent serious limitations of the scope of a program.
Unlike other workflows, precise UV margin in pixels is a gamedev modeling workflow requirement.
If it is assumed that Blender is supposed to be used for producing gamedev (up to AAA) models, it should contain the ability to set precise UV margins in pixels.

> In #90782#1210961, @Vyach wrote: > @1D_Inc look here, you will «like» such weird thing. How do you call it? Workflow bug? I would call this a gamedev workflow issue, or better - a gamedev workflow limitation. Such problems are not bugs, but they represent serious limitations of the scope of a program. Unlike other workflows, precise UV margin in pixels is a gamedev modeling workflow requirement. If it is assumed that Blender is supposed to be used for producing gamedev (up to AAA) models, it should contain the ability to set precise UV margins in pixels.

Vyacheslav Kobozev commented

2021-08-25 02:25:51 +02:00

In #90782#1210972, @1D_Inc wrote:
I would call this a gamedev workflow issue.

Mipmapping depends on pixels anyway.
So it is good to keep margin big enough, but not too big (and save some UV space)
Sure, in the game-design it is more desirable option.

> In #90782#1210972, @1D_Inc wrote: > I would call this a gamedev workflow issue. Mipmapping depends on pixels anyway. So it is good to keep margin big enough, but not too big (and save some UV space) Sure, in the game-design it is more desirable option.

Paul Kotelevets commented

2021-08-25 13:33:38 +02:00

In #90782#1210990, @Vyach wrote:

In #90782#1210972, @1D_Inc wrote:
I would call this a gamedev workflow issue.

Mipmapping depends on pixels anyway.
So it is good to keep margin big enough, but not too big (and save some UV space)
Sure, in the game-design it is more desirable option.

Well, yes, however, it is not a bug or a corrupted/lost functionality (it is not a workflow issue that arose as a result of a redesign process), so I am not sure that a bugtracker is an appropriate place for it.
It appears to be a better fit for an improvement proposal format to expand the scope of the program to meet the requirements of an industry-demanded workflows.
Current realization is working and is still useful, but for a limited range of modeling workflows - like architectural modeling, where you don't care as much about UV because that's where you can afford just about any kind of UV mess.

> In #90782#1210990, @Vyach wrote: >> In #90782#1210972, @1D_Inc wrote: >> I would call this a gamedev workflow issue. > Mipmapping depends on pixels anyway. > So it is good to keep margin big enough, but not too big (and save some UV space) > Sure, in the game-design it is more desirable option. Well, yes, however, it is not a bug or a corrupted/lost functionality (it is not a workflow issue that arose as a result of a redesign process), so I am not sure that a bugtracker is an appropriate place for it. It appears to be a better fit for an improvement proposal format to expand the scope of the program to meet the requirements of an industry-demanded workflows. Current realization is working and is still useful, but for a limited range of modeling workflows - like architectural modeling, where you don't care as much about UV because that's where you can afford just about any kind of UV mess.

Paul Kotelevets commented

2021-08-25 19:55:55 +02:00

Added subscriber: @DanielBystedt

Paul Kotelevets commented

2021-08-25 19:55:55 +02:00

In #90782#1210990, @Vyach wrote:

Sure, in the game-design it is more desirable option.

@DanielBystedt was planning some gamedev-related UV enhancements, you can check if such a functionality was proposed by him.

https://developer.blender.org/project/board/115/

> In #90782#1210990, @Vyach wrote: > Sure, in the game-design it is more desirable option. @DanielBystedt was planning some gamedev-related UV enhancements, you can check if such a functionality was proposed by him. https://developer.blender.org/project/board/115/

Paul Kotelevets commented

2021-08-26 23:29:08 +02:00

It could also be related to this task by Felinto.
https://developer.blender.org/T68889

It could also be related to this task by Felinto. https://developer.blender.org/T68889

Chris Blackbourn commented

2022-09-22 08:30:53 +02:00

Added subscriber: @Chris_Blackbourn

Chris Blackbourn self-assigned this 2022-09-22 08:30:53 +02:00

Chris Blackbourn commented

2022-09-22 08:30:53 +02:00

(hopefully) coming soon

(hopefully) coming soon ![image.png](https://archive.blender.org/developer/F13551711/image.png)

Vyacheslav Kobozev commented

2022-09-22 11:59:16 +02:00

In #90782#1421006, @Chris_Blackbourn wrote:
(hopefully) coming soon

Good!

> In #90782#1421006, @Chris_Blackbourn wrote: > (hopefully) coming soon Good!

Chris Blackbourn commented

2022-10-01 07:26:40 +02:00

With D16121 Choose "Fraction" for the Margin Method

![image.png](https://archive.blender.org/developer/F13601060/image.png) With [D16121](https://archive.blender.org/developer/D16121) Choose "Fraction" for the Margin Method

Paul Kotelevets commented

2022-10-01 13:57:36 +02:00

Looks interesting!
I guess, the next step value conversion to pixels?

By the way, a link to an explanation why values in pixels are important (in case if it wasn't clarified properly)
http://wiki.polycount.com/wiki/Edge_padding

(Also, some UV unwrappers has the ability to display margins borders visually - which is mostly used for manual packing or checking the result)

Looks interesting! I guess, the next step value conversion to pixels? By the way, a link to an explanation why values in pixels are important (in case if it wasn't clarified properly) http://wiki.polycount.com/wiki/Edge_padding (Also, some UV unwrappers has the ability to display margins borders visually - which is mostly used for manual packing or checking the result)

Chris Blackbourn commented

2022-10-01 22:00:44 +02:00

Aye, you can enter pixels manually as a fraction, e.g. write "4/256" into the Island Margin text entry

I didn't put them in D16121 because if the texture is non-square, (e.g. 305px * 713px), then internally the pixel margin becomes two different values, margin_u and margin_v, and that would have made the differential a bit more complicated.

Feel free to create a new Task for "Pixel" based margin, or any of those texture baking / padding tools.

Aye, you can enter pixels manually as a fraction, e.g. write "4/256" into the `Island Margin` text entry I didn't put them in [D16121](https://archive.blender.org/developer/D16121) because if the texture is non-square, (e.g. 305px * 713px), then internally the pixel margin becomes two different values, `margin_u` and `margin_v`, and that would have made the differential a bit more complicated. Feel free to create a new Task for "Pixel" based margin, or any of those texture baking / padding tools.

Paul Kotelevets commented

2022-10-02 14:21:36 +02:00

Looks interesting.
So 4/256 value will represent 4 pixels per 256 pixels side margin value, and all mipmap padding sizes that has the same fraction?
Sounds versatile.

How about to use 256/4 format instead of 4/256?
Or it will decrease while value increases so it will be better readable, but feel counterintuitive?
From other side, its fraction anyway, and the resulting value will be easier to store and manipulate with ...

Looks interesting. So 4/256 value will represent 4 pixels per 256 pixels side margin value, and all mipmap padding sizes that has the same fraction? Sounds versatile. How about to use 256/4 format instead of 4/256? Or it will decrease while value increases so it will be better readable, but feel counterintuitive? From other side, its fraction anyway, and the resulting value will be easier to store and manipulate with ...

Vyacheslav Kobozev commented

2022-10-04 07:14:50 +02:00

In #90782#1426312, @Chris_Blackbourn wrote:
Aye, you can enter pixels manually as a fraction, e.g. write "4/256" into the Island Margin text entry

I have tested this approach and it do not work.
Because fraction do not related to UV size, it related to average island size ore something like this.
But I even do not want to test it, because there should be predictable value.

> In #90782#1426312, @Chris_Blackbourn wrote: > Aye, you can enter pixels manually as a fraction, e.g. write "4/256" into the `Island Margin` text entry I have tested this approach and it do not work. Because fraction do not related to UV size, it related to average island size ore something like this. But I even do not want to test it, because there should be predictable value.

Chris Blackbourn commented

2022-10-04 07:24:06 +02:00

Hi @Vyach , apologies, you will first need to apply the Differential in D16121, build a custom version of Blender, and then select the new "Fraction" margin method to test.

The fraction will be related to the 0..1 unit square, so if your texture is 256 pixels wide, then entering "4/256" == 0.015625 will correspond to a 4 pixel margin around each island, giving a total of 4+4=8 pixels between islands.

We will most likely eventually add a "Pixel" margin method, but as discussed above, specifying a pixel-margin makes the code quite a bit more complicated because the user can have a texture where the width and height are different. That extra complexity is not supported in the current Differential.

Hi @Vyach , apologies, you will first need to apply the Differential in [D16121](https://archive.blender.org/developer/D16121), build a custom version of Blender, and then select the new "Fraction" margin method to test. The fraction will be related to the 0..1 unit square, so if your texture is 256 pixels wide, then entering "4/256" == 0.015625 will correspond to a 4 pixel margin around each island, giving a total of 4+4=8 pixels between islands. We will most likely eventually add a "Pixel" margin method, but as discussed above, specifying a pixel-margin makes the code quite a bit more complicated because the user can have a texture where the width and height are different. That extra complexity is not supported in the current Differential.

Vyacheslav Kobozev commented

2022-10-04 16:23:19 +02:00

In #90782#1427220, @Chris_Blackbourn wrote:
Hi @Vyach , apologies, you will first need to apply the Differential in D16121, build a custom version of Blender, and then select the new "Fraction" margin method to test.

Oh, I see. Sadly I cant build by myself. But okay, I see the Idea. Fraction is okay for me, it is flexible and do not bonded to image/resolution, only to UV 0—1 But on the user side i know, many ppl would prefer two digits: pixels and image resolution. And in case if image opened and seen under UV — just to use/get its resolution.

So idk, may be both will be fine as options.
Anyway i would be glad to have any of two if method will allow to set pixel size manually and will not break when image is non-quad.

> In #90782#1427220, @Chris_Blackbourn wrote: > Hi @Vyach , apologies, you will first need to apply the Differential in [D16121](https://archive.blender.org/developer/D16121), build a custom version of Blender, and then select the new "Fraction" margin method to test. Oh, I see. Sadly I can`t build by myself. But okay, I see the Idea. Fraction is okay for me, it is flexible and do not bonded to image/resolution, only to UV 0—1 But on the user side i know, many ppl would prefer two digits: pixels and image resolution. And in case if image opened and seen under UV — just to use/get it`s resolution. So idk, may be both will be fine as options. Anyway i would be glad to have any of two if method will allow to set pixel size manually and will not break when image is non-quad.

blender-admin commented

2022-10-11 23:57:17 +02:00

This issue was referenced by c2256bf7f7

This issue was referenced by c2256bf7f714bbd41388af3e184b3d84b496fbf3

Chris Blackbourn commented

2022-10-12 00:09:21 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Resolved'

Chris Blackbourn closed this issue

2022-10-12 00:09:21 +02:00

Chris Blackbourn commented

2022-10-24 05:59:42 +02:00

Hi @Vyach , have you been able to test this in the nightly build? Are you still wanting the 'pixel' option, or is it okay as is?

Vyacheslav Kobozev commented

2022-10-24 10:02:12 +02:00

In #90782#1436492, @Chris_Blackbourn wrote:
Hi @Vyach , have you been able to test this in the nightly build? Are you still wanting the 'pixel' option, or is it okay as is?

Yes, tested. Now fraction mode works properly after unwrap too (fixed bug)
And yes, thats enough for me as pixel magin, thanks!

> In #90782#1436492, @Chris_Blackbourn wrote: > Hi @Vyach , have you been able to test this in the nightly build? Are you still wanting the 'pixel' option, or is it okay as is? Yes, tested. Now fraction mode works properly after unwrap too (fixed bug) And yes, thats enough for me as pixel magin, thanks!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UV: unwrap. Margin size is not related to any useful measure #90782