IMPROVING AUTOMATIC UV UNWRAPPING

Hello,

What's this article all about? Well it’s about the "pelting" systems that currently exist and how we can improve on them.

Firstly let’s take a simple model of a pair of shorts. See image.
Now let’s take a look at the uv generate by RoadKill. See image.
Now let’s take a look at the uv checker pattern on the shorts. See image.

While the uv is simple to paint in this for we can see that it still is stretched.

This stretching / compression is typical across all of these "pelting" systems.

So here is a quick (simplified) summary of two alternative methodologies to reduce / eliminate this effect.

First is inserting geometry based on a point density function (thank you vladimir jankijevic / kerry), this is where all of the vertex distances are calculated and normalized to give a density of the vertices across the whole object. This is where white means more points are closer together, black further apart. See image. This functionality can then be utilized to insert geometry (complete edge loops) into the uv / object too ensure that the PD function remains constant. We do assume that edge loops are complete throughout the model, effectively limiting its practical use to certain types of geometrical objects. This methodology may well have drawbacks because of the insertion of edge loops, specifically in terms of workflow, in that and weight maps, vertex painting would effectively be destroyed, and have to be recreated. This would typically affect any painting for skeletons and or deformers as the geometry would have changed. Still if the methodology was done at the initial stage it would not be hampered by this recreation of maps. Though from tests, specifically the deformation of objects would require more effort depending on the new edge loop placements.

Second is a similar methodology that being that the edge lengths / polygon area for each polygon in the mesh is computed, and then normalized to generate a 0 to 1 range, effectively a Polygon Area Density Function. The pelting system either as a post effect or possibly built in to the actual stretching would take into account the normalized polygon area and keep the ratios of each polygons area a constant while unwrapping them, this would ensure that the amount of stretching would be minimized.

Again our (rough) tests have show that a post processing approach to this maybe be just as good. It also shows that the edge loops and broken loops are really not important, as you’re looking at each area of every polygon, and the normalization of all polygons area sizes ensures that "scale" across edge loops or not is preserved, and that each polygon with respect to every other polygon is again preserved.

A recursive approach could be simply employed to effectively use the normalized area as a goal, rather than an ideal. By using this approach to keeping the poly areas constant one could achieve a "scaling factor" that would be an overall ending goal of 1,which would indicate that the polygons are all at their original area. Where as the starting point would be a 0 indicating that no processing has taken place. The system could then progressively try to reach this end goal, but allowing the user to halt the process at any time. This then has the benefit, that if this was implemented in this way the overall stretch would remain constant across all polygons rather than just an erroneous few.

 Of course it goes with out saying the this goal driven route would depend on the users cpu abilities, and thus a further justification of using it as a post process rather than a direct connect into the logic of the pelting system.

Further the existing code for the pelting system does not need to be amended, as post processing could give the user a choice to improve the pelt and the amount of time they wanted to let the system use on achieving this goal. Which allows the user, rather than the system, to be the artist in best understanding where to stop this process.

I've decided to mention these thoughts based on tests we've done, here rather than "make a product" from it. In the hope that the people from the open source community can take the concept and use it to make their systems even better. Surely benefiting us all in the end, because no-one "likes" uv-unwrapping.

Steven