Solved: Importing FBX or BVH animation involving character dancing / walking backwards

megaworm

I have a motion capture suit, and I have figured out the workflow to import FBX and BVH animations onto Genesis 1-8 characters without any loss of data... Except when the figure begins walking backwards or spinning! I have multiple motion capture files, and they all play flawlessly in Motionbuilder, Blender, and Maya. There are no issues with the data. Most of the simpler dances work 100% in Daz, exactly how it should be, by following guides written on this forum to export Genesis 1-8 in a t-pose to Motionbuilder, applying the motion there, and exporting back to Daz using FBX or BVH.

Any dance or motion that involves the figure spinning or walking backwards will begin playing fine like all the others, until the moment the figure makes a spinning motion or begins walking backwards towards a certain direction, Daz will suddenly start tilting the figure back and forth at the hip, losing all feet-floor contact and breaking the animation.  I can prove that this is the issue, because if I delete the section of data where the figure is spinning or walking backwards, then the rest of the BVH/FBX will import correctly into Daz.  So it seems to be an issue with Daz studio's importer, not my data. It even affects static poses being imported via FBX/BVH. If the figure has their back towards the northeast, it will fail to load their root orientation and hip orientation properly.

Is this a known issue and being worked on? Because I just updated to the new version, hoping it had been fixed because of all the focus on animation inside Daz in the marketing lately. The issue is the same as always, and I am wondering if this is even being worked on? What is the reason for this issue, am I doing something wrong? Is there any workaround or way to get my motion capture data into Daz without any data loss, no matter what my actors are doing?

 

EDIT: This issue has been solved. The solution is to select all children of the root node, then turn off limits on all nodes of the Genesis figure and the FBX figure before applying the animation. Thank you Marcus Severus for your help!

megaworm

Here is how it happens.. The FBX/BVH import always works flawlessly up until the moment there is a spinning move, then everything falls apart. I have about 40 motion capture files, and I am attempting to make a music video in Daz. I won't really be able to, if this issue stops me.

How it imports into DAZ: https://imgur.com/Z6YoLP3 How it plays in Motionbuilder: https://imgur.com/YZt7gIn After the figure spins around, it seems like the importer fails to recognize that figure continued to spin, and stopped it spinning at an arbitrary point. It keeps the figure stuck looking back, when the actual animation has the figure completing the spin looking forward.

Gordig

Delete all the keyframes for the hip joint.

megaworm

Gordig said:

Delete all the keyframes for the hip joint.

This did not work. I deleted the position and rotation frames for the hip joint, and all it did was lock the hip in place, and break the animation further. See here  https://imgur.com/kK1QYg1

 

Hermit Crab

My reply is unfortunately going to be very vague because it is only a guess about something I know little about.

I've heard of 'Gimbal Lock' where (I think) when something rotates at an angle beyond 180 degrees, the software sees it as rotating only by the number of degrees over 180 (another term which comes to mind is Euler Rotations?? or something).

It seems to be a real-world problem with mechanical items (gimbals) as well as in the virtual world of 3d graphics.  I made a search before replying because I knew of the existence of the problem in 3d but I can't find any link to explain it that isn't beyond my 'much-less-than-Einstein' understanding.

Perhaps, though my reply might spark off a better explanation and hopefully a solution.

Your motion capture looks to be incredibly realistic!

Hermit Crab

At the risk of annoying you, Megaworm, by being so vague, I'll try to convey what I've managed to find out since my reply above.

Apparently most 3d software uses Euler angle curves to calculate the 3d rotations of an object.  This method allows the software to use curves in a graph editor.  The drawback to this method is that two rotating axes can sometimes align and this prevents the third axis from rotating (Gimbal Lock).  Could this be happening to the figure in your motion capture?

Other software gets round this by using Quaternian Rotation to calculate rotations in 3d applications.  Two drawbacks to this method of calculating is that (1) rotations beyond 360 degrees are not possible and  (2) there are no function curves created which enable the use of a graph editor.

I confused the 360 angle limit with the 180 degrees in my first reply, sorry about that.

As far as I know, all the software you've used to get correct motion have graph editors and so has DAZ, I believe.  This leaves me asking whether the problem may be with DAZ's fbx import?  Clutching at straws, could Collada (.dae) be any better?

megaworm

Marcus Severus said:

At the risk of annoying you, Megaworm, by being so vague, I'll try to convey what I've managed to find out since my reply above.

Apparently most 3d software uses Euler angle curves to calculate the 3d rotations of an object.  This method allows the software to use curves in a graph editor.  The drawback to this method is that two rotating axes can sometimes align and this prevents the third axis from rotating (Gimbal Lock).  Could this be happening to the figure in your motion capture?

Other software gets round this by using Quaternian Rotation to calculate rotations in 3d applications.  Two drawbacks to this method of calculating is that (1) rotations beyond 360 degrees are not possible and  (2) there are no function curves created which enable the use of a graph editor.

I confused the 360 angle limit with the 180 degrees in my first reply, sorry about that.

As far as I know, all the software you've used to get correct motion have graph editors and so has DAZ, I believe.  This leaves me asking whether the problem may be with DAZ's fbx import?  Clutching at straws, could Collada (.dae) be any better?

You had a really great point in seeing that it could be a limitation of 180 degrees, because that is exactly what it was. Upon investigation of the hip joint's line graph at the exact moment when the issues began, I found that the hip joint yrot had maxed out at 180 degrees exactly. I found that odd, so I tried selecting all the children of the parent figure and going to figure>limits>turn off limits.  And then all the motion capture data from the BVH file suddenly was able to work properly on a Genesis 1 model. It was the "Use limits" checkbox being on by default that was the issue. The full dance was now working, so I applied the same logic to Genesis 8 with my FBX import workflow, by turning off the limits on the Genesis 8 model. But it turns out I have to also turn off the limits on the FBX figure right after it is imported, and before creating an aniblock, because the process of creating an aniblock from the FBX will bake in the limited numbers. So you have to select all children nodes in the parent FBX figure and unlock all limits there, then create the aniblock, then copy the aniblock over to the genesis 8 figure with the limits unlocked there too, and then finally bake the aniblock!  I have yet to run into another dance file that gives me issues so I hope this process solidifies the workflow! Thank you for your insight and helping me to catch this.

Hermit Crab

Well I'm delighted that you found the solution to the problem but I definitely take no credit for the outcome.

I felt quite bad at the vague mumblings of my first post (which I couldn't edit, for some reason - I think there is a temporary forum software glitch.  My second post was derived from checking a book I have on animation software and the information there should be correct.  Even so, it was your from own investigation that the answer was discovered.

I'm very pleased though that you have cracked a way to go from your own motion capture to such good results with DAZ figures.

The animation you linked to looked very clean and well-performed.  Maybe you could find yourself a customer base among DAZ users!