- User Since
- Jan 20 2018, 12:00 AM (143 w, 3 d)
Thu, Oct 8
Just as a work-around, considering that this is related to a current, probably commercial, project, baking to visual keyframes should eliminate the weird in-betweens that happen from animated child-of influence.
Sep 14 2020
Thanks, sorry for the duplicate.
Aug 11 2020
While it does, that's not the cause of the problem. While investigating this for OP, one of the things I did to troubleshoot it was to create brand new geometry at the same positions, with the same angles-- just two quad faces, sharing an edge, triangulated (but that doesn't matter), with vertices snapped to the same positions as the original geometry. This new geometry showed the same problems, with the same fixes, even when giving it a solidify modifier to make it fully manifold.
Aug 10 2020
It's shocking to me that a few hundred units (meters) is leading to precision issues. (Applying scale doesn't fix the problem, just moving closer to world origin.) It would be easy to imagine animators that wanted to cover that distance in a single take. It's also surprising to me that Cycles is calculating in world space rather than camera space. (Maybe to maintain a static BVH or something? But then, there ought to be some options for which space it operates in.) Moving geometry is not always an option, because of things like physics (inertia is tied uncontrollably to the world.)
Jul 11 2020
Feb 18 2020
Extra info: problem exists regardless of linear, cubic, or smart filtering. No problem, of course, with closest (no mip) filtering.
I was mistaken about this being also true of data transfer modifier. Custom normals from a data transfer modifier are being read correctly by a displace modifier. For that matter, they're also reading custom normals from a normal edit modified mesh appropriately. In fact, this can be used as a workaround-- make one mesh, likely non-rendering, to get the normal edit modifier, and a second mesh to copy normals via data transfer from the first mesh.
Feb 17 2020
Since this could potentially be related to specific hardware, here's a screenshot:
Jan 29 2020
I know this is old, and apparently not going anywhere, but lerped component interpolation is still a problem with Blender. Particularly with abstract or mechanical animation, or when exporting animation (as what you see ends up not being what you get.) And it's one of those problems that requires enough technical expertise that most users aren't even going to realize what's happening and are going to bang their head into the wall and eventually give up.
Jan 21 2020
That's not inappropriate, that's a link to the actual commit. Very helpful for us.
Jan 13 2020
And, in anticipation....
@Sybren A. Stüvel (sybren) Please take another look. The issues remain if you connect finger1-1.R to its parent. If you need, I've done this for you in the attached file.
Nov 7 2019
Oct 28 2019
Just wanted to add to this with some additional problems I've discovered with normalizing the cross vector.
Oct 7 2019
Sep 26 2019
Sep 13 2019
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.