eye facs don't work

[Alessandro Padovani]

daz studio 4.15, blender 2.92, commit ad3b726

It seems eye facs don't work. Or may be I'm doing something wrong. As for G8.1F the eye facs are used to make the eyelid follow the eye. With the steps below the eye facs work for eye left-right, but not for eye up-down.

steps:

1. import G8.1F
2. add extra face bones
3. import facs units
4. pose the eyes

‌

Please note that G8F uses weight maps to make the eyelid follow the eye, so in this case we don't need to import any morph and the eyes work fine.

steps:

1. import G8F
2. pose the eyes

‌

[engetudouiti]

I could confirm. It seems one of commit cause, not generate eye related hidden facs_ctrl 4 morphs as Fin and raw Props.

facs_ctrl_EyeLookDownLeft.dsf (and right)

facs_ctrl_EyeLookUpLeft.dsf (and right)

all these 4 morphs need to be driven by mix eye rotation value (drv bone and pose bone)

Add on correctly circulate mix rotation value with constrain bone, but there is no morph props, which need to add the mix rotation value as variable.

The eye related morphs were most complex hieralchical morphs, then all morphs were checked carefully, then it worked before. (I confrim) so it seems one of recent commit effect it.

there are 8 hidden facs_ctrl_EyeLook XXXXX but other 4 ctrl add on correctly generate raw and fin props about other 4 controllers

facs_ctrl_EyeLookInLeft /Right

facs_ctrl_EyeLookOutLeft /Right

I suppose, if add on confuse about facs_ctrl_EyeLookUp-DownLeft.dsf (and right) then not generate (exclude) as same morphs

facs_ctrl_EyeLookDownLeft.dsf (and right)

facs_ctrl_EyeLookUpLeft.dsf (and right)

anyway Thomas may check, actually these 4 morphs not generate raw and fin prop even though there are dsf file with the name.

Once generate it, I suppose it is not difficult add on set driver correctly as same as before.

[engetudouiti]

After Thomas generate those 4 hidden morphs as raw and fin props, then if it still not work,, I may offer each driven expression for related morphs about this issue.

[engetudouiti]

And for UI controller, there are 4 almost same name morphs. they are not hidden morphs so we controll those value from UI (daz and blender)

facs_jnt_EyeLookUpLeft / Right

facs_jnt_EyeLookDownLeft / Right

but these 4 props are not same as hidden props which add on failed to generate props.

[Alessandro Padovani]

Thank you Engetudouiti for looking into this. Just in case, tested latest commit b6a195c and still doesn’t work.

[engetudouiti]

Yes I test it with the commit, Thomas do not notice this issue.

I am now trying to find when it worked, we actually talked about how manage facs_ctrl_EyeLookInLeft /Right and facs_ctrl_EyeLookOutLeft /Right

then they worked, so bascially facs_ctrl_EyeLookUpLeft.dsf (and right)

facs_ctrl_EyeLookDownLeft.dsf had worked. I suppose.

those 4 property need to be generated, because they are morphs which eye bone rotation directly drive. (so without it, it never work or if Thomas include those process,, internaly , it may need not… but new morph system should generate all props at least Fin.

I can guess related commits, but maybe Thomas easy find why add on not generate only about those 4 props.. after that if it is difficult to detect ERC, I may describe all steps. (it is easy enough),, then may know why add on miss them. (or if there remain new problem, when import base Facs)

I remember check almost all Fact morphs one by one, then I confrimed once all props we controll in daz studio worked. (with complex multipler too)

THen do not know, which commit cause this issue .

[engetudouiti]

I expected if recent commit may solve issue, but not.. It still not generate

facs_ctrl_EyeLookUpLeft.dsf (Right)

facs_ctrl_EyeLookDownLeft.dsf (Right)

as ob,data.props(fin) and ob.props(raw) with 2ab21dc

these hidden controller fin value will drive other morphs and eyelids pose bones.

‌

[Thomas Larsson]

The problem had to do with the UI when loading morphs. In order to keep the dialog size manageable, the first part of the file names were stripped off. However, this means that if two different files have the same stripped names, only one of them was loaded. In this case both facs_ctrl_EyeLookUpLeft and facs_jnt_EyeLookUpLeft have the same stripped names (EyeLookUpLeft), and only the jnt file was loaded. The fix consists of stripping off less, which you see when you load facs morphs next time. Note that you must make sure that the json files are updated.

OK, so that was the easy part. Unfortunately, we now get those nasty dependency loops again when loading the facs morphs for G81F. I have never really understood exactly how they are triggered.

[engetudouiti]

maybe rew commit will solve issue. (I supposed the facs_jnt_EyeLookUpLeft / Right

facs_jnt_EyeLookDownLeft / Right

may cause trouble.. (same label name is used when import morphs, then add on exclude I felt) NO? ><; ? sorry I check again (did not read Thomas reply..

About dependency loop,, I had thought it only happen, if same prop A drive prop B >>> prop C >>>. prop F drive prop A only…

now we devide all morphs as raw, rest, fin,, then fin values are only included in other props driver… but if prop drive pose bone transform,, and it mix with prop drive prop,, I suppose if it cause dependency loop without intention….

because we do not and can not drive fin bone directly like props. but we use mix fin transform value, when it drive other props…

I may check again,, actually which section cause dependency loop..(do not know if we can solve it or not,,)

[Alessandro Padovani]

Commit 918649b seems to work fine here.

‌

As for the daz names, I’d avoid stripping them, also for clarity to the user. Then, as I understand it, daz is using label + name + id, where id is used for expressions, name for file names, and label for the user interface. I’d suggest to follow the same rules, it may seem cumbersome but stripping names is always a risk. We may use id or name instead of label but it’s not nice for the daz user who is used to labels.

I’ll keep this one open or mark as resolved if you want to open another discussion for dependencies.

[Thomas Larsson]

Here is one of the dependency loops:

 Dependency cycle detected:
  OBGenesis 8.1 Female/Parameters Component/ID_PROPERTY(Rot:2:01) depends on
  OBGenesis 8.1 Female/Parameters Component/DRIVER(pose.bones["rEyelidLowerInner"]["Rot:2:01"]) via 'Driver -> Driven Property'
  ARGenesis 8.1 Female/Parameters Component/ID_PROPERTY(facs_jnt_EyeLookDownRight(fin)) via 'RNA Target -> Driver'
  ARGenesis 8.1 Female/Parameters Component/DRIVER(["facs_jnt_EyeLookDownRight(fin)"]) via 'Driver -> Driven Property'
  ARGenesis 8.1 Female/Parameters Component/ID_PROPERTY(facs_ctrl_EyeLookDownRight(fin)) via 'RNA Target -> Driver'
  ARGenesis 8.1 Female/Parameters Component/DRIVER(["facs_ctrl_EyeLookDownRight(fin)"]) via 'Driver -> Driven Property'
  OBGenesis 8.1 Female/rEye/BONE_DONE() via 'Bone Target -> Driver'
  OBGenesis 8.1 Female/rEye/BONE_READY() via 'Ready -> Done'
  OBGenesis 8.1 Female/rEye/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBGenesis 8.1 Female/rEye/BONE_POSE_PARENT() via 'Pose -> Constraints Stack'
  OBGenesis 8.1 Female/rEye/BONE_LOCAL() via 'Bone Local - Bone Pose'
  OBGenesis 8.1 Female/Parameters Component/DRIVER(pose.bones["rEye"].rotation_euler) via 'Driver -> Driven Property'
  OBGenesis 8.1 Female/Parameters Component/ID_PROPERTY(Rot:2:01) via 'RNA Target -> Driver'

‌

[engetudouiti]

Yes so now I am thinking which step (hieralchy) cause this issue.. (maybe mix copy constrain to get rotation ^^; happend to cause dependency loop I feel…) so now try to follow each ERC, when we pose eye bone, or use

Eye look side-side (or up down), how ERC work, about each hieralchy.

when import All Facs Unit it show 10 cycles for me all related with Eye.. , (but still do not know clear,, actually we loop some prop or bone transform or not…by driver, parent relation, and constrain,, not clear for me..

[Thomas Larsson]

Blender isn’t complaining anymore. Apparently it didn’t like driving several properties with the same name, even if the properties belong to different bones. When I added the bone name to the property name, Blender became silent. So somehow Blender confuses Rot:2:01 (lEye) with Rot:2:01 (lEyelidUpper). When the variable names are changed to lEye:Rot:2:01 (lEye) and lEyelidUpper:Rot:2:01 (lEyelidUpper), the loops go away. Weird.

Since the intermediate properties now have names that include the bone names, I will move them from the posebones to the armature. That will admittedly display more drivers in the driver editor, but it will also clean up the code since the rest drivers can use the same code.

[engetudouiti]

I actually experienced some infinit freeze,, after you make add on import facs_jnt_EyeLookUpLeft / Right with dependency loop… when I pose eye around bone, then use ctrl z,, so I may try with new commit.

(I expect new naming way may solve the issue too.. )

[engetudouiti]

Yes now all eye related morphs ERC correctly working I feel

[Alessandro Padovani]

I’d like to hear if @xin has some explanation for dependencies. It sounds as the variables are global so not local to the bones. Then if there’s nothing to add I’d mark as resolved.

‌

[Thomas Larsson]

My understanding is that the posebone type is somewhat half-baked. On the one hand it supports id-properties, so different posebones can have properties with the same name and they are distinct. OTOH a posebone is not a data type that supports drivers natively like objects or armatures. In drivers, the target id is the rig object, and we access the individual posebones through the data path ‘pose.bones[“bonename”]’.

Anyway, that is my understanding of what is going on, although I probably don’t use the appropriate nomenclature, and I also would appreciate if Xin would chime in. But including the bone name in the property names seems to be a simple way to create unique property names across the armature, and I see no harm in it.

‌

[Xin]

I found this problem too in the past, and it was related to names only too. It was a very simple example where no real dependency cycle existed. I don’t know why Blender behaves like that, but I would guess it’s related to the way it keeps tracks of dependencies.

As a rule of thumb, real dependency cycles usually cause noticeable FPS drops.