- User Since
- Apr 5 2016, 5:57 AM (41 w, 5 d)
The issue you are having is not actually related to shape keys, but rather the fact that the Mesh Deform modifier only works with manifold (closed) cage meshes, while your "head" mesh is non-manifold. The bind will succeed, and you may be able to get the result you are looking for, simply by closing all holes in the cage mesh.
Fri, Jan 20
Wed, Jan 18
Hey, thanks for the review @Sergey Sharybin (sergey). I'll probably be able to submit an updated patch by next week.
I have answered inline to a few of your comments, but for the vast majority I totally agree with your notes :)
Tue, Jan 17
Sun, Jan 15
Resolved the little mistake I mentioned in the last comment, did a bit of general cleanup, and removed the last couple of warnings I had forgotten about.
Sat, Jan 14
I have looked at this after we talked on IRC, and the memory estimate is indeed the estimated ram usage during simulation (though quite a poor one at that...), and has no relation to the size of the final cache.
Just some minor cleanup. Btw, kept nr as unsigned int instead of size_t, to keep consistency with the other math functions, especially because this function makes calls such as cross_poly_v3, which doesn't like size_t without casts and stuff...
I found a little regression along my SDef development, that causes minor artifacts on some binds, so I'll have to fix that. Also, I'll replace the angle functions, now that @Bastien Montagne (mont29) pointed out to me that we have a better builtin function (I guess I'm just too used to thinking of vector angles as arccos dot... lol).
Wed, Jan 11
Updated this to reflect the changes in D2461, and also removed the custom meanValueCoordinates function in favor of Blender's built-in interp_weights_poly_v2.
Yes, I understand that it is undesirable to assume things, even though this is a fair assumption, as the fourth weight is meaningless for any polygon with three vertices, and setting it to 0 is actually just as random as any other value...
Thanks for the heads up @Tamito Kajiyama (kjym3).
I've changed it (should probably have noticed the rest of the code using only isnan in the first place :P).
Tue, Jan 10
Indeed, only triangles can have their true centroid found this way, for all the other polygons the average point does not necessarily match the centroid.
I'm reopening this, because I realized that I shouldn't try to fix it by having everything cached and then rolling back once you go to to a point in time before a cache gap. Having a simulation with a time gap in it doesn't actually make any sense at all, so I realized that I should rather prevent the cache from forming such a gap in the first place.
Sun, Jan 8
I finally had some time to look into this...
Sat, Jan 7
I had forgotten to add a little comment explaining why the code was disabled. Added that now...
Fri, Jan 6
Hm, oddly my email didn't notify me about this task being updated...
Thu, Jan 5
@Mateusz (godler), Mesa is an OpenGL implementation. Manjaro likely installed it automatically, but you can check if it is installed and which version, on any Arch based distro, by running pacman -Qi mesa.
This is most definitely a duplicate of T50347, closing.
I suspect this is an issue with Mesa, and not really a Blender problem...
Tue, Jan 3
Dec 22 2016
Like I said above, this doesn't have to be a separate force field type, but rather just a "gravitational falloff" option in the "Force" force field. This is a small enough feature, that it wouldn't really require user demand. Also, I think this is a better option, than misleading the user about the function of the current falloff options (which is already the case, with the mention of gravity in the tool-tip).
Dec 21 2016
Fixed all the issues pointed out by @Bastien Montagne (mont29), and also fixed a little mistake in the vertex range checks (a weight of 0.0 was being returned if the object had no vertex groups, even if the vertex index was out of range).
Indeed, that does partially solve the issue, however, only when your mass never goes within the 1.0 mindist, otherwise, it will encounter a constant force, which will change its orbit (perhaps we should take the force field object's scale into account, for the falloff stuff, so that one can change the actual scale of the distances).