View Full Version : zeroing out orients on constrained and bound skeleton
07-28-2010, 02:43 AM
bit of a newbie issue. Ive always tip-toed around the joint orient values without understanding them completely.
weve been working on some characters for a real-time application at work recently. Ive set up a few, and all have a "straight" FK skeleton constrained to a control skeleton with IK and whatnot. FK "game rig" skeletons movement gets baked out for use in the engine.
today we were suddenly told that the game rig joints cant contain any orient information (thanks numb-nut clients...), which I had used on most joints already. as you do. now, just zeroing out the orient values for a few joints doesnt really seem to affect the way they move with the constraining joint. but its still a little bit scary - is it safe? will it just magically be ok? or does anyone know of problems that will arise from doing this?
by the way the game rig is already weighted as well so it would be nice not to redo it all (although I realise I might have to...).
does anyone have any info on what really happens matrix-wise with the joints final position and orientation being calculated. are the orient and rotation values just added together in the matrix so the end result, that the skin considers, is the same? it just seems so odd that changing the orient values doesnt even mess up the bind pose (maybe it does?) and skin?
usually with an unconstrained joint I would just add the orient values to the rotations of course? does the constraints do this automatically when I change the values?
Im so used to absolutely everything breaking as soon as I changed the minutest thing without knowing exactly whats going to happen, this just doesnt feel right. =D
07-28-2010, 03:52 PM
zeroing out the orientation axis can lead to some gimble lock problems, ie in game your characters will not move right. This is becuase the game engine is not picking up the internal orientation axis changes that are being done.
If you build the control rig outside of the skeleton which it should be already. And you are using PARENT Constraint (Rotate Only!) With some Parent Constraint (Translate and Rotate) on a few pieces. You can then save the file. Open it back up, bake the animation down into what would be all FK. Then Delete the Rig and export. So long as you don't save over your file you can reopen the rigged version to make changes.
I use this process for my Unity Rigs, and some other game engine work that I do. This way I can use all my IK and other bells and whistles for Rigging without having too much worry.
07-29-2010, 01:22 AM
hey thanks for the reply!
Im not entirely sure how you mean I should fix it. yes the FK skeleton is a separate hierarchy from the rigged one. do you mean if I only use parent constraints its ok? or was that just describing the general workflow?
are you saying that nah its going to cause problems so I should redo both skeletons, even the rigged one, with zero orients from the start? best case scenario would of course be that I could stick with my orients for the animation and just have them zeroed out for the game rig. youre saying no? redoing everything would be a major hassle, so if its possible Id like to try to recreate the problems right away to make sure that they happen. not that I dont believe you of course. =) Im just lazy.
actually its a bit strange. experimenting with it I find that joints down a chain behave like I wouldve thought: their constrained rotation is the combined rot+orient of the constraining joint. but the first joint in a chain has all sorts of rotation values, even though they started out exactly the same and have the same rot order. but even so I cant get the constrained joint to gimbal out though... Ive heard that constraints are all quaternion under the hood - how does that influence everything?
07-29-2010, 02:35 AM
actually the way of just changing the values under the constraints has another problem as well. when the constraints are deleted the rotation values go back to zero instead of retaining the values from when they were constrained. (why--?) this causes the whole skeleton to implode sort of...not good. maybe I better go back and redo everything and just find a way to save the weights based on joint name?
07-29-2010, 09:01 AM
so Im redoing the rig now...but other questions pop up. like how to keep good rotations without using orients or helper objects in the chain? for some place its really a question whether to have x down the joint and have mad rotation values or just use a handier axis. for instance going from the hip which is pointing one way, to one of the legs thats pointing downward obviously. having both pointing down x would in this case mean starting out with a -90 -90 rotation for the leg bone. Im not so sure thats healthy?
that could all be helped by using for instance -y as the leg axis and in fact different axes for all the joints in the body (typically the start of limbs at least) to keep the default rotations at a minimum. but that doesnt feel right either - not widely done for realtime apps and games? (well I guess usually they let you use orients?) any game makers out there whove seen it used?
guess I should just contact out clients (whos sitting on the engine and wont tell us stuff) and ask them?
07-29-2010, 09:01 AM
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.