JCM Drivers Broken When Transfering Shapekeys (Manually)

Issue #1505 resolved
Jasper29 created an issue

Hi Thomas, hope you had a great vacation. Before you left, I noticed that when transferring shapekeys from main mesh to GoldenPalace (with Genesis 8), the drivers for JCM ThighFwd_57 L and R are broken. I’m using Blender 3.5, and this problem has been noticed in the last few commits. It seems to only be a Genesis 8 and Golden Palace issue but i’m not 100% sure (tested Genesis 9 but could of course not use Golden Palace and it seemed fine). I also haven’t checked every driver for the main JCMs, but these two are definitely broken.

Steps to recreate:

1: Import character with typical basic settings (FACS, Expressions, JCMs etc). With the last options on bottom, only select transfer to face meshes.

2: In object mode, select Golden Palace and import desired morphs. (In import settings, select ‘use rig property drivers’, ‘use adjusters’ and ‘make all bones poseable’)

3: Select main mesh and import same morphs you just loaded onto Golden Palace. (In import settings, select ‘use rig property drivers’, ‘use adjusters’ and ‘make all bones poseable’)

4: Select Golden Palace, then main mesh and merge geograft.

5: Select Daz skeleton and either convert to desired rig directly, or generate metarig. NOTE: I personally generate metarig, edit it for better posing and convert it to Rigify.

6: With rig generated, select Torso bone and rotate on X-axis to bend character over. You will notice stretching/volume being added to glute and upper thigh area. If you select the body and go to Object Data Properties you will notice the drivers for JCM ThighFwd_57 L and R are at 0 when they should be at 1 (when bent over).

The supplied pictures show the results of the most recent version of Diffeo, but I also included the same exact model already setup from about a month and a half ago using Diffeo, with the same exact morphs and used the same exact workflow, and you can see that those drivers are working fine.

Diffeo 1.7.0.1530:

Older Diffeo Using Same exact model/morphs/workflow (From about 1 1/2 months ago using current commit at time):

Comments (13)

  1. Alessandro Padovani

    daz studio 4.21.0.5, blender 3.5.0, diffeomorphic 1.7.0.1530

    I can confirm that ThighFwr_57 doesn’t work with rigify. It has nothing to do with golden palace it doesn’t work even without geografts. It works fine before converting to rigify, then after we convert to rigify it doesn’t work anymore.

    Didn’t test other jcms, it is possible there are others that don’t work. Didn’t test mhx either.

    steps:

    1. import G8F and jcms
    2. pose the leg and check ThighFwr_57, it works fine
    3. convert to rigify
    4. pose the leg and check ThighFwr_57, it doesn’t work

  2. Thomas Larsson repo owner

    The acute problem has been fixed. There is a property called “JCMs On” which wasn’t properly copied to the rigify rig. This multiplier is used by some morphs, like pJCMThighFwd_57_L, but not by others, pJCMThighFwd_115_L.

    Another question is why JCMs On is not made into a protected property and displayed in the Morphs panel. Will investigate.

  3. Thomas Larsson repo owner

    OK, we have to enable the global setting Protect Multipliers to see the JCMs On slider. However, maybe it isn’t a good idea the protect multipliers in general. It works fine of jcms but a lot of facs morphs are also protected that shouldn’t be.

  4. Alessandro Padovani

    Commit 5986450 works fine here.

    As for protected morphs, personally I believe they shouldn’t be exposed to the user since they’re not intended to be changed anyway. This includes baked morphs. Eventually we may have a option in the global settings to expose the protected morphs in the user interface for debug purposes. Proof of this is Jasper is asking if he have to enable JCMs On, because he sees the morph in the user interface so it is just natural for him to understand it can be changed, I believe this is what any user will do.

    I mean now that we have baked morphs with their values we don’t need anymore to expose protected morphs. Unless I miss something.

  5. Jasper29 reporter

    Well put Alessandro, I agree. I personally love having as much options as possible, but if something is purely visual and not needed to be tweaked/won’t be used by most users, I think it’s kinda pointless to show-- although for debug reasons it’s understandable.

  6. Alessandro Padovani

    I still believe that baked morphs should not be exposed, but there's no reply and the main issue is resolved.

  7. Log in to comment