- User Since
- Jan 20 2018, 12:00 AM (70 w, 2 d)
Jan 30 2019
Not sure if you're asking me, but whether something's a bug or not is in the eye of the beholder. If you were to see cross3(vec3, vec3) and normalizedCross3(vec3, vec3) in some library, and both gave identical output, one or the other or both would be a bug. Even if they had identical code-- just on the basis of the name. Same as there's nothing buggy about a function named returnZeroNoMatterWhat(vec3), so long as it does what it says.
Coming back to add that there's a reasonable workaround, which is to use a vertex weight proximity modifier to determine the distance from each vertex before the weight transfer, use a custom (constant) curve to modulate that vertex group, and then use it to modulate the data transfer. It's a bit more work for the end user, but perfectly reasonable, and it wouldn't seem unreasonable to just drop support for max distance from the data transfer.
Jan 24 2019
Thank you for taking the time to consider it.
I think you might not understand. I don't care about the original UV map. The issue is that the mesh will not accept any kind of UV mapping from modifier after the creation of the mesh. The problem is not that the mesh doesn't keep a UV map from before the skin modifier, that's obvious. The issue is that no UV map can be created following the skin modifier-- unless you apply the skin modifier.
Dec 14 2018
Apr 4 2018
Jan 21 2018
Thanks. That's from another add-on (that shouldn't be messing with anything in this case, but apparently is.) I'll contact the developer of that add-on and reference this thread, let them know what's going on.