Thanks Matt,
You've summed it up quite well. I can't strip any more deformers than I
already have.
Alan, I'm not using GATOR and thus in the MergeMesh PPG it doesn't show
the method it is using. I'm hoping it is using closest vertex.
Eric T.
On Tuesday, October 28, 2014 1:41:01 PM, Alan Fregtman wrote:
This may be an obvious thing, Eric, but did you try the "closest
vertex" method? Since you're transferring from the same exact shape,
it should be a lot faster than the default "closest surface".
On Mon Oct 27 2014 at 9:51:57 PM Matt Lind <speye...@hotmail.com
<mailto:speye...@hotmail.com>> wrote:
You’ll get the best results if you merge the meshes first, cull
redundant deformers from the envelope, then do the weight
transfer. The part that’s taking so long is you’re creating an M
x N x O array of deformers and vertices (436 objects * 161,000
vertices * NbDeformers). That’s a huge envelope weights data
table. Moving that around in memory while retaining connections
to all the dependencies feeding into the table is what’s dragging
it down. Every new object added to the result triggers a refresh
cycle causing all the data to be rebuilt from scratch, but with
every new object the data gets larger at every step of the
process. If working with a handful of objects its not a problem,
but your case is quite extreme.
GATOR doesn’t cull deformers from an envelope if it’s not used,
nor (sometimes) does it cull a deformer if more than one object
use it. For example, if two different objects use the same
deformer, attribute transfer will sometimes add that deformer to
the resulting envelope twice – once for each input object.
I wrote our own set of GATOR tools to handle this problem. It
takes some time to work out the logistics and deal with the edge
cases, but it’s well worth it in the end.
Matt
