fixing animated uv's WITHOUT deleting history

#1

Hey, just thought about sharing this, since I was swimming in forums and couldn’t find an answer…
I was rigging a character, the face in particular which obviously took a while, and then I noticed that when animating (the geometry) the UV’s got all screwed up, probably because when I was UVing I used the automatic mapping (can’t think of another reason…)
so I tried deleting history which of cores deleted the rig, then tried deleting only the non-deformer history - which did fix the UV problem, but all the cluster work was destroyed as well - and there was really some complex stuff there.

so the work around was actually quite simple - all you need to do is duplicate the base mesh, delete history and freeze trans. for the DUPLICATED mesh;
then simply warp-deform to the original (screwed animated uv’s) one, checking in the options for exclusive bind and auto-weight threshold.
then just hide the original - problem fixed.

#2

Might be cleaner to duplicate the mesh, skin it and copy the kin weights from original. Same result but u avoidhaving a deformer and 2 meshes in the scene

#3

well he’d also have to reconnect the clusters etc… not as easy/obvious…

I think if you look at the DAG in the hypergraph connections you’ll see an a copy of the skinned shape labeled Orig. I believe if you replace it with your edited shape with the new UV maps you won’t need to copy weights or connections to clusters etc. What you’ll want to do is to select the connections from it and break them. Then copy the results of the commands printed in the script editor and then change disconnectAttr to connectAttr and use the name of your new shape instead of the old one. You’ll also want to parent the new shape under the transform of the old one and then you can delete the old shape.

#4

I admit I didn’t go down that road, but by itself - it is a nice approach to it - and thank you for the advice, but the thing is just too complex - it didn’t work, and of course you were right before about copying the skin weights - it’s impossible: bones, clusters, curves and even geometry effect the mesh, and each have there own weights assigned, on to of blendshapes it just didn’t work sadly - but again thank you for the advice.

#5

I think another possible solution is to use the transfer attributes function to copy the UV’s to that original shape and then delete history on the shape. I’m certain one of these two things has worked for me in the past

#6

BTW I just tested connecting a duplicated mesh with the new UV’s and breaking connections from the original shape node and then connecting to the new shape mode with the updated UV’s and it worked as I expected.

#7

I appreciate it,
for some reason - anything that has to do with any kind of history delettion - skrews everything or part of everything.
transfering the UV’s is not nescesary - in the bind-pose the UV layout is perfect on the Original mesh - it just gets skrewed when animating it, deleting the history is what freezes those animatable UV’s - but the mesh is not just influenced by a simple joint set, it’s a whole compound of stuff, joints, clusters, blendShps, influential curves and influential geometry affecting the weights,and having themselfs influ-vertecies: all those mean things that give you perfect lip twists and moves, if it was a simple weight copying - I wouldn’t ask twice, deleting history simply destroys some/all (depending on what history is deleted) that work.
gmask - thank you again for your input, I’ll be sure to try it under different circumstance, or better yet - pay more attention before any kind of bind…

in any case, since it was only the head - and the shapes are perfectly aligned - the wrap deformer calculates very quickly (RT) and basically - it’s just like having one more blendshape. thank again, I’ll hopefully be smarter next time…

#8

Well that’s fortunate… I’m still certain the method I’m suggesting would work no matter how many deformers were placed down stream from the original shape… no history deletion required.

#9

And it’s not just that your uv-projection node is downstreams from the deformers (ie projecting on the already deformed mesh)?

#10

part of the problem is that the part of the chain consists of tweekUV’s inbetween all those deformer nodes, if it wasn’t, I could just delete all nodes downstream from the skin node and fwd, without any need to duplicate.

the entire thing was a disaster as far as pipeline goes

#11

you could try using the node editor or hypergraph and change the order in the chain so the uvs are in the same relative order but before all deformations. (have you tried deleting non deformer history?) otherwise you might also find something interesting in the tutorial on how to keep uvs on animated pfx trees by djx at djx.com.au

#12

but that would probably be slower than your wrap deformer. But if you are lucky moving the uv nodes could actually work.

#13

wait, I;ve bin outside of maya for some time now but… you can’t simply fix or make another UV map or something without deleting whole history and breaking up everything?
could you share couple images of problem and solution as well please?

#14

It is possible but whenever you edit the UV maps of an object that already has deformers those edits will be added to the construction history after the deformers instead of before them. There is a delete non deformer construction history function but it doesn’t always work with complex setups.

It is however possible to put the changed UV map before the deformers as I’ve explained above.

#15

I think this tip might help your issue. Pretty simple and cleaver.
http://www.youtube.com/watch?feature=player_embedded&v=uzN_5ugDxa8

#16

yup that’s what I suggested back in post #5 :thumbsup:

#17

I cannont agree more with Gmask, we use this BULLETPROOF technique extensively, as we very often start facial shapes/rigging before texturing starts.
If you have time, I’d strongly suggest you make a script that allows to make it instant, and nobrainer, and updating uvs on a deformed mesh will become a routine task.
Idea is simple, let’s say you want to transfer uvs from meshSRC(good uvs) to meshDST(bad uvs, eventually with any deformer down the stream)
You need to inspect if “meshDSTshape.inMesh” attribute receives an incoming connection, and if yes, parse all it’s siblings intermediate shapes, and polyTransfer uvs only on those whose inMesh is free. For the cost of time polyTransfer execution, you can proceed without searching if any of those intermediate objects are really usefull or not. But of course you could make the check for the really usefull ones.

Bonus is that with this approach, you can even update base shape of your model (with a vertex transfer), if any retake happened after you started modeling, provided the topology didn’t change.
Extra bonus is that you can make your script smart enough to figure the kind of shape it’s
processing, because the same principles apply to nurbsSurface/Curves…

You can even reuse some code to make a script that cleans useless intermediate shapes under a transform, as they can cause you scene size to grow fast…

Nicolas

#18

You could make a copy of your mesh, fix the uvs there and set the original mesh as blendshape target, then template the original mesh.

#19

doing this - is no different then using the deformer, and yup - it’ll work.
the other posts in this thread have tried to find a way to not have that extra model and extra deformer, although there were nice suggestions and smart ones - in my rig, still the only one that works is still the deformer (unfortunately), because there is a wide chain of complicated stuff, having all blend-shapes, deformers, clusters and even curves&geomatry effecting the rig - no other solution has worked.
P.S. I have tried ALL the suggestions, and I appreciate a lot the time you all put into this…

#20

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.