Blender Exporter and IK animation workflow

[gryff]

Normally in my animation workflow I use mocap animations, but recently I have been experimenting with IK animation (see images A & B below)

Image A shows the model with all the bones (mesh deform and IK bones - 49 in total) and an animation in the Action Editor with just the bones (mainly the IK bones) that are translated/rotated to create a simple walk animation.

This I exported with no special settings for the exporter - all the IK bones included. Result here

Now the exporter has a special setting I can use  - the "Ignore IK Bones" setting. If I use that I get this - not for the squeamish

Image B shows a different procedure that I used. I bake the animation, delete key frames in the Action Editor for any bones with IK in the name, delete the IK bones from the rig (now 37 bones in the fig), then export. Result here

I am curious about what the workflow should to use the "Ignore IK Bones" setting.

cheers, gryff

[JCPalmer]

I will look at this soon.  Need to be sure root bone scaling in copyAnimationRange before 2.4 goes out.  I guessed your B example was index2.html, but that link to it is not working.

Off the top, I would say the goal is for A with the ignore IK setting to work.  FYI, baking should be avoided.  The exporter should get the values in the middle on the fly.  Having all that baked limits your future possible options.

Might need the .babylon files.  I also need to review some of the ik tutorials I saw back in January.

[gryff]

@JCPalmer :

Edited the link Jeff - works for me now

Quote

I would say the goal is for A with the ignore IK setting to work

That is what I assumed, but er ... spaghetti

Quote

I will look at this soon.  Need to be sure root bone scaling in copyAnimationRange before 2.4 goes out.

No rush Jeff. All the animation stuff you are doing is important and good

Just FYI, the baked file is actually 40kb smaller.

cheers, gryff

 

[gryff]

@JCPalmer :

Quote

Having all that baked limits your future possible options

Jeff, now that intrigues me   You have something planned for the future?

cheers, gryff

[JCPalmer]

Well, just letting you know that I have not forgotten about this.  I just spent 2 days making my own IK rig based on the MH 1.1 Game Rig, with finger bones deleted.  Not gotten to make any poses yet.  I notice that I have a fewer # of IK bones than you.  Part of it might be the rig's root bone is already on the ground.

The tutorials I viewed all use B-Bone display, not octahedral.  The yellow bones have an IK constraint on them.  The foot & hand IK bones have a slightly larger scale, so the feet and hand bones are inside.  Feet & hands have copy rotation constraints, so they are greenish.  Seems to work.  Am I missing something?

As far as future plans, I was referring to the pose interpolator of the Queued Interpolation extension.  If you bake all your poses, then you have to delete all the garbage frames.  I am not even going to try to debug using IK with BABYLON.animation objects.  Finding the error using poses will be much easier for 2 reasons:

1. All data for a pose is organized together, not each little piece spread out across all the bones.  If I run your same test, and diff compare my pose library exports, I'll have all the data for that pose contiguous in the file.  As an animation, it would be much more difficult to  diff compare.
2. I only need test 2 poses.  You could do an animation with 2 frames, but it does not give much of a run.

Down side is I am developing that at the same time. It is done except for scaling.  Just need to use skeletons of exact same size.  Stay tuned.

[dbawel]

@JCPalmer - I understand why you don't recommend baking skeleton animation considering your explaination of your personal workflow. However, I recommend baking all skeletal animation prior to exporting to any other format, application, engine, etc. And as I often post on this forum, if you're not freezing all transforms of your skeleton prior to animating (mocap, keyframe, proceedurally, etc.), then the person is setting themselves up for major problems - which cannot be solved post animation. I recommend this as IK interpolation (the method, math, and constraints driving IK chains, as well as the same for interpolation between keyframes) is considerably different in every application, extension, etc., and there are no assurances that compatability is and/or will be maintained. The safest, and in my opinion the best method is to bake your skeleton at the playback framerate in your target engine, (and delete all "IK Bones" - control bones specific to Blender) prior to export. Ths is not to be confused with in general terms what are called IK bones, as these are most skeleton chains from most any animation application, and Blender made a confusing error in naming their control bones "IK Bones". Of course, if you plan on using an extension or functions to handle keyframe interpolation post export, then this is certainly a consideration. But personally, I would avoid this due to the reasons above, and for issues with quality and consistancy of skeleton animation by post interpolation.

@gryff - From personal experience generating both mocap and hand keyed animation using most every animation application, I believe this is far less of a subjective issue, and can often cause enormous problems in the pipeline somewhere down the process and/or when rendering. It is in my opinion also more efficient, even though as JCP mentions that you may need to handle "garbage" animation frames at some point (depending on the bake settings as well as the post interpolation process,) and there are also additional resources required when interpolating in real time - which can easily slow down a render depending on device, charater performance, character count, etc. - and quality is often impacted when using most any automatic interpolation function. I have probably exhausted every possible method over the years, and always find better quality and often efficiency in baking all skeletal animations - especially animation which has been created using any of the many methods of IK - which is a vast amount of methods with vast differences. Of course, this is not generally the case for non-skeletal objects with single joint centers or other objects using hierarchy based animations. But always note that IK is almost never the same between applications, and often not compatible. So allow interpolation in another engine or application, cannot provide the same results and often create large differences in the animation and the quality of the animation.

So I just want to make certain that anyone new to character and other animation understands the reasons and issues for baking animation or to choose not to bake before any export to a seperate format and/or engine - as this can cause considerable issues in quality, efficiency, and also flexability - depending on the end usage as JCP is certainly considering. However, any discussion concerning "to bake, or not to bake" can sometimes be an objective issue, but I believe it's a far more subjective decision with the most common and best result generally being "to bake."

I hope any newbies to animation understand why I believe this is a highly subjective decision, and why I personally recommend baking before export. I certainly wouldn't want @JCPalmer to take offense at my strong opinion, as he provides us with so much great code, as well as perhaps the most technical advice and unique perspectives we recieve find on this forum.

Cheers,

DB

[gryff]

 

Quote

Well, just letting you know that I have not forgotten about this.  I just spent 2 days making my own IK rig based on the MH 1.1 Game Rig, with finger bones deleted.  Not gotten to make any poses yet.  I notice that I have a fewer # of IK bones than you. 

@JCPalmer: Was not worried Jeff. I have checked the situation with the BE status regularly and see that it still says :

Quote

Scaling root bone animation on copy part 1

I assumed there is/was a "part 2" to come and you were working on that. And as I said above, "all the animation stuff you are doing is important and good".

You should have asked me for a rig instead of spending 2 days - though i suppose you are learning about Blender Soon be no need for me around here

You are right about the rig I am using - it has more IK bones. It is what is often described as an "intermediate foot rig". I comes from a tutorial (Part 3) by Lee Salvemini who has worked for Lucas Arts. The rig he creates allows for easy creation of foot "heel and toe roll"  when making walk,run,jump etc animations. (See image below)

Anyway, I will create a very simple rig set up/animation  with possibly 2, but maybe 4 poses for you.

As for B-Bones it is just for the 3D window display. Mostly I use Octahedral and sometimes Stick - the need to scale B-Bones bugs me. And of course some people just use Shapes. David Ward who has a lot of Blender videos on YouTube likes to use B-Bones.

Quote

As far as future plans, I was referring to the pose interpolator of the Queued Interpolation extension.

Trying to understand this Jeff. This well be an extension to BJS but the BE will export the file appropriately - or will it to be an extension of some kind requiring a different Blender plugin?

Anyway enough for now.

cheers, gryff

[gryff]

Quote

But always note that IK is almost never the same between applications, and often not compatible. So allow interpolation in another engine or application, cannot provide the same results and often create large differences in the animation and the quality of the animation.

@dbawel: I am aware that the IK is likely to be different between applications - and will depend upon the IK solving routines and how they might be applied in a particular piece of software (and Blender has two different ones!!).

As for the baking issue, which is easy to do in Blender,  I don't know enough about the programming below the surface to take a side. But it does seem to me that @JCPalmer is working on something :
 

Quote

 

"Having all that baked limits your future possible options. "

and

"As far as future plans, I was referring to the pose interpolator of the Queued Interpolation extension."

 

And I am interested to see where Jeff is going. Maybe it will work, maybe not - but what he has done over the last two years says to me, "let us see what the future possible option are".

cheers, gryff

[JCPalmer]

@dbawel, I do not understand the "freezing all transforms" prior animating.  What is that?  I understand your viewpoint as a user of multiple applications strung together, that baking upstream is defensive move to avoid issues downstream.  There is a high cost for that insurance in terms of the size of the data needed to download, and loss of flexibility in terms of re-combining, frozen FPS value, & work flow.

Remember I am not just a user of Blender. I am also aspirating game developer, not just making tools for others to use.  I am using Blender to front end process things which would be difficult in BJS.  By programming from both sides, I can do things like costly analysis of sets of shape keys assigned to multiple independent groups (FACE, WINK, L_HAND, R_HAND) on the same mesh, then generate optimum source code, that I can catch on the other side with Typescript.

I have decided that Blender is only going to be my "parts" supplier, either shape keys or poses.  The actual performance of any animation will be done soley in webGL.  Might sound risky, but a pose is a pose.  Either you are translating from Blender to the Queued Interpolation extension correctly or not.  I control the code on both sides, which is my edge.

Yes @gryff, you will need the TOB Blender add-in, not the .babylon exporter.  TOB actually has a separate export process for transferring poses from a Blender Pose Library to a QI.SkeletonPoseLibrary source file.  There is a button on the armature tab you click, then pick a file name.

When exporting your poses, every bone is compared to see if it is at rest.  If the value of a bone is the same as rest, it is not included.  While this makes things even more compact, the real reason is so you can assign "sub-poses" to a skeleton.  A sub-pose's bone matrices are substituted at runtime for any pose targets which are queued until the sub-pose is removed from the skeleton. In the above library, headLeft, headBack, headForward, & headRight are all sub-poses.  They can make the same walk poses be performed 5 different ways.  Baking upstream makes sub-poses much much harder.

I just added a pose to the IK rig, and generated a file.  This process automatically excludes IK bones.  I have yet to delete all the IK bones, export it again, and check if I get the same results.  If my results are the same, then you are going to have to provide .babylon files in order for me to figure out the problem.  FYI, here is what an export looks like (not sure if auto including the rest pose is really necessary):

// File generated with Tower of Babel version: 5.0.0 on 06/13/16
var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
};
var game_rig_no_hands3;
(function (game_rig_no_hands3) {
    var B = BABYLON;
    var M = B.Matrix.FromValues;
    var boneLengths = {
        "Root":.5349,"pelvis":.8868,"spine_01":.6803,"spine_02":.7507,"spine_03":1.4429,"clavicle_l":1.4906,"upperarm_l":2.4214,"lowerarm_l":2.3861,"hand_l":.3224,"clavicle_r":1.4906,"upperarm_r":2.4214,"lowerarm_r":2.3861,"hand_r":.3224,"neck_01":1.0821,"head":1.4814,"thigh_r":3.9444,"calf_r":4.076,"foot_r":1.3151,"ball_r":.6619,"thigh_l":3.9444,"calf_l":4.076,"foot_l":1.3151,"ball_l":.6619
    };

    var lib = new QI.SkeletonPoseLibrary("game_rig_no_hands3", boneLengths);
    new QI.Pose("rest", lib, {
        "Root": M(0,1,0,0,0,0,-1,0,1,0,0,0,0,0,.2675,1),
        "pelvis": M(0,0,1,0,.8996,-.4368,0,0,.4368,.8996,0,0,8.7429,.3995,0,1),
        "spine_01": M(1,0,0,0,0,.7772,.6293,0,0,-.6293,.7772,0,0,.8868,0,1),
        "spine_02": M(1,0,0,0,0,.9789,-.2041,0,0,.2041,.9789,0,0,.6803,0,1),
        "spine_03": M(1,0,0,0,0,.9955,-.0945,0,0,.0945,.9955,0,0,.7507,0,1),
        "clavicle_l": M(-.1507,-.9886,-.0038,0,.9882,-.1506,-.0263,0,.0255,-.0077,.9996,0,.2274,2.4496,.4764,1),
        "upperarm_l": M(.775,-.6315,-.023,0,.631,.7753,-.0271,0,.035,.0065,.9994,0,0,1.4906,0,1),
        "lowerarm_l": M(1,.0019,-.005,0,.002,.7311,.6823,0,.0049,-.6823,.7311,0,0,2.4215,0,1),
        "hand_l": M(.6569,.0737,-.7504,0,.1073,.976,.1897,0,.7463,-.2051,.6332,0,0,2.3862,0,1),
        "clavicle_r": M(-.1507,.9886,.0038,0,-.9882,-.1506,-.0263,0,-.0255,-.0077,.9996,0,-.2274,2.4496,.4764,1),
        "upperarm_r": M(.775,.6315,.023,0,-.631,.7753,-.0271,0,-.035,.0065,.9994,0,0,1.4906,0,1),
        "lowerarm_r": M(1,-.0019,.005,0,-.002,.7311,.6823,0,-.0049,-.6823,.7311,0,0,2.4215,0,1),
        "hand_r": M(-.4518,.1221,-.8837,0,-.1073,.976,.1897,0,.8856,.1805,-.4279,0,0,2.3862,0,1),
        "neck_01": M(1,0,0,0,0,.9039,.4278,0,0,-.4278,.9039,0,0,3.1712,.3627,1),
        "head": M(1,0,0,0,0,.9142,-.4053,0,0,.4053,.9142,0,0,1.0821,0,1),
        "thigh_r": M(.8932,-.2431,.3783,0,-.1006,-.928,-.3588,0,.4383,.2824,-.8533,0,-1.0138,-.0366,-.1097,1),
        "calf_r": M(.8915,-.0046,.4529,0,-.0497,.9929,.1079,0,-.4502,-.1187,.885,0,0,3.9444,0,1),
        "foot_r": M(.9853,-.1534,-.0745,0,-.0019,.427,-.9043,0,.1706,.8912,.4204,0,0,4.076,0,1),
        "ball_r": M(.998,-.0418,.0471,0,.0598,.8613,-.5045,0,-.0195,.5064,.8621,0,0,1.3151,0,1),
        "thigh_l": M(.8932,.2431,-.3783,0,.1006,-.928,-.3588,0,-.4383,.2825,-.8533,0,1.0138,-.0366,-.1097,1),
        "calf_l": M(.8915,.0046,-.4529,0,.0496,.9929,.1078,0,.4502,-.1186,.885,0,0,3.9444,0,1),
        "foot_l": M(1,.0049,.0044,0,.0019,.427,-.9043,0,-.0063,.9043,.4269,0,0,4.076,0,1),
        "ball_l": M(.998,.0418,-.0471,0,-.0598,.8613,-.5045,0,.0195,.5064,.8621,0,0,1.3151,0,1)    
});

    new QI.Pose("stepLeft", lib, {
        "Root": M(0,1,0,0,0,0,-1,0,1,0,0,0,0,0,-.2351,1),
        "upperarm_l": M(.8229,-.568,-.0149,0,.5659,.8216,-.0689,0,.0514,.0483,.9975,0,0,1.4906,0,1),
        "lowerarm_l": M(.9993,.0257,.0284,0,-.0376,.5211,.8527,0,.0071,-.8531,.5216,0,0,2.4215,0,1),
        "hand_l": M(.6905,-.1613,-.7051,0,.2015,.9791,-.0267,0,.6947,-.1236,.7086,0,0,2.3862,0,1),
        "upperarm_r": M(.7779,.628,.0218,0,-.613,.7661,-.1932,0,-.138,.1369,.9809,0,0,1.4906,0,1),
        "lowerarm_r": M(1,-.0031,.0031,0,.0001,.7178,.6962,0,-.0044,-.6962,.7178,0,0,2.4215,0,1),
        "hand_r": M(-.4539,.2486,-.8556,0,-.1125,.9366,.3318,0,.8839,.2469,-.3972,0,0,2.3862,0,1),
        "thigh_r": M(.8885,-.2851,.3595,0,-.0999,-.885,-.4548,0,.4478,.3682,-.8148,0,-1.0138,-.0366,-.1098,1),
        "calf_r": M(.8913,-.0024,.4533,0,-.0267,.998,.0578,0,-.4526,-.0637,.8895,0,0,3.9444,0,1),
        "foot_r": M(.9852,-.1576,-.0668,0,-.0017,.3813,-.9245,0,.1711,.9109,.3754,0,0,4.076,0,1),
        "thigh_l": M(.9258,-.0513,-.3744,0,.0983,-.9239,.3697,0,-.3649,-.3791,-.8504,0,1.0138,-.0366,-.1097,1),
        "calf_l": M(.8853,-.0177,-.4647,0,.4394,.3593,.8233,0,.1524,-.9331,.3259,0,0,3.9444,0,1),
        "foot_l": M(.9977,.056,-.0371,0,-.0426,.1005,-.994,0,-.0519,.9934,.1027,0,0,4.076,0,1)    
});

})(game_rig_no_hands3 || (game_rig_no_hands3 = {}));

 

[JCPalmer]

Well, I deleted all my IK bones, and I lost my pose except for the root bone translation I added.  The more I think about it, I the problem is likely with the definition of the skeleton & mesh.  Failure to actually write out the frames or pose of certain bones, should not affect the values for other bones.

The mesh must be defined with the skeleton in the exact same state as when the skeleton was defined.  This was the cause of the problems in 4.2-4.5.  In order to know what the matriceIndexes of the bones are, when ignoring some of them, you have to process all the skeletons first.  I was also recording the animation when the skeletons were being defined.  Later when the meshes got processed, there was no guarantee that the mesh got processed set on the same frame as the skeleton.

I have another test I can do.  I always thought you would have a separate skeleton with the extra ik bones, from the skeleton that got exported with the mesh.  Should be able to work if they are one & the same though.

Also, I think you are referring to "un-applied" transformations in Blender lingo, right @dbawel?  Actually, future versions of either exporter are going to detect if there are any on a mesh with an armature, and just terminate with an error rather than produce an output file.  Maybe an error message like: "Die noob, die!".  @Wingnut, would love that

[JCPalmer]

Ok, found a bug.  The parentboneindex in the skeleton definition was wrong ignoring IK bones.  There could be more, so have not PR'ed yet.  Try using this update, and report results.

[dbawel]

Hey @JCPalmer -

I know all too well that you are a game developer as well, and again - one of the great talents as well as contributors to this forum. So I understand what you might see as limitations, but I must disagree, as I would personally never initiate keyframe interpolations post my animation package - unless for a very specific application. But I certainly do appriciate the level of concern you have for memory and resources - as there is often a price to pay for this outside of a slightly heavier scene - and I personally can't bring myself to doing this after so many years of running into problems when I used post keyframe interpolation in a pipeline. But if I was building a game and knew I had my pipeline fully vetted and locked - and free of any obvious issues, then not baking skeletal animations would possibly be fine.

Again, this is my personal preference and also my advice as well. But we all have our opinions - which is one of the best aspects of existing as individuals.

As for freezing transforms, you nailed it - 

Quote

Also, I think you are referring to "un-applied" transformations in Blender lingo, right

And I believe in Blender it is to Apply Transforms or more specifically "Apply ---> Rotation & Scale". This is an essential step for me and any team I work with whenever importing/exporting skeletons or object hierachies containing animation. As an example 3DSMax uses a Z-up world axis, and Blender a Y-up world axis. So depending on how you import a character from 3DSMax, you might often find that the character or object is rotated 90 degrees. Of course, I often read posts on this forum where this is an issue. So to correct this, you might simply rotate your character 90 degrees back into the correct desired orientation matching your display in Max, and everything now "looks" correct. However, in doing this the rotation of your character's root is now 90 degrees offset. This can and often will cause serious problems  - especially if you are merging animation or adding a proceedural animation now with your character in Blender.

So to correct this, you would use "Apply ---> Rotation & Scale" which causes your bone's rotation transforms (numerical values) to change correctly to a value of 0.0 in X,Y,Z - but without changing your character's orientation in Blender world space.

And most importantly regardless of whether you are importing/exporting between applications and/or frameworks, when you have several artists working on the same scene and characters, one or more persons can often scale and/or transform a character or object during the modelling process, rigging process, etc. - leaving values other than 1.0 in the X,Y,Z scale channels in your application. Now any animation will be scaled to this value other than 1.0, as well as often rotations. And this doesn't need to be the result of a team, but individual artists often do this as well, and then cannot figure out why they have transform problems. This is why I always recommend "Freezing Transforms" as it is called in Maya, XSI, Houdini, MotionBuilder, Etc. - and "Apply Transforms" in Blender.

Anyway, @JCPalmer - please don't be mad at me for holding a strong belief in baking animation - we all have our own preferences. But in freezing or applying transforms, I must always recommend this prior to export. But I'm guessing you already knew all of this - however, I wrote this explanation for the benefit of other users who I often see trying to resolve transform problems.

Cheers,

DB

[gryff]

Quote

Try using this update, and report results.

@JCPalmer : As you requested Jeff, the results using the simple rig in image below:

IK Removal Test

Exported using the Babylon Exporter from your above link and with the "ignore IK bones" box checked.

As you can see it has four IK bones - 2 foot bones (chain length 2, yellow colour) and 2 knee bones (chain length 1, brown colour). The regular foot bones "copy rotation" of the foot IK bones.

I first created a simple Pose Library - 2 "Contact" poses and 2 "Passing" poses then used those 4 poses to create the animation.

A pretty crude animation - almost a "zombie" walk - but it WORKED.

Another triumph for you Jeff

cheers, gryff

 

 

 

[gryff]

@JCPalmer :And in case you want the .blend files they are here in a zip file:

Pose_Libraries

base_model3a.blend - just the 4 poses.

base_model3b.blend - 4 poses and the animation created from the 4 poses.

cheers, gryff

[JCPalmer]

@gryff, thanks for debugging this for me.  It is PR'ed, but the file you have is un-modified.  I downloaded your blends.  Will look at them and your tutorial reference soon. 

Going to build my IK rig again, using a new TOB operator I just made, Amputate Limb.  It removes any child bones of the selected bone or shear point, recursively.  What it also does is assign any vertices from the vertex groups of the delete bones to the vertex group of the shear point bone.  You can do this manually, but it takes several minutes.  Also, you could over-spray.  I want exact results every time.

I will use this to shear off the numerous finger bones off the MH 1.1 Game-rig.  Not sure why you are playing with the cmu rig.  It has too many bones to run on mobile.

@dbawel, going back to my original baking comment at the beginning of the thread, anything using a BABYLON.Animation object is technically baked.  It is just a question of whether you use a Blender menu, or let the exporter bake it without leaving artifacts in the .blend file.  Barring any difference, which is easy to test, letting the exporter do it, gives you more future options without having to try an figure out what the key frames are amongst all the derivative ones.

[gryff]

@JCPalmer : Np problem  Jeff. I'm working on something that uses IK bones and Pose libraries - so it gave me more experience with the latter.

Quote

Not sure why you are playing with the cmu rig

Actually Jeff, I use the game rig from MH1.02 most of the time - which probably also has more bones than will run on a  mobile. The CMU rig is funny as it seems to have been designed for the CMU .bvh files. It has two interesting bones - RHip and LHip - between the hips and thigh bones, BUT any CMU .bvh file I have ever used - has no changes to those bones. They can be deleted as far as I can tell along with the finger/thumb bones. 

Anyway - glad we sorted this issue.

cheers, gryff

[dbawel]

@gryff - 

1 hour ago, gryff said:

Actually Jeff, I use the game rig from MH1.02 most of the time - which probably also has more bones than will run on a  mobile. The CMU rig is funny as it seems to have been designed for the CMU .bvh files. It has two interesting bones - RHip and LHip - between the hips and thigh bones, BUT any CMU .bvh file I have ever used - has no changes to those bones. They can be deleted as far as I can tell along with the finger/thumb bones. 

Yes, these bones can be deleted without any negative performance issues as they generally don't (and should not) recieve any values in their animation channels. These bones are also common in many other formats and default skeletons in many applications, and are primarily used for weighting (binding, skinning) to a mesh. So unless your skeleton is bound to a mesh, there will be no effect on the resulting animation, and in WebGL these only use resources and are unnecessary; unless someone is inexperienced and/or has made an error by animating their rotation channels. These are legacies of the BVH format, and I never recommend keeping these bones in skeletons when the target API is WebGL or any game engine.

[JCPalmer]

The finger/thumb influence needs to be re-assigned, but just letting any influence of those 2 hip bone go away looks to be beneficial.  The skeleton is still exported with 7 influencers by default, but the # of verts requiring 7 drops to 25 from 45.  This may allow exporting with 6, 5, or maybe 4 with pretty acceptable results.  Since 4.0 of exporter, influencers are sorted high to low.  When a vertex has more than you tell it to export, the lowest are dropped first, not first encountered like before.

After fingers and hips deleted, the number of bone on a cmu skeleton is 23 as well.  It could be a mobile rig.  Did notice a problem where a stray vertex on the right hand is part of a left finger vertex group.  Not sure how big a problem that would be.  I still like the root bone on the ground of the game rig though.

[gryff]

Quote

Did notice a problem where a stray vertex on the right hand is part of a left finger vertex group.  Not sure how big a problem that would be.

@JCPalmer : Well Jeff, I  have run into issues before (see image below). Note the left foot bone is selected but it is the right shoe that has the weight paint. And worse - there is no vertex group called foot.L . If you actually try moving the foot bone - it moves the pants and not the shoe. So not everything is perfect even with MH . Easy to fix though - just unparent the shoes, then reparent them with automatic weights.

As for your single vertex - just subtract weight paint on the right hand.

cheers, gryff

[dbawel]

@JCPalmer -

3 hours ago, JCPalmer said:

I still like the root bone on the ground of the game rig though.

I've generally always found benefits in using an object (sometimes a bone) in the position of the root bone in your scene, as it is very useful for full character translation and rotation, as well as in functions such as registering the floor level, detecting and translating on inclines, and many actions from the feet upwards to the head. But regardless how you might use this "bone", I dont recommend an actual skeleton object such as a bone, since there will never be any verticies bound to it. So since its use is simply as a parent object, using a bone for this purpose only lowers the number of actual bone objects permitted in a scene; and also genrally requires more resources since it holds the attributes of a skeleton object without the need to ever use in this capacity.

So I generally recommend that if you use a rig such as in your example above, then there are real advantages to parent or constrain your skeleton to an object who's center equates the current "root" bone's center. I also recommend adding additional parent objects in the same position - also as parents of the skeleton and root bone to handle proceedures such as floor registration, character translation, and most often a seperate parent object for character orientation; as this causes less potential conflicts when reaching euler rotation limits as can often occur.

Also for compatability in other applications, there is a standard skeleton recognized in many applications and is based upon the .bvh format - which includes the lhip and rhip, as well as the "root" bone is always in the hip or base of the backbone for the greates compatability with motion capture and other datasets. Just an FYI for future reference so that all artists and developers might speak the same language in terms of skeletons. So generally the "root" bone should be in the hips. Of course, this is a completely objective issue, but there is a general standard by which most applications understand or expect the root and other bones to be located - especially applications such as MotionBuilder, and many plugins for 3DSMax and Maya as well as others.

DB

[JCPalmer]

I think the initial goal of this thread is satisfied, so going to re-purpose with my problems.

I do not know if my changes to IK the rig are wrong, or this rig just cannot bend at the waist, due to that root bone being at the base. 

Gryff's rig, with the additional IK bones, can bend at the knees / jump.

gryff rig.avi

Mine cannot. 

game rig.avi

Is this due to my pelvis bone being parented to the root at his feet?  If so, I guess could use the cmu rig with all the deletions.  Kind of throws a wrench in how to record translation and rotation.  The best I can come up with is to have a text field to put the bone name to use for translation right above the Skeleton Library export button.  In gryff's case, the would be 'root'.  Shouldn't this actually be 'root.ik'?  That way the bone would not be exported with a pose library or with a scene.  The button would then need to generate the trans / rotation for each pose in the library relative to the rest values.

David, I really need this to be self contained within the skeleton, so no parenting.  Technique fine for an individual application, not a BJS extension.

[gryff]

Quote

Gryff's rig, with the additional IK bones, can bend at the knees / jump ..... Mine cannot. 

@JCPalmer : Jeff, did you add a "copy rotation" constraint to the foot bone? So that it copies the rotation of the IK bone?

Edit: Ohh and in the properties of that foot bone - turn off "Inherit rotation"

Edit2: Can you post your rig so I can take a look?

It is not the new root bone causing the problem - I use one as a  parent for all my IK bones.

cheers, gryff

[dbawel]

@JCPalmer and @gryff - Without your scene files, I can only tell you what I see is happening, but am certain of your issue. I'm not familiar with Blender "IK Controls", but in looking at your AVI files it's obvious that the IK control bones hold specific constraints when attached to your skeleton. This is not typical behavior of any IK skeleton outside of Blender or any other application; as in order to register a "floor" (even there is no floor object), the application requires either a parenting method or a set of constraints which allows the inverse kinematics in all of your skeleton chains to respond in a specific behavior (normally IK works from the end of the bone chain (end effector) backwards towards the root bone of each individual chain (not the "root" of the skeleton.)

So now I see how IK Controls in Blender function. So without these IK Control bones, you will not be able to produce the same performance as the skeleton using IK Control bones, as "normal" IK (and any skeleton exported out of Blender) will not hold these constraints and behaviors. There are methods that I can provide to produce the same or similar behaviors once exported from Blender, but they will have no relationship to the IK Control Bones and behaviors you see in Blender. These are only valid in Blender and extremely useful for quickly animating specific actions. 

I'm not certain what the specific target behavior is outside of Blender, and how you might want the user experience and input, but there is no way to export the IK performance you get in Blender using IK Control bones. As you are aware, you can animate in Blender, bake, delete the IK Control bones, and export moves and actions. But it appears that you wish to build a control rig" similar to the one in Blender. If this is the case, then this requires a unique combination of parenting and constraints (as well as seperate objects similar to IK Control bones) in order to acheive this. If we can have a more specific discussion, then I'm certain you can achieve what you want. This will definately require a substantial number of function in BJS, which I personally would make an extension. However, I can provide you with very specific methods so that you won't need to waste time on a whole lot of testing and uncertainty.

Cheers,

DB

[JCPalmer]

@gryff, the copy rotations were there.  Changed the inherits, but no change.  I also tried un-parenting the pelvis bone from the root bone.  It did not help, but it also did not hurt!  If I then rename root to something like master.ik, then my # of bones in BJS will drop to 22!  I could put in a field so you could specify the bone to use for position / rotation changes to make permanent on the BJS mesh.  I have only modified the UI so far, but here's what it would look like:

Here is the .blend.  I would appreciate if you could look at it.

[JCPalmer]

@dbawel, the only goal of this is to just to make making posing the skeleton fast & easy.  The exporting feature of 'ignore IK bones' is just so that the bones that have outlived their usefulness do not follow us to BJS.  I have no interest in doing IK in BJS, though Blender does have "normal" IK  solver features.  If someone implemented an IK solver in BJS, I could throw those bone fields on the .babylon file.

My plan is to standardize my rig that I would use for all my characters.  Make a modified version with IK bones.  Make up to 200 pose & sub-poses that can be used / combined over an over.