2
$\begingroup$

I am having a UV-Sphere with 23k vertices and 25k faces. I used the Smart UV project to create UV-Coordinates but I was surpries to see that some of the faces are overlapping.

enter image description here

I was able to reproduce that behaviour with a simple plane, which I subdivided two times and then moved two vertices. The Smart UV Project's angle limit must be 89.00.

enter image description here

Is that a bug? I thought every face should have it's own uv-coordinates as well as texture space.

FYI: The first picture was done with Smart UV project Angle Limit 66.00.

UPDATE

This also happens when I use a Smart UV project on a uvsphere where the vertices are moved along their normal with a value out of a noise function. enter image description here This can't be right?

Improve this question
$\endgroup$
2

2 Answers 2

Reset to default
4
$\begingroup$

Smart UV Project simply doesn't guarantee non-overlapping UVs.

It doesn't detect or correct self-intersecting UV's within a UV-island.

Using lower angle limit will typically help to avoid this problem, but there are still cases it could happen.

If the possibility of overlapping UV's is unacceptable, you could use Lightmap-pack instead.

Note, in the example given - there is a lot of noise, One way to resolve could mitigate overlapping could be calculate the UV's on a less noisy version of the mesh:

  • Store the original vertex locations.
  • Smooth the vertices.
  • Execute Smart-Project
  • Restore the vertex locations.
Improve this answer
$\endgroup$
2
  • $\begingroup$ If I use Lightmap-pack than there aren't any texture-islands. That means that when I decimate the mesh (for level of detail) the uv's aren't merged. What do you mean with "there is a lot of noise"? The vertices are manipulated via noise, thats on purpose. The Updated-Example shows a UV-Sphere where the vertices are manipulated, too. But not that much and still happens. Is there a way Smart UV Project could be improved so that something like that isn't happening? $\endgroup$
    – Hamburml
    Jul 27, 2015 at 7:16
  • $\begingroup$ Even though the noise is on purpose, its making some UV tools give worse results (that try to make the texture coordinates follow the surface). Thats why I suggest smoothing the vertices temporarily to calculate UV's $\endgroup$
    – ideasman42
    Jun 17, 2016 at 12:31
1
$\begingroup$

Because there are non-planar/concave quads.

Unfortunately I don't know the math behind the algorithm itself, but I can guess that this kind of faces are not easy to handle for this kind of operation.

Blender has to do calculation about the angle between faces. If that angle overcome a thershold (the angle limit) the edge between faces become a point of discontinuity, a seam.

If the face has an ambiguous geometry, it becames more difficult to have a predictable behavior, as what the modeler sees may not be what the software understand.

enter image description here

The image above shows two possible triangulation of a non-planar quad face. If the modeler doesn't specify which one is the expected geometry, the software could not act as expected.

A predictable behavior can be achieve by solving ambiguities. One (brutal) way is to triangulate (not only the overlapping-uv faces, but a bigger area as adjacent faces are also take in account in the calculation).

Notice in the images below how a triangulate mesh is not affected by overlapping uv.

enter image description here enter image description here

...and in your example:

enter image description here enter image description here

It may not enter in the UV-unwrapping hall of fame,... but at least there isn't any overlap.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Did you triangulate with the triangulate-modifier? Could you upload the screenshots in a higher resolution? And how do you know that a triangulated mesh is not affected by overlapping uvs? In your screenshot the texture space is overlapping, isn't it? $\endgroup$
    – Hamburml
    Jul 21, 2015 at 6:34
  • 1
    $\begingroup$ No, i triangulated with <kbd>Ctrl</kbd>+ <kbd>T</kbd>. Sorry, I thought they were bigger...And you are right..there are still some small overlaps! I'll check this fact and extend the answer as soon as possible $\endgroup$
    – Carlo
    Jul 21, 2015 at 10:02
  • $\begingroup$ You are right! In corrispondence with great angle differences tris are stitt not able to avoid overlapping it.tinypic.com/r/9u4qwj/8. Currently I can't give you a proper answer...I hope somebody will $\endgroup$
    – Carlo
    Jul 21, 2015 at 10:13
  • $\begingroup$ Thank you for your help! Maybe that's a bug in the implementation of the algorithm which hasn't attracted someones attention because normally you don't have that extreme spikes in a mesh. $\endgroup$
    – Hamburml
    Jul 21, 2015 at 11:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .