View Full Version : UV>Weight skipping some points/ the spring thread

08-22-2015, 05:46 PM
So, in relation to the spring thread:

I'm attempting to use UV to Weight to assign the V coordinate as a weight to all the points, after UV mapping the spring using ABF Unwrap.

It appears that the points that the dividing line is established on, the ones that show in Red in the UV window, do NOT get assigned to a Weight Map when using UV to Weight, UNLESS you UnWeld them first. Which makes sense, because in their "both ends red" UV state the points have TWO sets of UV values, and which to use? Apparently the answer is "punt", and they are not added to the Weight Map at all. (Which is good, because it makes them a lot easier to spot.)

If you first UNWELD, run UV>Weights, and then MERGE POINTS, it seems to work perfectly well.

So, one proper workflow appears to be:

Establish a dividing line for ABF (Edges)
save it as a selection set (Points)
Select the set again
Apply UV>Weights

At the end you have a Weight Map defined by the U or V coordinates.

I did this hoping that the UV coords were clamped at 0% and 100%, but this turns out not to be the case, dangit. That would have made creating the stationary/undistorted bits slightly easier, and far more graphic to select in the UV window. But, one can still manually select them (save the sets!) and set the wmap values by hand.

I'm posting this just as a cautionary tale, because it was such a huge PITA to figure this out, and it might help somebody someday.

08-22-2015, 06:53 PM
I did this hoping that the UV coords were clamped at 0% and 100%, but this turns out not to be the case, dangit.

It would be bug, if they would be clamping automatically. UV outside of 0.0...1.0 is perfectly fine.
It's can be even used, especially in apps that have single UV map per layer/object.

Imagine plugin which is taking UV map for vertex v, then doing u' = floor( u ); and u'' = u - u' to get fraction,
then it can be used as index to image in image-sequence..

08-22-2015, 09:54 PM
Would PX UV Creeper be a better way to unwrap the spring?


08-22-2015, 10:20 PM
I doubt it: it's not anything about the unwrap (although maybe it would be straighter in the UV map space) it's just that without unwelding it's ambiguous where a point is(???) in UV space?

But, I'm moving on to nodal issues now. :thumbsup:

08-22-2015, 11:10 PM
I'm getting something similar.
Weight along ABF seam edge=0.... even along entire V distance in UV space.

08-23-2015, 12:22 AM
Did you Unweld?

08-23-2015, 08:31 AM
:D Yes, I did. I might be confusing myself.... but, technically I don't think that works.
In a sense you are robbing Peter to pay Paul. As you correctly point out you can't have two values for a single point location.
So unless you're willing to leave those points unwelded (iirc your model was SubD so I don't think you are)..... The original welded UV seam seems to default to the lower value. If you unweld > create weight from UV > and merge, the seam defaults to the higher value. You're just not seeing it because the values differences are so small on the ABF unwrap.

Another reason why Creeper is better here. The map is perfect.... no difference in value across seam.

08-23-2015, 08:38 AM
:D Yes, I did. I might be confusing myself.... but, technically I don't think that works.
Worked here.

08-23-2015, 08:43 AM
Care to share model?

08-23-2015, 08:52 AM
Here's an extreme example.
Welded seam on left are all close to 0.... on the right close to 1. 129422

Straight UV to weight 129423. 0 value along whole seam.

Unwelded > UV to weight > merge 129424. 1 value along whole seam.

It has to be one or the other.... I really don't think it calculating an average.

08-23-2015, 09:11 AM
Here's the whole, not quite working, scene. 129425
While getting the values correct would be nice, without Unwelding the points weren't being added to the wmap at all.

(watches animation again) Except for the obvious problems, that's a really nice spring.