PDA

View Full Version : Problems with seperate rigs and referencing. Help needed!


Nenox
04-19-2006, 12:42 PM
Hi.

I have set up a creature pipeline and rig tools that use seperate rigs for control, bind etc. (Think Poul Thuriot). These rigs are referenced seperately into the scenes where they are to be used. Then in those scenes, they are hooked up to each other (BindRig to ControlRig) strictely by connections. What is connected is translate, rotate, scale, rotate order and rotate axis. No compound attributes are connected, allways x y z seperately.

This gives me a lot of trouble. More so than referencing in my experience normaly will induce. A lot of attributes simpely do not get updated and things also tend to be just a tad more funky than usual. So right now animators and render people hate me/my tools. The "bad behaviour" is not stable, but something might be a problem in one scene, but not in the next. Using exately the same assets and hookup. A lot of times reloading the references will do the trick.

I wonder if connecting the rigs together in a seperate scene and then referencing that in would be better? That would keep maya form having to establish all those connections after referencing the rigs into the scene. But would also complicate and limit updating/handeling of my rig assets.

In general I've noticed that Maya does not allways handle simple connections between attributes, very solidly. Like for instance going between compound .r and seperate axis .rx .ry .rz., can make things just stop updating. So as a rule i always avoid compound. I think that using constraints might in praxis be a more robuste solution, when connecting the seperate rigs? I went with connections to avoid the slowdown that constraints induce.

Anyways, does anybody have some sane comment on my ramblings?

Thanks a lot!
http://www.creaturetd.com/forums/images/smiles/icon_smile.gif Sune

isoparmB
04-19-2006, 02:31 PM
Just a speculation, could it be that in referencing to different files, especially with multiple similar characters in the same file, there occurs a situation where the namespaces some how make it hard for direct connections between attributes to remain consistent? I imagine constraints would be more effective in this situation, where you would import a skin rig with the geometry and a controller rig and constrain the skin rig bones to the controller bones. I was thinking along those same lines for a controller pipeline myself, since we were going to be using referencing for our studio.

Basically the workflow would be reference the skin rig, reference the controller rig, constrain. Although I wonder why this would be any different from direct connections. If you had to constrain the rig into a seperate file and reference that, it would seem to kind of defeat the purpose of referencing in terms of convenience.

What I've encountered, which you may have experienced, is that when I import a referenced animated file into another referenced and animated file, the animation on both gets disconnected. Tha animation curves aren't actually lost, they're still there in the scene, but disconnected from their respective controllers. In situations like that I have to manually reconnect the keyframe nodes to the controllers (which isn't pleasant at all.). Maya seems to have a hard time associating keyframe nodes to multiple references once an alien reference enters a scene file, and you only see this after resaving. I've learned it's best to reference all of your necessary elements straight-away at the beginning of creating a file and I NEVER import any scene files with references. Before I reference additional files, I save, reference, and save an alternate file with the additional reference, then reopen this new file to see if I haven't killed my animation. If I have, I go to my backup.

This same phenomenon might apply to direct connections between nodes, or even keyframes.

Morganism
04-19-2006, 05:59 PM
I wonder if connecting the rigs together in a seperate scene and then referencing that in would be better? That would keep maya form having to establish all those connections after referencing the rigs into the scene. But would also complicate and limit updating/handeling of my rig assets.


I think that's the ticket.

Connecting the rig in the animation scene is useful because it allows you to update the bound rig without changing the animation rig, (and therefore animation), and vice versa.

However, if you're using referencing, animation transfer isn't as much of an issue. So if you have one file that is just the low rez, and one file that is low rez connected to high rez, then as long as animation only stays on the low rez rig you should be able to reference between the two without much trouble.

Basically if there's not going to be any animation on the bound rig then there's no reason to reference it as a separate file, because there's nothing to transfer from one version to the next.

Does that make sense? It seems like referencing AND reconnecting would be redundant. You should only need to do one or the other I think.

isoparmB
04-20-2006, 01:02 PM
However, if you're using referencing, animation transfer isn't as much of an issue. So if you have one file that is just the low rez, and one file that is low rez connected to high rez, then as long as animation only stays on the low rez rig you should be able to reference between the two without much trouble.

Basically if there's not going to be any animation on the bound rig then there's no reason to reference it as a separate file, because there's nothing to transfer from one version to the next.


There seems to me there might be some special cases though. For most it is true that referencing is meant to do away with transfer animation, and it does it pretty well.

But if for example a rig uses a runtime setup, say, the attrGoalEditor, which is used to give a form of transform based jiggle using goal principles. If neither the geoemtry or the skin joints of a rig have their animation baked in, you'll run the risk of inconsistensies in render output because of the nature of that setup, but I imagine it would be harder to bake animation on a controller rig because of all the connections it would have. Using a skin and controller reference would seem to me a sensibe, in that after animating you'd want to bake in the skin rig's animation to make sure it stays put, and then unreference the controller rig as it was no longer needed.

Nenox
04-20-2006, 03:27 PM
Thank you for your answers!

Just to clarify, my problems are not really that I loose connections between the rigs or to animation curves, more that the control rig does not allways want to update. In some cases also the bindrig not updating. And other sicknes related to the rigs.. More that usual i think! :-)

Just a speculation, could it be that in referencing to different files, especially with multiple similar characters in the same file, there occurs a situation where the namespaces some how make it hard for direct connections between attributes to remain consistent?

Yeah, that's exately my own thoughts. I did try to hookup the "bindRig" to the "controlRig" in a seperate scene, making a new asset called "combinedRig". In one animation scene that had "gode bad", I tried getting rid of the "bindRig" and then replaced the "controlRig" reference with the new "combinedRig". This did not get rid of the problems in the scene. However they would maybee not have been induced if I had used with the "combinedRig" asset from the start.. ?

For some shots we needed to have mutiple identical characters (rigs) in one scene. That made things totaly crazy. For those cases, what really helped, was to made symbolic links on disk, that all was a reference to the same file, but had diferent names.


Morganism:

The only trouble with connecting the bindRig to the controlRig in a seperete scene, is that it would give me an extra step in updating / creating rig assets, if my bindRig or controlRig were updated.

IsoparmB:

Baking the bindRig and loosing the controlRig makes sense. Because of all my troubles with seperate rigs, I allready made a small script that will bake any bindRig (joints/transforms) and do away with the controlRig.

Thanks again!

Morganism
04-20-2006, 04:46 PM
The only trouble with connecting the bindRig to the controlRig in a seperete scene, is that it would give me an extra step in updating / creating rig assets, if my bindRig or controlRig were updated.



Understandable.

Just a thought, though:
One way that I've worked in the past is to have a master rig file with everything in it: control rig, bind rig, etc, with all the connections made. Then from that file you publish just what you need. ie, if you want to publish an updated bound, all you need to do is delete the control rig, and vice versa. That way if you needed a file with the connections already made, well, you already have it.

lemonyfresh
05-08-2006, 01:24 PM
I have a similar sitiuation to Nenox. I have a character that I have skinned in one file, referenced into a rig file where I created all of the controllers, IKs, connections and whatnot. Then I plan to reference this rig file into the final animation scene. However, I loose the connections I set up in the rig file when I reference into the animation file.

Any thoughts?
S

niralrajani
05-09-2006, 04:48 AM
Well When i work with refrencing in maya i always take care of prefix or namespace while getting my char in scene, this equally imp while exporting animation clip .
more over about making connection, I usually make connection for only rotaion i.e rx ry and rz for all joint and only main COG will have tx ty and tz connection with rx ry rz, since in 3d world joint always rotates and do not trans except COG.

lemonyfresh
05-09-2006, 03:51 PM
You were absolutely right, I had accidentally turned off the namespace options when referencing and not looked at that as a possible problem when I had the loss in connections. Stupid, sorry guys, false alarm.

CGTalk Moderation
05-09-2006, 03:51 PM
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.