JCM Reading Incorrect Joint Axis - Source of Problem Found

[brucek5]

I haven't found where in the code where the joint axis is determined for the corrective morphs, but morphs that should be linked to the "P" axis, is linked to the "H" axis. I'm guessing the other axis are incorrect too.

I'll keep looking in the code to find what defines this.

Bruce,

[brucek5]

I found part of the source of the problem. The Cinema-4D part of the bridge reads a FIG.dtu file where the JCM definitions are defined. Example:

{ "Bone" : "rShin", "Axis" : "XRotate", "Morph" : "pJCMShinBend_90_R",

It looks like all the "XRotate" need to be "YRotate". These must not be constants because I was unable to find this text in the DAZ3D Bridge code.

On a related note, I'm note sure what the "Would you like to fix bone orientations?" that seems to be driven by the contents of the FIG.dtu file. In my case, I see no difference when clicking Yes or No. If it is "fixing" something, the message box should state what is "broken".

Bruce

[samjay3d]

Hey, haven't looked at this code for a while so, sorry that I can't help more. Do not currently work at Daz3D but, this is most likely where the issue is coming from.

https://github.com/daz3d/DazToC4D/blob/d5d27f4433f3326d469129d26b1c67ec0a977178/Cinema%204D/appdir_common/plugins/DazToC4D/lib/MorphHelpers.py#L168

This function is what is used to set the vector type and transform type in the API but, I don't think it will be as simple as just changing Xrotate to Yrotate. For context, we had to do more conversions in Daz To Blender but I can not remember the coordinate system in c4d vs Daz but figuring out the differences between Daz and c4d transforms is what's necessary.

In side DazToBlender https://github.com/daz3d/DazToC4D/blob/d5d27f4433f3326d469129d26b1c67ec0a977178/Cinema%204D/appdir_common/plugins/DazToC4D/lib/Morphs.py#L196 https://github.com/daz3d/DazToC4D/blob/d5d27f4433f3326d469129d26b1c67ec0a977178/Cinema%204D/appdir_common/plugins/DazToC4D/lib/Morphs.py#L441

This is where the vector conversion is used. I am an artist turned programmer so, apologies for my old code haha.

About the pop-up,

So, unless this has changed in the new updates from Daz, when importing in the fbx the orientation on the joints were zeroed out to match the world axis after import, they were essentially reseted. The point of using the dtu was to fix the orientation on the joints after fbx import. If they look the same either the rotations are off or, Daz has fixed the fbx export and that section of the code should be disabled.

hope this helps!

[brucek5]

Hi Sam,

I think I'm partly to blame for this bug, as this wasn't an issue in the previous revision of the Bridge. I had made a request to make so the Bridge import all the joints axis the same as if you imported a FBX file directly from DAZ3D into Cinema-4D. In the previous revision the JCM worked, but code and animation re-targeting I wrote in Cinema-4D no longer worked because the joint axis were different and characters rigged based on a "A" pose were converted to a "T" pose. The latest revision fixed all those issues including using the Cinema-4D default rotation mapping to "HPB".

I should have been more clear when I used the term "Source of Problem". I didn't mean to suggest that the DAZ3D side of the Bridge needed to be changed, but more where I traced it back to where the axis are defined. Based on your comments, it seems the easiest and safest means to fix this is to do something like I did to trace the code is change the code that creates the joint Xpresso object rotation axis output that connects to the Xpresso object Python input, or any where else on just the Cinema-4D side of the Bridge so it doesn't break other applications.

On the message box text, might seem nick-picky, but if I see a message that uses words like "Fix", "Change", "Restore", etc., I also want to know why am I being asked this and what happens if I do or don't click Yes

On a related topic, I'm started to see what danielbui78 talking about the challenges of emulating the DAZ3D JCM/ECR system. I've been able to export "baked all ECR morphs" for a single joint in a specific rotation, in this case the shin, while the character is still in the "A" pose. In DAZ3D with the morphs constantly being applied, look right when the shin is rotated to the full 155 deg. Though in Cinema-4D, doing the same thing results is a mess. It's like DAZ3D has an extra ability to mix the joint-to-mesh deformer (In Cinema-4D it's called the Weight Tag) and the corrective morphs (which is the Morph Tag in Cinema-4D) at the same time (or work together) which I don't think Cinema-4D can do that I have found. In fact I don't think I've ever found a character project done in Cinema-4D that had JCM that was even close to what DAZ3D does. If anyone has, please show me.

Bruce.

[brucek5]

Hi Sam,

Forgot to comment on the rotational zeroing. When I import anything from DAZ3D using FBX, all joint rotational values are zero based on the designed posed it was created with. Example, if I import any Genesis 8 character, regardless if it is in a pose or animated, I can select all joint from the hip down, put zero in HPB, and the character will jump to the perfect "A" pose. ,This applies to all other characters before Genesis 8, except they'll jump to a "T" pose. So I'm not sure where the need to fix a zeroing issue comes from in the first place.

Bruce.

[danielbui78]

About the pop-up,

So, unless this has changed in the new updates from Daz, when importing in the fbx the orientation on the joints were zeroed out to match the world axis after import, they were essentially reseted. The point of using the dtu was to fix the orientation on the joints after fbx import. If they look the same either the rotations are off or, Daz has fixed the fbx export and that section of the code should be disabled.

hope this helps!

Sorry, there is some confusion here that needs to be clarified: When you click "Fix Bone Orientations?" it should NOT visibly change the character. What it is doing is modifying the bone orientations so that the x,y,z rotation orientation of each bone points in different direction. In other words, it uses a different joint-space orientation system than what gets exported by the Daz FbxExporter.

This joint-space is extremely important, since it affects things like JCM and mirror-symmetry tools: example: 90 degrees in Daz Studio may correspond with -90 degrees in other programs. If a JCM is set up to kick in at 90 degrees, but the 3D application is telling it that the joint is actually at -90 degrees, things will not work correctly. For mirror-symmetry example, some programs apply 90 degrees to right and left limbs, assuming that this will mirror affects on both sides. However, Daz joint-orientation does not work like this and will produce incorrect results. I agree that calling it "Fixing" is very confusing and should be changed in the future.

Unless there is a specific test case with specific instructions to reproduce and verify a specific bug, I will mark this issue as question for now. Thanks

[brucek5]

Sorry, I'm still confused. I tried the "Fix Bone Orientations?" both with "Yes" and "No", and animated the character using my retargeting software I've been working on. In both cases, the character animated the same. I can understand that other 3D applications might have different joint-space orientation systems, but wouldn't this be constant between DAZ3D and Cinema4D?

As far as the JCM issue, the attached PDF file illustrates what I my observations are that the last Bridge revision is mapping the JCM logic to the incorrect axis. The "Fix Bone Orientations?" options doesn't change this.

With all due respect, unless I'm missing something, we do have a bug. It seems the easiest and safest means to fix this to not impact the other Bridges, is to revise just the Cinema4D version of the Morphs.py on what joint Xpresso axis port is being used.

Hopes this helps. Bruce.

JCM_Axis_Issue.pdf

[danielbui78]

I don't doubt that there are bugs, but the major challenge for me is trying to understand and identify expected behavior, unexpected behavior, intended use-case, incorrect use, valid data, invalid data, etc. The only place I can start to investigate is with exact step-by-step instructions for reproducing issues with clear description of expected behavior vs actual behavior.

I'll look through your notes and will post updates when I figure something out. Thanks