sprockets The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen Character animation exercise by Steve Shelton an Animated Puppet Parody by Mark R. Largent Sprite Explosion Effect with PRJ included from johnL3D New Radiosity render of 2004 animation with PRJ. Will Sutton's TAR knocks some heads!
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Rigged in 60 Seconds?


Recommended Posts

  • Hash Fellow

Is it magic? Is it a trick?


 
I will note that Transfer AW is not a one-button solution and sometimes makes mistaken assignments that are rather odd.
 
But if you had to get a body moving quickly... it's there.

Link to comment
Share on other sites

  • Hash Fellow

Impressive Robert.

You make me wonder how trying to transfer weights form something like the default Knight model to a mesh from one of those generators might work.

 

You will get a result.

 

Part of success with Transfer_AW is to use "exclusion groups"

 

When there are body parts that lie near each other but should not share any CP weighting, like a right and left leg, then you make an exclusion group for each body part in each model.

 

For the right leg you would make a "lo-res rightleg" Group in the lo-res mesh, and an analogous "hi-res rightleg" Group in the hi-res mesh.

 

Likewise for other body parts.

 

For this demo I just did the absolute bare minimum of Exclusion Grouping to get a functional result.

 

ExclusionGroups.png

 

Here is Steffan's page for Transfer_AW

 

http://www.sgross.com/plugins/plugin24/index.html

 

 

Here is the demo PRJ in the video, before Transfer_AW has been run

 

lo-hi015a demo.prj

Link to comment
Share on other sites

  • Admin

Never one to be satisified with a 60 second auto-weighting rig of a character... ;)

 

I find myself wondering about being able to auto create groups based on bones and weighting.

It seems to me that the process of Grouping could be trimmed considerably because the weights already dictate the groupings.

 

Just mindless speculation.

Press on. Press on!

 

Very interesting stuff going on here.

Link to comment
Share on other sites

  • Hash Fellow

 

It seems to me that the process of Grouping could be trimmed considerably because the weights already dictate the groupings.

 

I thought so too, but it seems that mere proximity in space is enough for influence to happen.

 

For example, the right big toe and left big toe are very close to each other in space even though they are far away from each other in the spline mesh.

 

You don't want either to be partially attached to the other.

Link to comment
Share on other sites

  • Admin

I thought so too, but it seems that mere proximity in space is enough for influence to happen.

For example, the right big toe and left big toe are very close to each other in space even though they are far away from each other in the spline mesh.

 

You don't want either to be partially attached to the other.

 

That's perhaps even more reason why it might be useful to have a means by which Groups were created via Bones and the Control Points assigned to each.

This seems even more appropriate given that the weighting current already gets colored by each bone.

So what might drive the creation of a Group would be (primarily) 2 fold; first, there would be a Group created for each bone, and secondly an additional Group would be createdfor any overlap of weighting. The Group would automatically take the name of the bone as a default in order to keep the one to one match up between Bone and Group. The areas of partial weighting then would receive a treatment similar to Fan bones... so there could at least in theory be multiple groups generated as subgroups to identify areas of overlap. Those areas of overlap then would be likely areas for additional attention anyway via adjusting of weights, smartskinning or direct mesh animation.

I would not expect the reverse to be as accurate. That is to say Groups driving the creation of Bones although the process could work in reverse.where Groups could automagically create (at attach to) bones.

I suppose the main flaw in this approach might be that there may not be much need for a one to one matching of groups to bones/bone weighting but there are a number of reasons why I think that might be optimal specifically when considering that Groups are the place where surfaces are defined and Groups can easily contain all, some or none of the CPs of other Groups.

The fascinating part of this to me is that weighting very obvious already does define groups as can be seen by the color of each bone and the bone's influence.

I really need to leave this extraneous exploration alone though as it's way out of my comfort zone. ;)

But in my naive thinking I just see the colors and say... hey... that's the Groups right there... why do I need to manually create them?

BoneWeight_Color Groupings.png

Link to comment
Share on other sites

  • Hash Fellow

If you can make that work, I'm all for it!

 

But note how in the picture you've posted, for example, the two thighs are the same color but you would definitely not want them to be communicating weights.

 

Also note that those bone colors fade from one to the next. Where would one group end and the next start?

 

 

 

Here's a result with no leg Groups... the thighs get stuck together.

 

StickyThighs.JPG


 

 

Link to comment
Share on other sites

  • Admin

Yes, they are the same color but the color doesn't define the contents of the group... it's just a useful label.

But you are correct... we wouldn't want to use the color to create the groups... at least not optimally.... and unless specific colors meant specific things relative to relationships that were desired to be formed.

Color can be useful in that regard but not when used as arbitrarily as those colors currently are.

Link to comment
Share on other sites

  • Hash Fellow

As I see it, making the matching groups is so easy that it's probably easier than whatever interventions you'd have to do to make some other automatic discriminatory power to work.

Link to comment
Share on other sites

Wow! 'Pearls' of wisdom here. Wasn't this a 3rd party plug-in at one point? WeightMover or something? I seem to remember buying and trying it...

 

What is the underlying rig you use here, quite flexible and the beauty being that the plug-in divides the lo-res into the high res SO smoothly- quite valuable! I need to watch again!

  • ____ 1
Link to comment
Share on other sites

  • Hash Fellow

Wow! 'Pearls' of wisdom here. Wasn't this a 3rd party plug-in at one point? WeightMover or something? I seem to remember buying and trying it...

 

 

Yes. The "AW" stands for "Anzovin Weightmover" I believe. However, Steffen wrote this from scratch after they stopped upgrading it for new versions of A:M.

 

 

 

What is the underlying rig you use here, quite flexible and the beauty being that the plug-in divides the lo-res into the high res SO smoothly- quite valuable! I need to watch again!

 

 

TSM2

 

I haven't shown the best practices workflow here.

 

Ideally you'd run Transfer_AW on a lo-res model that had just the TSM2 geometry bones in it, before Rigger was run on it.

 

THEN.. you'd run TSM Rigger on the newly weighted hi-res model.

Link to comment
Share on other sites

SO- thinking more about this...

There are many-many high res models out there that could be employed here in A:M with this plug-in... if there was an easy-peasy way of getting the CP's and rig transferred over.

 

Does the lo-res model need to be generated from the hi-res? Could a minimal CP rigged model be used as a 'Universal Lo-Res'? I suppose a fair degree of scaling and sizing would be needed to fit the lo-res to the hi-res, and even tho rigs like TSM2 have great 'limb-stretch' capabilities- you can not activate them in a model window...

 

Could open new doors for A:M if 'mixamo' type capabilities were acheivable!

 

BTW- I love the little 'action to put him thru the paces' you made in the example!

  • ____ 1
Link to comment
Share on other sites

  • Hash Fellow

Does the lo-res model need to be generated from the hi-res?

It doesn't have to be. I think they do need to occupy the same space as closely as possible.

 

For this demo I locked the hi-res mesh and then modeled a very lo-res approximation on top of that.

 

Note that the head and hands are just place holders for the volume. If you wanted fingers to work... you'd have to have working fingers in the lo-res model.

 

The more detailed and functional your lo-res version is, the better your hi-res result will be.

 

 

Could a minimal CP rigged model be used as a 'Universal Lo-Res'?

 

Yes, if you stayed within reasonable human proportions.

 

 

I suppose a fair degree of scaling and sizing would be needed to fit the lo-res to the hi-res, and even tho rigs like TSM2 have great 'limb-stretch' capabilities- you can not activate them in a model window...

 

If you had a lo-res-model rigged with just the geometry bones, and the geometry bones all had basic parent-child-tree relationships (as TSM2 does, but as Squetch does not AFAIK) you could use CTRL scaling and Rotating in the model window to move the bones into position and move the mesh along with them.

 

 

Could open new doors for A:M if 'mixamo' type capabilities were acheivable!

 

BTW- I love the little 'action to put him thru the paces' you made in the example!

 

 

Thanks!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...