whoops, this was automagically added to the codequest workboard... just wanted to tag it properly with "code quest"...

Hmm do you maybe want to join the "#blenderfracture" channel in blenders IRC ? there the FM team sometimes is discussing. :)

Regarding Threading, believe it or not, over the last 2 days i spent hours to thread this existing implementation.
I was using OpenMP to quickly test, but the algo implementation contains so much "shared" stuff (like MemArena, linked lists of cubes etc) which simply crash if several threads work on it.
Atleast I found no viable way to get it working.
As second approach it tried to re-implement the algo based on marching cubes, I got it only half running, but that what i got was even slower with OpenMP than the original implementation present in blender without any threading.
So i stashed it locally and gave up on threading this, for now :(
I found no example how to "properly" thread such an algorithm with the task system in blender,
because it contains much shared stuff as I mentioned earlier (and probably MemArena, which holds allocated stuff in a linked list, which depends on "next" pointers, which threading will mess up since execution order isnt guaranteed.)

Hey, thanks for that info :) I will take a look at it now and try to understand how its implemented. Maybe i can adapt this for the remesher.
And the other problem, you would like to "bind" some verts to particles by proximity or something ? like surfacedeform modifier or so ?

The remesh transform issue should be fixed now, but the deform mblur issue is iirc a cycles limitation. It cannot deal with changing topology / vertexcounts in a mesh across frames. If you use duplis / metaballs, this is object based mblur and does not have this issue i think.