Stop import Custom morph when driven prop driver expression reach 255 with info or solve limit problem

[engetudouiti]

So we actually have limit length for driven morph expression, and after all it should cause issue, when user import many custom morph (which drive already imported morph property) then unitll solve it I think error handling need for this particular issue.

I suppose Thomas can check current expression length for each props, then when import new morphs, untill overwrite or re-generate the driver expression, check it and if it come to limit 255, Stop to edit driver. at same time if add on generate Controller slider, and property, remove them. (then only remain new controller props (raw and fin) and slider, it not break other morphs)

and show info in console. if you can.

===

Then the blender driver expression limit remain as separate problem of import morphs. So may keep this topic only for expression limit problem and way to manage and solve it. Same thing should happen for any generation figure and custom morphs which drive other morph value.

[engetudouiti]

a1885f6 commit now show info when import custom morphs, and tell which morph driver may over limit.

like this…

‌

But it simply cancel all process to import selected morphs which I selected as one group (usually vendor directory)

Ideally, add on generate props and edit driver until it cause limit issue… (so all other morphs remain as new custom morph, then it may edit already imported morph driver expression, without limit issue)

Then there should be morphs which add on stop to import. (then show them as info or console report)

Or at least show the problem morph names which may cause issue (the morphs will drive those properties then may cause issue if import all selected morphs) , so I can avoid those morphs from selection, next time…

I do not think, all my selected morph may drive these 2 props.. (though I do not confrim it,,)

At current the info not tell which morph (I selected) may cause limit issue, but only tell which morph driver (they already improted) may cause issue when add on import all selected morphs.

(so the infomation can not be used to decide selection when next import to avoid limit) Though now it never break already imported morph driver,, (so actually improved as error handling)

[engetudouiti]

Then it seems show un-expected behavor,, if I try to import custom morph but this time only select 4 or 5 expression driver morphs.

Now add on generate all morphs slider which I selected before. (but not select this time) do not know if it work or not at all.. (if it keep driver correctly, it should cause limit issue,, if not so,, some morphs may not drive those problem morph, and I do not know which morph was generated (as incomplete driver)

I suppose,, add on did not remove those prop when I first import (select all morph of package) >> show error >> not generate any slider. but keep those data of props still..

Then when I next import,, with change selection to avoid limit problem,, this time add on generate slider and morphs which excluded with current selection as incomplete morphs.

[engetudouiti]

I could confirm,, add on remain all props (raw and fin) when I first tried to import custom morphs >> show error info,(which cause limit issue for some property), and not generate any slider..

If you do not generate slider ,, it should not remain those props (raw and fin) about imported morphs.

it you generate slider,, it should remain those props, and all drivers need to work. At current error handling cause problem.

Then I feel the behavor looks like this small error

https://bitbucket.org/Diffeomorphic/import_daz/issues/420/import-custom-morph-custom-pbm-edit-bone

add on may show un-expected behavor, with error info.. not clean cancel steps.. if there is no custom morph category . I feel.

maybe the behavor, change,, if I import some custom morph first without error, and try to import new morphs which may cause limit issue. (though I do not test them)

‌

[engetudouiti]

To reproduce issue

1. import g3 or g7 then import default morphs
2. import custom morphs (product package) as bunch of morphs (you may select most of all) which should cause limit issue (like Z morphs package)
3. add on show info (some property expression too long..) then not generate any new morph slider as if it clean cancel
4. but add on remain all generated props (raw and fin) and the raw and fin prop driver still work as morph (so it actually change face unit values and deform) . I do not know those props are complete one or it may remain problem (because there should be some prop which cause limit issue add on informed )

Then if I re-try to import same morphs, but this time only select one or two to avoid limit issue, add on suddenly generate all slider… those behavor really un-stable as real usage… I feel.. (because user do not know which morph may imported correctly or not at all)

[Thomas Larsson]

This should be solved now. If there are more than four variables that drive a given property, we add intermediate properties and a sum driver for the excess variables. This should allow for arbirary many driving properties, without complicating things in the usual case when we only have a few variables.

[engetudouiti]

Thomas I think the commit should be good first try. At same time there is case it not work well.

I test Z morphs with G3 .

Z morphs only drive Face units. then I separate 2 steps to Import Z morphs.. like this

Making morphs

• Z FI Focused
• Z FI Grieving
• Z FI Growl
• Z FI Hurt
• Z FI Pain Cry
• Z FI Playful
• Z FI Pouting
• Z FI Ready
• Z FI Sadness
• Z FI Serious
• Z FI Unimpressed
• Z FI War Cry
• Z Fi Viscious
  Making missing morphs
  . ctrlcheeksdimplecreasehd.dsf
  . ectrlbrowinnerup-down.dsf
  . ectrlbrowouterup-down.dsf
  . ectrlbrowouterup-downl.dsf
  . ectrlbrowsqueeze.dsf
  . ectrlbrowup-down.dsf
  . ectrlcheekcrease.dsf
  . ectrlcheekeyeflex.dsf
  . ectrlcheekflex.dsf
  . ectrleyelidslowerupdown.dsf
  . ectrleyelidsupperdownup.dsf
  . ectrleyesclosed.dsf
  . ectrleyessquint.dsf
  . ectrljawout-in.dsf
  . ectrljawside-side.dsf
  . ectrllipbottomin-out.dsf
  . ectrllipbottomup-down.dsf
  . ectrllipbottomup-downl.dsf
  . ectrllipbottomup-downr.dsf
  . ectrllipspart.dsf
  . ectrllipspucker.dsf
  . ectrlliptopin-out.dsf
  . ectrlliptopup-down.dsf
  . ectrlliptopup-downl.dsf
  . ectrlliptopup-downr.dsf
  . ectrlmouthcornerback.dsf
  . ectrlmouthcornerup-down.dsf
  . ectrlmouthfrown.dsf
  . ectrlmouthnarrow.dsf
  . ectrlmouthopen.dsf
  . ectrlmouthopenwide.dsf
  . ectrlmouthsmileopen.dsf
  . ectrlnosescrunch.dsf
  . ectrlnosewrinkle.dsf
  . ectrlnostrilsflare.dsf
  Building drivers
  Building sum drivers
  Building rest drivers
  Folder I:\myfile\dazstudio4\Mylibrary\data\DAZ 3D\Genesis 3\Female\Morphs\Zeddicuss\Z Fighter loaded in 6.058 seconds
  File paths cleared
  File paths cleared
  Making morphs
• Z FI Angry Shout
• Z FI Attack Cry
• Z FI Cheeky Smile Right
• Z FI Concerned
• Z FI Contemplating
• Z FI Crazy
• Z FI Crying
• Z FI Dangerous Smile
• Z FI Determined
• Z FI Disappointed
• Z FI Disgusted
• Z FI Emotional
  Making missing morphs
  . ctrlcheeksdimplecreasehd.dsf
  . ectrlbrowinnerup-down.dsf
  . ectrlbrowouterup-down.dsf
  . ectrlbrowsqueeze.dsf
  . ectrlbrowup-down.dsf
  . ectrlcheekcrease.dsf
  . ectrlcheekeyeflex.dsf
  . ectrlcheekflex.dsf
  . ectrleyelidslowerupdown.dsf
  . ectrleyelidsupperdownup.dsf
  . ectrleyessquint.dsf
  . ectrljawout-in.dsf
  . ectrljawside-side.dsf
  . ectrllipbottomin-out.dsf
  . ectrllipbottomin-outl.dsf
  . ectrllipbottomin-outr.dsf
  . ectrllipbottomup-down.dsf
  . ectrllipspart.dsf
  . ectrllipspartcenter.dsf
  . ectrllipspucker.dsf
  . ectrlliptopin-out.dsf
  . ectrlliptopin-outl.dsf
  . ectrlliptopin-outr.dsf
  . ectrlliptopup-down.dsf
  . ectrlmouthcornerback.dsf
  . ectrlmouthcornerup-down.dsf
  . ectrlmouthnarrow.dsf
  . ectrlmouthopen.dsf
  . ectrlmouthopenwide.dsf
  . ectrlmouthside-side.dsf
  . ectrlmouthsmileopen.dsf
  . ectrlmouthsmilesimplel.dsf
  . ectrlmouthsmilesimpler.dsf
  . ectrlnosescrunch.dsf
  . ectrlnosewrinkle.dsf
  . ectrlnostrilsflare.dsf
  . ectrltonguein-out.dsf
  . ectrltongueraise-lower.dsf
  Building drivers
  Building sum drivers
  Building rest drivers

it seems generate in-complete morphs which I import later as same category.

eg I install 15 morphs first, then import another 2nd time as same category.

then I found there is only 15 morphs for eCTRLBrowInnerUp-Down(rst)_XXX

then Z FI Angry Shout or others which I import 2nd time not have rts even though It drive eCTRLBrowInnerUp-Down. then do not controll eye around bones at all. (angry should controll eye bones too)

And I hope to know,, how you change each eCTRLBrowInnerUp-Down(rst)_XXX value? I suppose each (rst)_XXXX value should be each “controller value * step value” then you gather them (Sum) as Rest. = eCTRLBrowInnerUp-Down(rst)

But those prop eCTRLBrowInnerUp-Down(rst)_XXX not have dirver (driven prop will turn purple but the prop not set any driver) but it seems auto change value with controller value. So if you can drive those prop without driver? ^^; ? (or something hidden from UI?)

But I can found those driver in driver editor,, so I suppose you intend to hide driver from prop..

‌

In armature property editor, it shown as non driver.. (do not know if it is bug, or you set so in code,,)

‌

Though it make no difference for me,, but I though if I can change those value too.. (actually it seems driven so I can not change the prop value)

And If you do not use number, for each prop, I think I can more easy check,, how each drive change or not when I found poblem.

eg, ,at current you set prop name as eCTRLBrowInnerUp-Down(rst)_005

but I suppose the 005 should represent controller so if you use controller name like eCTRLBrowInnerUp-Down(rst)_Zangry

it make more easy to check how each value change with controller (so if it failed I can easy detect problem) (of course if it work perfectly I need not check those value , so it is only problem to detect bug or corrutepd driver)

[Thomas Larsson]

Re: naming convention. I first tried with the naming convention that you suggested, but got errors because Blender properties can not be longer than 64 characters. But I can change to a hybrid convention for testing, though.

[Thomas Larsson]

Better names implemented.

[engetudouiti]

OK thanks, Of course after you confirm it work crrectly, it is not problem (or I feel even better than set such long prop name) at all, so anytime you return it when you need. I did not think blender have limit for prop name too ^^;

What I found is, if I do not import all package of z morph, I suppose add on can not set those rst XXX prop for new installed morphs. So if those prop can show for which controller , you may clear see, those are not generated . I can suppose reason, add on may try to avoid generate same controller (because they are generated when I install first), but it need to up-date for 2nd import morphs. But to work 2nd import morphs,, it now need to add each rst XXXX prop (2nd import morph drive ) for same face unit. but add on do not generate them, then only remain rst XXX props which driven by Ist import morphs only. Some rst XXX props which driven by 2nd improt controller seems only generate Face unit which may not driven 1st import moprhs?

Can you test same thing ? (same thing may happen for G8 too,, if you devide step to import custom morph package (which drive facs units) as 2 or 3 step..

[engetudouiti]

Thanks the way now I clear find what is wrong. There is case,, RST (rest) not add new variable,

I import Z morphs, Z FI Angry Shout as 2nd import custom morphs. then add on correctly generate new RST props for driven Face unit , ECTRLEyelidsLowerUpDown_Z FI Angry Shout then the value correctly driven by Z FI Angry Shout it is correc.

then if it work correctly, ECTRLEyelidsLowerUpDown(rst) add the ECTRLEyelidsLowerUpDown_Z FI Angry Shout as new driver variable. But add on fail to add ECTRLEyelidsLowerUpDown_Z FI Angry Shout as new variable for the ECTRLEyelidsLowerUpDown(rst) expression.

you can see this pic, I only change Z FI Angry Shout as 1.00 , then it will multiple with step value, so

ECTRLEyelidsLowerUpDown_Z FI Angry Shout = 0.337

‌

But ECTRLEyelidsLowerUpDown = 0.00

Because the driver not added ECTRLEyelidsLowerUpDown_Z FI Angry Shout as new variable of ECTRLEyelidsLowerUpDown(rst)

[engetudouiti]

Then above the case add on generate 18 ECTRLEyelidsLowerUpDown_Z FI expressions as step value mutlipled property. by 2 times import.

Then ECTRLEyelidsLowerUpDown_Z should have those 18 props as driver variables to get Sum.

But ECTRLEyelidsLowerUpDown(rst) only have t001 to t012 variable as their expression. 2nd time improted Z morphs only generate multipled prop. but not added as sum. Only Z morphs which I imported as 1st time, they are added in ECTRLEyelidsLowerUpDown(rst) driver variables.

Then I suppose it maybe related with your way, “If there are more than four variables that drive a given property, we add intermediate properties and a sum driver for the excess variables”

I think it usually work, but when you need to re-generate driver variables, (remove morphs or import new morphs which drive same Face unit) , there is case add on fail.

I found some morphs. it mix use Rest and old style Morph name * step value in one expression.

idally,, all morph may better to use same structure,, Fin = (Raw + Rest) . at current some morph Fin = (Raw + b*0.568 +Rest)

then it maybe cause issue,, when it need to edit. (add or remove) ..Though I still not test when I remove a few Z morphs, add on can generate driver expression of those Face unit correctly.

==
At same time I feel, you almost solve these compex problem.. you only need to adjust some exceptional case… then to manage those case,, I think even though you do not hope to add un-necessary rst props,, you may better keep to use same Format for all morphs.. as Fin = raw or Fin = raw + Rest,(driven values SUM part)

Then it make easy when you need to add 2nd multiple expresssion. Fin = (raw + Rest)* 2nd stage multiplers

I think you should avoid expression like Fin = raw + morphA *step value anymore…

Then you can concentrate how edit Rest when we import new morphs or remove morphs. (do not needto worry about morphA section,, it should be included in Rest.

[engetudouiti]

And it is just for future problem I now worry about,,,

, at current you use “_” to set res prop names. as (driven prop)_(controller prop)

I suppose there is case you may need to get driven prop and controller prop name,, to manage remove morph etc,,

I do not know if Daz have rule to set dsf name, but I think there is case the dsf include “_” as ID or file name many times.

(I often use “_” it for dsf name, or morph ID like head_move_myname. dsf etc ^^;) so I am afraid if it will cause new issue.. (if you already find way to controll strings pefectly, (you can easy devide, the driven prop name and contrloller prop name, even though dsf name include multiple “_” when you need them,,,, ignore this please)

Though I can not say which separator never be used for dsf file name,, and it work without problem…

‌

[engetudouiti]

Then now you decide to use ID prop then represent each “rest” varialbes as armature[“Morphname_CtrlName”] so I know you do not need to use collection props, (actually I thought use ID prop should be more easy and maybe stable as driver)

At same time, I have thought to use collection property as one option,, then generate hieralchy collection props to achive same thing.., like this

ob.data["ctrlEyeBone_res"] driver is,,

driver = Sum type

t001 = daz_morphs["ctrlEyeBone"].drvs["Z suprised"].value

t002 = daz_morphs["ctrlEyeBone"].drvs["Z angry"].value

……

it have some merit..

(eg you easy get how many drivers drive [ctrlEyeBone] as

len(rig.data.daz_morphs[“ctrlEyeBone”].drvs)

and you can get those driver names by rig.data.daz_morphs[“ctrlEyeBone”].drvs.keys() , it can use the controller name directly to get value without check the mix string,, then when we need to manage res props. I think it is more stable. Of course I suppose it cause more difficulity when you generate those props with import morphs than ID props , maybe add or remove is more easy.. with check current drvs collection props for each morphs.

I only do simple test it seems drive prop correctly, with use each drv[“name”].value ,, if there is case, it seems useful to manage each props,, and if it not so diffiult for you to generate “controller prop value *step value” as Collection propertys. like drvs[“controller name”] I hope you consider it as one option, if there is case you can not make it work well with current ID prop way. of course it is just option, if current way can not manage complex thing and I expect current ID prop work well. (actually I know it already work,, so only remain tine problems,, when we need to overwrite , add, remove those props)

‌

[Thomas Larsson]

In the last commit the rest variables have been grouped into batches as in #461, for the same reasons and reusing the same code. Unfortunately, the variable names are changed back into numbers, since each batch contains several properties.

[engetudouiti]

As I said if it can import morphs correctly, it seems not problem how you generate drivers.

Though I afraid if it make difficult to manage drivers (remove or add new ) each prop later once several props are gathered.

If you can still manage each prop (remove or add props correctly and re-build driver) after import one csutom morph gorups, and generate drier, it is not problem. (though It make more time to detect props problem when it happend)

Anyway test later, if it solve this issue too.

‌

[engetudouiti]

OK at first, I like the way too.

it actually solve corrupted morphs which I 2nd time import about Z morphs . Then improved.

The good thing for me is,, it can re-order props with alphabet about each Rst:01 02 03 …

Then I test remove some custom morphs which drive face units, with selection and find 2 problems.

I first check how each Rst 01 02 03 change… it seems correctly removed props and variables in each Rst:number though Rst : number change. (now some Rst section start as Rst:02 or Rst03,, but it seems not heavy issue. though I have interesting, if I re-import some morphs, how Rst number change..

Then problem are

1 when I remove some imported Z morphs,, it now hide all Custom group slider from UI, as if all morphs removed. (but remain as csutom prop so I can change morph with custom prop (not add on UI )

2 It remain fin props which I removed. (but driver are revemod correctly)

I only use one category, then import / remove morphs. (if these 2 issues are solved, I may test with use multiple user defined category.

[engetudouiti]

Yes I think, this issue is solved. so there remain how up-date props and UI slider correctly, but how manage limit string for expression seems clear now. by you devide “sum part” as Rest first, now I think all import fin morphs driver expression becom clean enough. and there seems no exceptional case.

So I set this as sloved. (no limit issue any more) then may make new topic for up-date . (remove morph, category , etc)