Blender exporter problems with many animations

[adam]

It's not a hack.  Good luck

[gryff]

@adam : the video you posted above is done by Jonathan Williams of cgcookie.com. I have learned a lot about using Blender from that guy - he produces excellent tutorial videos

cheers, gryff

[ozRocker]

I got it working!!

http://www.babylonjs-playground.com/#25M97N#51

While looping through the keys I just check if the current bone is the "hip" bone.  If it is, do not apply the rescaling.  I'm sure there's a cleaner way to write the code by not resorting to using the actual bone name.  But the point is, if re-scaling you just leave the root bone alone and it comes out perfectly.  I've tested this in my virtual world and it works great.  My avatars now have their swagger back. YAY! So happy about this!

[ozRocker]

I just noticed the "parent" variable so I replaced the hard-coding with a check to see if parent == null instead.  This playground has cleaner code:

http://www.babylonjs-playground.com/#25M97N#52

 

[adam]

8 hours ago, ozRocker said:

 

I got it working!!

 

Yes, that will work as long as your models are about the same size / height.

[ozRocker]

14 minutes ago, adam said:

Yes, that will work as long as your models are about the same size / height.

Thanks for the heads-up!  I'll keep that in mind.  

[JCPalmer]

@adam , what about using the ratio of bounding boxes between the source / dest skeleton for bone(s) which have no parent?  I do not know how to compute this in BJS, but I can get it form Blender. I added bone lengths in 2.3, only scaled it wrong.  On the assumption this will work, will put this on the Blender exporter today.  We would need to get the properrty (vector3) on skeleton, and read in skeleton.parse().  Not much time, so let me know.

 

[JCPalmer]

Also, the example file I used for that snap was in a .blend I was doing something stupid for a rest post.  Will probably get best results when getting dimensions at rest.  It is up to user to have comparable rest poses with arms out to sides, else screw them.

[adam]

26 minutes ago, JCPalmer said:

what about using the ratio of bounding boxes between the source / dest skeleton for bone(s) which have no parent?

That sounds like a good solution.

[ozRocker]

ooh this looks interesting!  Unfortunately I don't have time to experiment with it today though. I'd eventually like to compare all 3 methods: ignoring root, adding parent bone to root, bounding box.

[JCPalmer]

This is going to be done in more than 1 PR.  Blender exporter & changes to skeleton to load 'dimensionsAtRest' first.  Actual changes to Bone.copyAnimationRange(), can then be tested, (assuming you re-export with new exporter).  Will at the very least get the exporter (already coded) onto google drive before I finish yesterday.

Today, in Melbourne, is very different from NY.  Please export / republish to same spot, as soon as you can.  2.4 goes out at end of week.

[JCPalmer]

Ok, PR with Blender exporter 4.6.0 & changes to Skeleton to load "dimensionsAtRest" on the way.  It is a US holiday, so may not be approved real soon.

@ozRocker, use this for new exporter, if you manage to have time to re-export before then.

[JCPalmer]

Ok, I PRed the changes for 2.4, untested relating to root bones.  Am now calculating a skelDimensionRatio in Skeleton, and passing it to Bone's copyAnimationRange

@ozRocker, your babylon's need to be re-exported using 4.6.0.  A playground without an overridden Bone.copyAnimationRange should be started with.  Also, is the skeleton used to make the rumba animation the same one as the character uses.  If so, better to use the first scene with the idle animation to test.

[ozRocker]

ok @JCPalmer I used the new exporter to export the rumba animation and the Josh avatar.  Here's a playground with the rumba animation applied to Josh (not using that extra rescaling code):

http://www.babylonjs-playground.com/#25M97N#53

 

[JCPalmer]

Well going through the code, first I put console logs in for the dimensionsAtRest being loaded into the skeleton, which validates they are in both .babylons.  To have any meaning, they must also not be the same values, or everything is just going to be multiplied by 1.  Passed.  Here are the values, more on this later:

avatar dimensions   {X: 3.5118 Y:4.4382 Z:0.6782}
animator dimensions {X: 1.8305 Y:1.1113 Z:4.8125}

Next, I wanted to see it was going through the code in bone, so I brought a copy of the js prototype for Bone.copyAnimationRange().  skelDimensionsRatio being passed to bone.copyAnimationRange was null.  Turns out, although a skelDimensionsRatio is created, I forgot to put it as an arg.  Added the skeleton prototype to the playground, and put the ratio on the call, and suddenly the mesh disappeared.  Looking closely and adding a bunch more console messages, the computed ratio:

skelDimensionsRatio {X: 1.9184922152417372 Y:3.9937010708179614 Z:0.14092467532467534}

causes the the mesh to be moved higher out of scene.  He is there, if you zoom out, pg.  I am wondering how the dimensions can be so skewed between the 2 skeletons. @ozRocker, can you look at your blend files, putting the skeleton files in edit mode & see what Blender has for the dimensions?  The changes for each dimension are not very proportional.

next, @adam, do you think I am messed up somehow?

[JCPalmer]

Check each .blend selecting each armature, in object mode, like:

[adam]

Those dimensions at rest can't be correct.

The hips for one of the models is at:

-0.0131, 2.289, 0.013

and the other one is at:

0.0067, 2.5382, 0.0005

[gryff]

The image @JCPalmer has posted above looks like a model that was exported from MakeHuman1.1 with the units set to decimeters. I would normally use the meters setting

Strangely, in MH1.02 - I would have to reverse that.

Then you end up with a rig/model that fits inside a standard Blender cube mesh.

cheers, gryff