Transfer Uv to rigged character

[Will Sharkey]

Hi, Are there any tools available to transfer Uv form a mesh to a skinned mesh?

I understand there is this method:
https://gabnation.wordpress.com/2010/02/09/how-to-transfer-uvs-after-rigging/

But i was just curious if there are other tools or scripts available that Im not aware of. Currently that Uv transfer method mentioned isnt working and Im transferring weights to new meshes instead. Not ideal.

Any pointers much appreciated :)

[Will Sharkey]

Hmm, just noticed this maybe a duplicated question to a previous post.

I guess you guys just resort to transferring skin weights if the Uv transfer method fails?

[Yaleh paxton-harding]

Do you have an idea why it's not trasfering to the orig node? If there are more than one orig nodes then try the other(s). I've written tools I can dig around for them but sometimes it's better to do it manually. And yes as you mentioned sometimes just better to reblend and copy weights to the new UV mesh if all else fails. Good luck.

--
You received this message because you are subscribed to the Google Groups "maya_he3d" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maya_he3d+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Sharkey]

no idea why the Uv arent coming across to the orig node. The two meshes blend fine when added as a blendshape, I havent figured it out yet.

Thanks for the info, think Ill just transfer the weights manually. 

[Stephen]

I tend to stay away from doing any uv transfers to rigged geo. bind or blend or otherwise 

  If need , I'll most commonly just transfer weights via copy skin weights from a skinned character to the one with new uvs.    

   I find proper joint labeling is major factor in getting copy and mirror skin weights to work.   And if your topology isn't changing the export import skin weights generally works.  None of it is bullet proof however. Best practice is to get the uvs created before hand.  Or what I use in referencing is to have separate geo for the bind/rig and blend or input mesh that to the render mesh.  That way you can do whatever you want to the uvs and it's far easier to make that blend connection in the end.  This also allows to have separate uvs for bind vs texture to allow for udim and other uv tiling methods. 

 Hth 

-=s 

--

[Will Sharkey]

We exported a bunch of characters as fbx from Max to Maya, the Uv's on some characters were broken and twisted 90 degrees on export, its wasnt something that we could spot straight away, really random stuff. 

Great idea to blend the animated mesh back to another piece of geo for export, thats what im gonna do if all else fails.

[Gerard van Ommen Kloeke]

Our studio has approached it from a different angle that you may want to consider if you have the development resources. 

We wrote a version of our own alembic plugin that allows a proper updating of animation onto existing alembic in a lighting scene. Replacing alembic through Autodesk's (Maya specifically) implementation of Alembic is not very good and instead of reconnecting animation to the geometry in scene via the existing alembic node, it will create a new alembic node, which clobbers a lot of shading work in-scene (shape nodes etc).

Pipeline wise, it's ridiculous to have to pass uv updates through an animation rig in order to allow lighting to have the changes, where a proper process would allow you to have independent uv's that can be swapped and managed directly by the artists that need the changes (Usually not by rigging - at least not constant updates). I'm a little sketchy on the final implementation of our version of alembic - I didnt write it -  but the animation data etc will get passed into the custom alembic node that will update animation without messing up shader assignments, and UV's etc. (And even allow the user to manually update the path on the alembic node !! (Current implementation allows you to change the path but doesnt actually update, ( maya2015))

(Even better was the use of Cortex at another studio that I worked at where the animation and the mesh data were separate files so lighters were not dependent on anything apart from vert order and animation didnt need to worry about any changes other than vert orders.. saves a lot of disk space also). Both systems are an improvement on Maya default offerings. Hopefully Autodesk's approach will improve in future versions, as Alembic can allow for it. 

Gerard van Ommen Kloeke

Fin Design and Effects

Sydney, Australia