UV mapping: bug or ( boring ) feature ?

[pitibonom]

Hi all
i got a question about UV unwrapping. Though the unwrapping behaviour after pressing U sometimes ( rarely ) gives
a correct/expected result, it often behaves randomly and uses to do some strange unexpected and above all illogical
results.

Lemme explain with a lil pic:

It’s a simple-like-hell mesh made of 4 tris and quad faces. I unwrapped the two leftmost faces and trimmed UVs by hand. There come the ‘A’ part of the pic… Now that i got what i want with those 2 faces, i select the 2 other ones, and hit U->unwrap.
The result i obtain is showed ( against all odds ) in B part of the picture. In all logic, the 2 last faces wich are coplanar with the 2 first ones should unwrap AT LEAST toward the right ( good ) direction. Instead of this, the angle of the common edge is used as a ( something like ) mirror axis and vertices are unwrapped uncorrectly.
There comes then the B part of the picture.
Finally i edited this by hand and showed in the C part of the pic what would be normally expected ( i’d say this is the
kind of logic a 5 years old child could show up )

What do you all think about that ?
Is it a bug ? malfunction ? feature ( to leave hours of work to modeling ppl ) ?

Or maybe ( i confess i dunno all the tips and tricks of blender ) i’m missing someting ? a parameter somewhere ?

I also have to mention, that flipping the normals of those faces, give a more correct unwrap. Though perpendicular-in-3D edges are not unwrapped to perpendicular-in-2D UV edges, at least it unwraps the last two faces on the
correct side of the two first ones…

Any clue would really be appreciated

regards.

EDIT: Of course, changing all the parameters in the Tool param window does not solve the problem.

[dukejib]

To get the “C” part directly, press “U” and select “Project From View” . There are many options in Unwrap menus , play with them. Also, after Selecting any option from “U” menu Press F6 immediately to some more options.
Blender is a bit different from other 3d Apps, hence the learning curve.

[pitibonom]

Thanks for the clue
It’s now been hundreds hours i play with them and i don’t need to try this out that the ‘project from view’ unwrap also relocates
pinned UVs and have no option at all. The only way to unwrap faces without changing pinned UVs coordinates is the ‘unwrap’ function wich unwraps the vertex not properly ( i mean with no logic )

As i ‘EDITED’ in my previous post: <<Of course, changing all the parameters in the Tool param window does not solve the problem.>>

And FYI unwrapping a mesh ‘from view’ exactly does what it says: it unwraps the mesh from the 3D view axis by parallel-projecting verts on a plane that is coplanar to the screen. And this function works perfectly indeed, but this is not what i want.

Anyone for any clue please ?
regards.

[pitibonom]

noone able to say wether it’s a bug or normal behaviour ?

[Sanctuary]

If only when inverting the normals your unwrap is going as expected, it sounds like a bug
Because regardless of the normals an unwraping leading in overlapping faces is certainly not something you may want for this kind of situation.

You should report this on the bug tracker (but check first on a buildbot version of Blender if it still unwrap wrongly) :
http://projects.blender.org/tracker/?group_id=9&atid=498

So at least if this is a bug there’s a chance it will be fixed before the incoming 2.66 release.

[wccrawford]

It could be a bug.

However, unwrapping is incredibly complex, and supporting some of the more complicated stuff may cause weird things to happen with stuff that seems obvious to us as humans. It’s important to keep that in mind when dealing with complex code.

[RickyBlender]

tyi this video
might help

http://vimeo.com/52705809

happy blendering

[pitibonom]

Hi all !
Thanks for your answers

@Rickyblender: This lil video is very interresting, but is much more about how to tile textures and set them up in materials so that they look seamless, than about UV unwrapping of faces on a map. Thanks though for the ling

@wccrawford: Yes i can imagine that unwrapping algorythms are very complex as unwrapping 3 dimensions to 2 dimensions uses to lead to mathematical unsolvable cases. However, as i said, what am talking about is not complex variation on discrete surfaces converted to
D-1 topology. Am talking about a case easily solvable by a 5 years old kid: A face connected to another one. the 1st one is properly unwrapped, and you see the 2nd one in a 3D context. please imagine what this 2nd face will look like after unwrapping.

#Sanctuary: yes santuary, face normal flipping leads to an unwrapping of the 2 last faces on the correct side of the already unwrapped and pinned faces. So in your opinion, this would be a bug ? I agree that normal side should not influence the unwrapping, but it does in this case. In the 2.66 RC the problem still exists. I also noticed this behaviour on perfectly square connected faces. It looks like as if unwrapping would depend on the order vertices are retrieved in lists for creating the new 2D topology from the 3D one.
Aside it is really boring, as i use to trim all my unwraps by hand, it appears to have no clear rule.
Then if you confirm this could be a bug, i’ll file one…
Tell me wether a .blend would help for really ‘seeing’ the problem

regards to all.
EDIT: OK, here the blend. I throwed everything away and only kept the 3 faces i showed in the pictures in my 1st post…
unwrap_bug.zip (142 KB)

[Sanctuary]

I managed to reproduce it on r54487 downloaded today on the Buildbot.
Even if the unwrap is not very good regrading the stretching of the faces, just selecting all and pressing U -> Unwrap result in the overlapping faces, and when pressing CTRL+N (that will flip all the normals in the case of this model), pressing U->Unwrap gives the expected result.

I think it is a real bug, but when i report what i think is a bug, sometime it is considered as one by the devs and sometime it’s rejected as it’s “expected” behaviour even if not satisfying for the user.

Still reporting is the best way to go in my opinion, because if it is really a bug and not something obscure for non-coding users, the devs should be able to do something about it.

And better reporting it now as the devs are in the “bugfixing” status of the last development part before the 2.66 release

[pitibonom]

okies sanctuary. many thanks for taking time to give this a try and for your advice.
I’ll report this as a bug linking the blend and the url of this discussion. Would be neat if devs implement a ‘pitibonom button’ in the TOOLS window to artificially switch normals while unwrap
OK i confess it would be a dirty answer to the question, but damn convenient !

regards.

[pitibonom]

ok./ just submitted it at bug tracking:
http://projects.blender.org/tracker/index.php?func=detail&aid=34216&group_id=9&atid=498

wait and see what dev team says…

[Psy-Fi]

A five year old could indeed possibly flip the unwrapped faces as is done in your example but I understand an adult could get there too by projecting from view, pinning and then unwrapping. In general, the normal does influence the unwrap result. I’m not sure if this can be fixed for the arbitrary case.

[pitibonom]

Hi Psy-Fi.

Yes am not sure either. Topology algorythms are this complicated that they can not handle all cases. Of course, when i troll, saying that even a 5 yold kid could solve the problem, am assuming that my case is a simple one. But in the point of view of the algorythm, which have a generic approach, it’s just handled as if my mesh would have thousands Bmesh faces with normal in and out etc…
This might be the reason why there’s no button in blender called ‘make my model, texture and animate it’…

When a computer have several solutions to a problem, it can hardly choose obviously between them ( provided a computer can be ‘obvious’ then it offers one, and if the user is satified with it, he wins, if he’s not, he looses.

Therefore, i was thinking about something that could be very convenient, and might let the user choose. If the normals influence
the unwrap ( wich is not totally absurd, depending on how is coded the unwrap routine ) and if the user is sometimes satisfied with the unwrap result and sometimes not, and then have to flip normals, and unwrap again, then why not implement a small checkbox ( that i previously called ‘pitibonom button’ but that could be called ‘unwrap with flipped normals’ ) and let the user choose what result is best for him ?

IMHO it’s a 10 minutes-coding simple solution with no headache for the coders and big happyness jumps for users like me

but well this is just an idea…

[pitibonom]

Back there for some lil news.
Brecht Van Lommel in the bug tracker moved the case to the todo list. in his opinion, the behaviour i’m talking about is a normal behaviour, though it’s not totally convenient. From brecht point of view, the unwrap function could be enhanced so that it wisely
consider normals before unwrapping, though it might be a hard thing to code…
I offered him the idea of the ‘pitibonom button’ that would IMO request less coding effort and pretty efficient solution to the problem.
waiting for his answer now.

thanks all.

[pitibonom]

Back again on the subject.

Am not familiar to all the blender dev processes with nightly builds and all this. Therefore i didn’ realised Brecht Van Lommel
submitted a fix on the case shown in this thread, and that this fix is now integrated in the 2.66 RC1.
I just downloaded this RC and tried out the blend i also posted here.
The result is pretty what i expected. Consequently, i send a BIG thank to Brecht !
Now the unwrap gives the same result whatever are the normals of the faces that are unwrapped.

I’ll dig though in the subject this week as i have some few hundreds of faces to unwrap like this, and will
give a feedback here and in the bug tracker.

Nevertheless io think that this case might be closed. With thanks to all and special big one to Brecht Van Lommel.

Have nice blends !!!