This auto/heat vgroup creation seems to be fuzzy/unstable (each run gives a slightly different result). I have not the competences (nor time) to investigate that laplacian stuff, so for now just adding an option when parenting to an armature with envelope/heat, to mirror weights along the X axis (as it is done by default when doing it from the Weight Paint mode).
This deadlock was caused by lock of threads using LOCK_DRAW_IMAGE
mutex and lock used in render result acquire functions.
So if image draw would lock LOCK_DRAW_IMAGE before compositor
operation released render result it'll lead into a deadlock.
Refactored code a bit to make naming a bit more clear and added a
function to create mesh from given display list rather than from
object's displist.
Tested using plain curves (which doesn't imply using derived meshes)
and curves with constructive modifiers (which are using derived meshed).
notes:
- uncomment #define USE_RASKTER in BKE_mask.h to use the previous mask rasterizer.
- slightly slower for regular masks but significantly faster for feather.
- main benefit is that it threads well so works nice for tile compositor.
- feather is lower quality, can use some improvements here.
- feather can also use some interpolation enhancements, will do later.
This commit adds "shift" and numtype to both Bevel and Inset mesh operators.
It also gets rid of the magicnumber used in NumInput to str operation (currently, 20 chars per element, now defined as NUM_STR_REP_LEN in ED_numinput.h).
Problems were in the old multires loading system.
Actually, the sigsev itself was the easy part of the job (simply had to convert from tesselated data to polys/loops), but after that I was getting a horrible bunch of wild stray faces...
It finally turned out it was a mismatch in two different subsurf structs used while computing a mdisps layer from the multires DM, leading to getting complete random normals (null ones, NAN ones...), leading to complete dummy tangent space matrix, leading to absurds mdisps values...
Note: I also moved the copy of first layer's vertex and face data from old me->mr to mesh's v/fdata earlier in multire_load_old(), to be able to use general face_to_poly conversion function (later on we would have to do it by hand, the general function would erase our newly computed mdisps layer...).
Took me the whole week (something like 20h) to track this down: multires + subsurf = C nightmare!
Issue was caused by threading conflict between compositor output node which
is freeing buffers used by render result image and image draw code which
could use buffers at the same time as compositor frees this buffers.
Solved by adding adding lock around viewer image invalidation and image
drawing.
Use renamed LOCK_PREVIEW mutex for this, which si not called LOCK_DRAW_IMAGE.
With new compositor locking for preview is not needed so it could be removed.
Added the same lock around viewer operation which also frees buffers used
by viewer image. It's actually quite difficult to check whether this is
indeed needed. This code seems to be using acquire/release technique, but
somehow acquiring ImBuf before invalidating it in compositor operation
doesn't resolve the issue, so probably it's not actually locking acquire
and things should be checked deeper.
