Set Driven keys - changing parenting

[BPorter]

Yes. On the locator, you should have a ParentContraint node in the outliner. In there you have a "wrist W0" with a value of 1. You can key that. However, when you put it to 0, it'll jump back to its starting point. You will need to key the translates and rotates for the locator. You'll then have a new Blend Parent attribute to key on and off, 1 being wrist, 0 being world. Hope I answered your question. If you have any questions, let me know.

[isoparmB]

Constraints, though I'm not quite sure if maya constraints are exportable to game engines, don't have much familiarity in the field. Though for switching what one object follows within maya, constraints are the way to go.

[BPorter]

Yep, that was my bad. I totally missed the part about it being exported to a game engine. Now I feel like an idiot. Hehe

[Antilight77]

Thank you both for your posts.

The way I am viewing this is that I will have to bake out the animations for an eventual export in to Unity or Tork. So if I can use the parenting method and still get the key frames I need baked out then it will work for now.

This constant method. How best is it to set this up? Is it just a point and orient constant?

One other point in all of this - at Current I am using anzovin.com - 'the set up Machine' to rig my charters. Makes life much easer - However its rig cant export nicely to game engines so I had to make a slave rig that 'The Set Up Machine''s rig controls. This slave rig then has the smooth bind of skin to it and what I export to Unity. So all the joints in this rig are Point and Oriented constraned to each joint on the master rig. - Would having this set up make the constant method not work?

Thanks for your help thus far its fantastic~

[NolanSW]

You have to make sure your slave skeleton is a complete hierarchy. You can't have a broken hierarchy when exporting the skeleton. Now I'm not familiar with Unity so I don't know what it's expecting when you export. If the exporter is grabbing all the joints and skinned meshes in the scene, that could break the process since the master rig is not a complete hierarchy.

As for as a prop being parented to a character and exporting you only have two choices. One is have the prop part of the characters hierarchy. Meaning the prop needs to be skinned to some joint. Most exporters treat unskinned geo as static. In order for it to be animated in game it would need to be skinned. Parenting an unskinned object would probably not get exported.

[Antilight77]

NolanSW - Interesting. I will try a few experiments and see if the animation will be exported with the attached object. As of now my attached objects (a staff) has a joint chain in it (not attached to the slave Skeleton) that joint chains root it parented to a loacator - that locator is then point and orinated constrained to a joint in the slave skeletons wrist. I did it this way so that the animation of the joint chain can be exported (or so i am guessing). Were still experimenting with the use of Torque or Unity so this initial run of charters is just to get the bugs out and find the best methods for a pipe line.

[NolanSW]

Well I just took a quick peek at the Unity manuals and it's saying that you export the scene using fbx or you can import the maya scene into Unity from what I gathered. If this is so, then I think your master rig is going to get exported as well. To be clean, I'd bake out the slave skeleton, kill the master rig and export out the slave skeleton and the skinned mesh into a new scene. Something that could be eaisly scripted. Then export the new scene in the fbx format for the engine. Just a hunch from what I read.

If the staff is a separate asset then you'd have to export it as such and not with the character. I'd bake out the staff as a separate fbx and import that into the engine and the two animations should line up. However, if the engine compresses the animation data then the staff could possibly jitter. Depends on how much compression there is.
-Sean

[CGTalk Moderation]

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.