FACS impot issues (import file and set drier of "FACS" directory)

[engetudouiti]

I really suprise everytime how daz announce their improvement, with special words (I think DAZ is one of best company how use word to appeal their product,,)

but after all to import FACS, at least with I check ERC of new 8.1 expression controllers, it just mix shape key morph with bone controller at same time with one controller. it is all.

(actually it is not new techinic at all ^^; I have such product with genesis 3.. expression morph product, it do same thing

A. move facial bones + B correct or add new morph which vendor may hope to add

The real word meaning FACS is, how human face musle work with each expression (I suppose) with sychological data.

so Daz may get kind of template, with each expression, then try to mimic it with shape morph + bone weight defomation. it is all. Yes I sometimes genesis3 or 8 expression not what I feel with the label.. so I often make new facial morph or custom face bone controller. Anyway,, my intention is how it can be used in this add on.

I think Thomas make it work with recent commit, that means we can import those mix type controller. , (not only FACS) , which drive pose bones + add new shape key morphs, when user custom made, or vendor offered as expression?

‌

[Thomas Larsson]

https://diffeomorphic.blogspot.com/2021/01/facs.html

[engetudouiti]

Thanks new doucments. Then I could understand (but partially), now you offer option which we can choose “add sub-component shape keys or not” when we import one controller for pose bone controller.

I actually feel your morph conversion way is really reasonable for blender,, how mix shape keys when it need. Then just confirm, this case please. then if there is something different, correct it..

I make “FacsXXX” Expression in daz.. this FACS mimic Expression controller do these 2 things. (Of course It is not real FACS, but make it as best simple case which add on will import correctly)

A. it change BsFacsXXX and pctrFacsXXX

B. BsFacsXXX is daz usuall shape morphs (shape key style) which we may use morph loader to generate controller.

C. pctrFacsXXX is daz usuall pose controller (move Facial pose bones as “pose controller”) which we may use Erc freeze. (or manually set up ERC)

To make it in daz studio, I need to generate 3 dsf files. FacsXXX.dsf, BsFacsXXX.dsf, and pctrFacsXXX.dsf. Then I may import those 3 dsf, as Custom Morphs. I check all 3 files in your offer UI import option, with use new option (Combine Multiple Shape keys) + add rig-driver.

when we import “morph” to blender, add on generate new UI controller for blender, now I call it as “UserController” to discribe clear. what your add on will do (I expect so)

=====================

1_ When import BsFacsXXX.dsf,, add on generate new “Shape key” BsFacsXXX , then generate BsFacs XXX as User controller.

2_ When import pctrFacsXXX.dsf, add on generate new User controller , pctrFacsXXX , Daz Importer should change related bones transform value expression. ,by add pctrFacsCustom value.

to make FacsXXX controller ,, DS need not generate new morph data.. it can re-use BsFacsXXX.dsf data , for FacsXXX But in Blender we can not do it.. then when import add on will do

3_ When import FacsXXX.dsf, generate new “Shape key”,, named as FacsXXX, at same time it change related bones transform value expression. by add FacsXXX value.

=====================

In Blender shape key, panell, we may get 2 new Shape keys, as driven. But if you made ERC step value as 1.00, basically BsFacsXXX and FacsXXX are perfectly same data.. but we need it.

One thing user may need to know,,

when import any morphs which need to drive vertex as shape morph, Daz importer need to generate new shape keys for each User Controller.

So if we made FacsXXX2 , FacsXXX3 which change BsFacxXXX as 1.00 with other pose controll, add on make perfectly same shape key data, as FacsXXX2, and FacsXXX3.. but it must need to keep all morphs work. (without it we can not move each morph individually)

(so it is current blender shape key and driver limit, as same as pose bone transform value and driver,)

[engetudouiti]

Then I still not confirm, add on do same things I describe above..so if it is wrong (step 3) I hope Thomas correct it.

If add on actually do those things what I describe above. As long long term future request,

add on will change shape key driver expression, when we import new Mix type morph which drive same shape key data we imported before,, not generate new shape key, but change expression of shape key driver, as same as you already do it for pose bones drives expression. I think Thomas understand what I means.

‌

[engetudouiti]

Thomas could you confirm current add on FACS options can import and set driver correctly for all dsf (daz morph) files of FACS and FACS expression?

I directly use dsf files name, FACS dsf are grouped as 2 in directory, One is FACS the other is FACSExpressions. Now check FACS directory first. there are many dsf but, basically it labelled as 4type. we only tweak 3 types with controller, last type is corrective morphs (like jcm)

1 facs_bs (OK)

they are vertex morphs with change edit bone transform values. plug in can not manage zero pose transform, so I ignore the edit bone transform. then only vertex morph is matter. then plug in can import them as shape key without problem. plug in generate UI controller. and drive those shape keys.

2 facs_jnt (OK)

they are facial pose bone controller. they do not include vertex morph data. but include pose bone transform (rotation etc). then plug in generate UI controller and drive each pose bone (as same as default facial morphs)

3 facs_ctrl (partially OK?)

They are mix type controller.. most of them drive facs_bs values. additionary some of them drive pose bones as same as facs_int.

4 facs_cbs (?)

They are mcm type hidden morphs. they include vertex morph data, and they will be driven by other 3 type controllers (above) _bs, _ jnt, _ctrl values.

those MCM should be most difficult type morphs which add on manage. I suppose. eg if you pick up, facs_cbs_EBL_ELDL_div2.dsf you may see these formula.

            "group" : "/Hidden/FACS/Fixes",
            "formulas" : [
                {
                    "output" : "Genesis8_1Female:#facs_cbs_EBLxELDL_div2?value",
                    "stage" : "mult",
                    "operations" : [
                        { "op" : "push", "url" : "Genesis8_1Female:/data/Daz%203D/Genesis%208/Female%208_1/Morphs/Daz%203D/FACS/facs_jnt_EyeLookDownLeft.dsf#facs_jnt_EyeLookDownLeft?value" }
                    ]
                },
                {
                    "output" : "Genesis8_1Female:#facs_cbs_EBLxELDL_div2?value",
                    "operations" : [
                        { "op" : "push", "url" : "Genesis8_1Female:/data/Daz%203D/Genesis%208/Female%208_1/Morphs/Daz%203D/FACS/facs_jnt_EyeBlinkLeft.dsf#facs_jnt_EyeBlinkLeft?value" },
                        { "op" : "push", "val" : 1 },
                        { "op" : "mult" }
                    ]
                }

If I manually set up it in blender,, I need to generate this _cbs shape keys. and need to set 2 driver target. as facs_jnt_EyeBlinkLeft and facs_jnt_EyeLookDownLeft, then discribe expression for the driver. Plug in already manage them without problem?

[engetudouiti]

So I actually test how add on import FACS UNITS, it seems not generate any facs_cbs morphs as shape keys.

eg about the facs_cbs_EBL_ELDL_div2.dsf, this morph value need to change and auto applied when EyeBlinkLeft and EyeLookDownLeft change value. but I can not find any shape key, which seems driven by those 2 FACS Units controller.

Thomas I recommend you check those facs_cbs dsf files >> operator section. You might not notice those facs_cbs morphs are actually used to get FACS units correctly (modify)

[Thomas Larsson]

I didn’t understand what the facs_cbs files were good for, so they weren’t loaded. They are now. However, they do not controlled by the same property as the jnt file, because the jnt file has no reference to the cbs file, which is sort of backwards. A similar situation appeared for some ordinary face morphs, but in the case they contained no morph at all, so we could tell that something went wrong and try again later. The facs_jnt files do load a morph, even if it is without the correction.

Note that the fix requires that the json file is updated too. I don’t really understand the updater (its not my code) and use git instead, but I think there was some trouble telling it to update json files. The updater uses json files to store its own data, and something went wrong when I told it to update such files too.

[engetudouiti]

because the jnt file has no reference to the cbs file,

As you said those relation (ERC operators in dsf) are written in driven file, not controller file about this case.

In ds we can choose in which file we discribe the reference(ERC) , between driver(controller) file and driven-flie(sub-component) when we make ERC (driver) . if you open property hieralchy , you may see each controller or subcomponent ERC have option “save as”. it is option to decide which file we use to discribe the reference. (controller or sub-component).

I do not understand the all reason, but it make user remove or add morph product without see strange error. (when there is no sub-component file,, ds may complain etc)

On the other hand, in blender we describe driver expression in driven property only in blender.. (so when we check controller (driver property) we can not find any reference. and user do not know the prop is driver or not.

To catch those backward reference, I think we need to check each file formulas section “ formula[n] /output “

one by one.

if the output = the self file morph value, the formula (ERC) is to move self file morph value.

if not the formula move another morph or bone etc.

===

About up-dater , actually I do not know if it only happend for my pc, = maybe I edit the up-dater setting file before,,, then did not up-dated correctly,) anyway, now I understand those data/ json need to check when I use auto-up-dater. I did not notice it is used to import morphs.

[engetudouiti]

OK I may report here about Fact directory dsf files only (not include Facs Expression) because I suppose there seems remain quite a few issue, to it work correctly .

I basically hope , correct all ERC related issue, at once but, it seems difficult untill Thomas will find way which can set driver or mix shape key, for all type ERC. So I may prefer one by one aploach.

About recent commits, add on import _cbs files as shape key, and generate same name _cbs controller.(as temp solution) but we know it not what daz do. those cbs need not UI controller. (we do not have jcm UI controller, same reason), , but they need to be driven with other controllers

Then Thomas what may help you, to solve or partirally improve this cbs driver issue? I can check each _cbs file formula. and can offer what controller (and files) may drive each _cbs, with expresison, but I do not know, it may help to add on auto import process. So if you discribe what you need,, I may offer when I could,.

(but I can not help to modify script , actually the process is too complex for me, so still do not clear understand how your script set expressions,,, for complex ERC, pirtailly understand, you seems generate controller file first, then try to generate related shape keys when you catch it.

[engetudouiti]

I now get new idea which may improve and manage daz parameters (which related with user modify pose and shape)

About daz, when you have file in data/../morphs/

all dsf files may generate controller. then only User controll parameter, they try to show them in UI, so actually all jcm mcm (like these _cbs) have individual controller. in parameter section, but with “hidden” option.

So do not do same things for this add on? eg at current this add on never generate jcm controller. but ds actually generate them for each _jcm dsf files. but set them as hidden.

As add on,, you may make new category for those . “hidden morphs” then it can be closed (as default). so we can set driver for each controller as same as DS way.. at current we need to use each shape key to set driver. now you happend to generate _cbs controllers which drive _cbs shape keys.. so I may prefer group them as hidden, and closed as default. (then when user need to edit it or set driver, user open it )

You can check it, in each dsf (in morph directory) modifer_library>channel>visible value. when it is false, ds set them as hidden property. then it only be shown when user set “show hidden properties”

As start point, lets do it for genesis FACS morphs first.

Or I may prefer, not generate controller (but just import as shape keys,) for those “hidden” cotroller. because they are not user tweak controller. You make it so about JCM,, but this time (temporally?) you generate MCM controller with import shape keys…we may better keep same pinrciple,, when generate controller or not, about _cbs,, it should be hidden morphs. (same as JCM morphs)

‌

‌

[Thomas Larsson]

The cbs morphs are now invisible and follow the control morph. It is not a general solution, but seems to work with the standard FACS units because the morphs are loaded in the right order.

Also, most morph sliders now show the same text as in DS, because their labels are used instead of their names.

[engetudouiti]

I may wait untill Thomas show plan how you think. (keep to generate _cbs controller, or not,)

About FACS morphs I do not expect, it work well. I suppose Thomas already confirm those CBS need to set driver. or user everytime manually set value when we add facial unit pose. (Though now we can use CBS morphs which deform mesh = they are now improted with driver)

after you decide it, I might report about each controller , or shape keys, driver expression. (there are some interesting controller in FACS, like facs_ctrl_EyeLookAuto.dsf (boolean switch), which may change eye bone and eye lids bone move at same time or not, for eye pose controllers. (if add on can manage all these FACS morphs ERC, I may expect most of ERC daz morphs may be imported without problem ^^; so even though I may not use genesis8, I hope add on improve gradually to manage daz ERC.

‌

[engetudouiti]

Ah thanks, now I can keep test, and report again. (you seems keep improve about this issue, I did not notice recent update ^^;)

[engetudouiti]

Ok I discribe first one which you may improve. (Solved)

facs_ctrl_EyeWide.dsf (EyeWide) is controller which open both eye wide. then in ds it simply drive facs_jnt_EyesWideLeft and facs_jnt_EyesWideRight by ERC. (ratio is 1.0 to 1.0)

in blender, at current 2 Right and Left eyewide jnt controller already work (it can drive cbs shape keys too). without problem.

then facs_ctrl_EyeWide drive pose bones, without use 2 _jnt controller value. it is OK. then only problem is, it need to drive

facs_cbs_EyeWideLeft_div2, and facs_cbs_EyeWideRight_div2 . I can confirm current add on not move those 2 shape keys, and not generate new mix _cbs shape key. So you now set driver for each _cbs controller,, you may need to choose way to solve this.

a. set expression for facs_cbs_EyeWideRight_div2, facs_cbs_EyeWideLeft_div2 which will be driven by facs_ctrl_EyeWide.dsf too.

(of course you need to keep driver for facs_jnt_EyesWideLeft, and facs_jnt_EyesWideRight of each cbs.

b. generate new mix shape key as facs_cbs_EyeWide by _cbsEyeWideRight and Left , after that generate new hidden morph as facs_cbs_EyeWide, and set driver for facs_ctrl_EyeWide (EyeWide)

which way you used (or think another way), after all you need to add “ facs_cbs_EyeWideLeft_div2(M) and facs_cbs_EyeWideRight_div2(M)” vertex delta when facs_ctrl_EyeWide (EyeWide) change value.

[engetudouiti]

2nd (Solved)

It is not critical for me, but to know current add on how generate driver, it seems good example. to generate driver I think.

In Daz studio, Mouth close = facs_bs_MouthClose_div2 , change vertex morph with change edit bone transform. At same time, this value is controlled by Jaw Open = facs_jnt_JawOpen , current Jaw Open value auto multipled with user set Mouth close value.

So if keep Jaw Open as 0.0, Mouth close never work. (keep as 0.0) . then to clear see how it work,,

1. Set Jaw open as 1.0,
2. Set Mouth close as 1.0
3. gradually change Jaw Open value. you may see Mouth close value are multipled with current Jaw Open value.

To get it work as same as daz, we may need to edit, facs_bs_MouthClose_div2 shape key driver expression. it need to be mulitpled with Jaw Open controller value. Then it may show same effect, when user mix use both parameter.

Then if you check the property hieralchy you may find, save with parameter like this

‌

if add on only check formula of controller files. as you said sort of backwards may happen, (though I do not know how add on catch all dsf morph files formula, when we load..

they do not controlled by the same property as the jnt file, because the jnt file has no reference to the cbs file, which is sort of backwards. 

about each ERC (driver),, it may change save with controller file or save with driven file when vendor generate ERC. about this case this formula not be shown in Controller (facs_jnt_jawOpen, so if add on only check Controller file formula,, those ERC may lost .

‌

[engetudouiti]

Then when plug in not generate driver, I suppose it usually 2nd stage ERC

(in dsf, it discribed as stage multi)

Dson formula only have 2 stage,, then when morph A (controller) multipled with morph B ( subcomponent)

it need to be discribed as 2nd stage. about the facs_bs_MouthClose_div2 , it discribed ERC of facs_jnt_JawOpen?value here.

So what I may expect is, plug in auto catch those 2nd multiple ERC s.

{
                    "output" : "Genesis8_1Female:#facs_bs_MouthClose_div2?value",
                    "stage" : "mult",
                    "operations" : [
                        { "op" : "push", "url" : "Genesis8_1Female:/data/Daz%203D/Genesis%208/Female%208_1/Morphs/DAZ%203D/FACS/facs_jnt_JawOpen.dsf#facs_jnt_JawOpen?value" }
                    ]
                }

All "sum" stages will be grouped and then multiplied by the "multiply" stages.

(sum(1)+sum(2)+sum(3)....+sum(n)) * mult(1) * mult(2) * mult(3) ... * mult(n)

https://www.daz3d.com/forums/discussion/6917/question-about-dson-file-format-formula-stage

by Kendall

But daz already offer one more type (key animation type) ERC, I do not know add on could read it or not.. (it sometimes used)

[engetudouiti]

3rd (Solved)

It seems looks like 2nd case. Some facs_cbs have same issue, then it is good example too.

you may find facs_cbs_MP_CPL_div2, facs_cbs_MP_CPR_div2, facs_cbs_MP_MC_div2,facs_cbs_MP_MF_div2

as hidden parameter, in daz studio. (Hidden/FACS/Fixs), They are MCM (vertex morph), so plug in generate them. I discribe facs_cbs_MP_CPL_div2 , then it have 2 ERC

1st delta add (with scholor), by Mouth Pucker,

2nd Multiply with Cheek Puff Left

so it is expected only add value, when these 2 pose controller set value at same time. eg if you set Cheek Puff Left as 1.00, but not use Mouth Pucker (keep as 0), facs_cbs_MP_CPL_div2 not used. (keep value as 0 in daz studio), like this pic

but in blender, it have only one driver expression, with Cheek Puff Left, then when I use Cheek puff left, facs_cbs_MP_CPL_div2 shape key value change and deformed by MCM, even though I do not use Mouth Pucker at all.

It is because, the shape key facs_cbs_MP_CPL_div2 have no driver expression witch need to add value of Mouth Pucker.

(1st and 2nd change, but same problem happen about those 4 CPL , which need to be driven by Mouth Pucker too, so it work as MCM (morph corrective morph)

It is somehow important, or even though we can import MCM,, it may add un-necessary defomation, without we notice. (2nd multiple, or 1st add value are ignored, )

‌

[engetudouiti]

you can compare in daz studio ERC formula, in property hieralchy, and Blender shape key Driver expression in driver editor. about this case, only 2nd drv seems used. (it change with each _cbs,, I do not know reason though)

‌

‌

You may find same issue for those facs_cbs_MP_XXX morphs. (MP = Mouth Pucker I suppose,, so without mouth pucker link, the MCM not have meaning

‌

[Thomas Larsson]

The Eyes wide case is solved now. Mouth close requires more work.

[engetudouiti]

OK Eyelids and Eye controller seems most complex one, I may check them. As quick view, There are one gloval controller which add on not generate.

“Eye Look Automatic” it can change eye around mesh (eyelids etc) will deform with eye or not. so if we set it OFF we can controll eye mesh only. (not move with eye around mesh), but it can be improved later. I suppose at current add on always use it as ON. THen I may test with “ON” only first.

[engetudouiti]

No I test with recent commit and 2.91 , but eye wide open still not drive any shape keys.

I can confirm I up-date add on file, by check your modified actually they are up-dated correctly.

[engetudouiti]

If I manually correct it without generate mix shape key or new hidden controller, it is actually easy.

I need samething for right side. you may compare how it work, with mute the _cbs

‌

[engetudouiti]

The dificulity is I know, we can not set driver directly for _jnt s, daz simply drive r and l _jns with Eye Wide, then each MCM driven too.

but if we set driver for controller, in blender we can not move them individually any more. so we set driver for shape key (about this case), or make new mix shape key. (R and L _cbs mix and generate new _cbs eye wide. but when import files, there is no formula you can use it in files. I think if you try to auto-mate all, you need complex condition.

if correct each morph specific (like I manually do in blender) , it seems more easy but need to discribe each parameter. I suppose if we can add one more data json, which only discribe specific morph ERC relation as same as we can see it in daz property hieralchy pane. then add on check it when generate driver.. (so we can discribe ERC relation for each specific morphs , when we found problem)

Though I may disappoint, because if make it so,, we can manage specific morph like FACS but it never work for other product. morph. or custom morphs. ^^; And it need to consider format, how we make ERC data file, which script can read and auto-set driver. (if add on can read such data file, and there is clear format documant,, user can discribe ERC relation manually, then when import custom morphs, set the file as ERC.json.

‌

[Thomas Larsson]

Weird. Thing did work here before I made the commit, but I seem to have deleted the line that added the extra drivers. Its back now.

[engetudouiti]

Yes I supposed so ^^; then if you could (as far future request) consider, make ERC.json and read it when we import morphs please.

[engetudouiti]

I could confirm, 1st one solved. (and you seems correct some same type problem (r and l move at same time) .

though blender lost controll property when it is driven,, but blender can set more complex expression for driver, than daz do.

Then about all morph ERC, it seem we only need to generate driver expression correctly, for shape keys or pose bone transform.

2nd and 3rd issue seems can be solved. only change shape key expression. as same way.

[engetudouiti]

Now I could confirm 2nd is solved. and 1st commit for L and R seems other _CBS , then generate driver expression for both. (master and each L and R side)

Then 3rd still remain. I do not think need to describe same thing again, but if you check about facs_cbs_MP_CPL_div2 dirver setting it should be like this.

current one

current already add driver target for Master ctrl too. it has been enhanced. then you need to add new Variable “c”, for Datapath = ["facs_bs_MouthPucker_div2"] (it is delta add ERC, 1st stage)

Then if we follow the daz formula stage,, order (first, delta add second multiple), Expression should be “ca + cb” or “c * (a+b)”

‌

you need to do same thing for other facs_cbs_MP_XXX shape keys. add MP path then multiple it. And there seems some other mix type facs_cbs_A_B, they have same problem. (not set expression for both property A and B. only one property set driver target ) I suppose it may be auto solved. (though after you correct it, I may check them like facs_cbs_MSL(R)_XXXX ,, facs_cbs_JO_JL(R)) etc)

[engetudouiti]

4th

In ds G8.1 we have Eye Look Automatic on/off property. it controll Eye around mesh deform with Eye bone rotation. or not. Then as default value is ON, I think, then add on already generate the controller with default ON. (but seems not set driver at current)

Then Main problem is ,, when we move eye bone, or contoll drv-bone, both case eye lids bone need to move with eye bone, and need to add related morphs. (eye around mesh deform)

eg in ds use facs_ctrl_EyeLookSide-SideLeft (Eye Side - Side Left) in pose controller/Eye, ds auto move eyelids bone and add some corrective morphs.

But in blender, it only move Eye bone. (eyelids not follow, and not deform eye around mesh)

One reason I could easy found is,, add on seems generate hidden/FACS/Utility ctrl properties. (they are not be shown as UI controller) ,Then these hidden Ctrl are key controller for G8.1 eye posing. They need to be driven by eye bone rotation, and drive eye around morphs at same time.

but at current they do not set driver at all. and I can not find facs_ctrl_EyeLookDownLeft and Right as custom prop. I do not know reason though.

Then if add on actually generate it,

facs_ctrl_EyeLookDownLeft controlled by Eye Left Eye X rotation. (with scholor value as 0.333 = when Eye X rotate = 30 degree, (not radian) the value driven as 1) so we need to set driver target as eye X rotation (in daz local) after that it will be multipled with Eye Look Automatic.

Then facs_ctrl_EyeLookDownLeft drive facs_jnt_EyeLookDownLeft . But the difficulity and complex thing is, the sub-component facs_jnt_EyeLookDownLeft is UI controller which we need to set value, so we can not set driver for those UI controller (or we lost controll manually)

So about these case (can not set driver for UI controller), we need to pick which props will be driven by UI controller, and add facs_ctrl_EyeLookDownLeft as new expression value, with keep facs_jnt_EyeLookDownLeft

facs_jnt_EyeLookDownLeft actually drive those eyelids bone X rotation,, with add related mcm. add on already do it correctly, but all props which driven by need to change driver expression, which add new variable for facs_ctrl_EyeLookDownLeft so those props can be driven, when facs_ctrl_EyeLookDownLeft change value too.

The relation is like this

eye rotate X >drive> facs_ctrl_EyeLookDownLeft (Hidden) >drive> facs_jnt_EyeLookDownLeft(UI ctrl)>drive> eyelids bone rotation and MCMs

at current eyelids bone rotation and MCMs only driven by facs_jnt (UI ctrl), but they need to change value with facs_ctrl too. (we can not set driver for facs_jnt_EyeLookDownLeft(UI ctrl) , so we need to set driver for eyelids bone and each shape keys)

[engetudouiti]

And one more, when eye lids drv_bones _(or any pose d_rv bones) are driven by eye bone , we must need to check this issue too https://bitbucket.org/Diffeomorphic/import_daz/issues/296/making-bones-posable-results-in-wrong

or it may only work correclty, when we use pose controller for eye bone. blender can not catch, eye bone roataion when we use controller as driver target variable. (so may need to do samething before,)

[engetudouiti]

Then I am thinking way to make things work more daz like, (difference blender driver and daz ERC) . the main problem is blender can not use “delta add” for driver. so when add driver the prop can not use as UI controller any more.

About bone transform prop, you solved it by add drv bone as parent of pose-bone.

that means, you divide user controll value (raw value) and driven value (current value - raw value) so when we see eye bone (or any pose bone ) transform value in blender it only show Daz raw value. then drv_bone transform value show Daz Current value - Daz raw value = driven value .

If generate all driver as same as daz manner,, I may plan to do same thing, for morph property too. As I said, all morph dsf generate controller in daz. Then about controller which user not change value , set as “hidden”. about controller which user set value, set as “visible”. now I call those user tweak visible prop as UI prop (prop_A)

Then only when UI property (prop A) are driven by other property , duplicate it and generate drv_prop A as hidden.

so drv_prop A can set driver as we like. at same time can set it as driver-target. as same as prop_A may becom driver target.

the relation is like this

In daz studio,

ERC controller (prop C) >> drive >> prop A >> drive >> ERC subcomponent.(prop B)

To show same effect in blender, duplicate prop A UI controller and label it drv_prop A, then it is hidden from UI , and set driver as same as daz.

(prop C) >> drive >> drv_propA >> drive >> ERC subcomponent (prop B) ,

next we need to set driver for sub_component (prop_B) then, add prop_A as driver variable of prop B.

prop_A >> drive >> ERC subcomponent (prop_B)

prop_B driver expression function change from f (prop_A.value) to f (prop_A.value + drv_prop_A.value)

then we may only tweak “prop A” as UI property,, the value should be Daz raw value. only. not include driven value.(because we can not set driver for prop A) but other property(prop C) will drive drv_propA then it show driven value only (real value - raw value) . after all subcomponent “prop B” need to be driven by “prop A” and “drv_prop A” so the value should be same as daz prop B. the function should be f(prop_A.value + drv_propA.value)

Though I do not know, if the prop C (controller) will be driven by other cntroller,, the duplicate way work or not. but actually you do so about drv_bone transform value.

[engetudouiti]

And one more substitute way I can imagine,, it is almost same, but perfectly divide real value, row value and drv value.

The merit is so we can set driver for each more precisely. with use dsf formula.

that measn for eachy morph prop. generate 3 morph porp. 1 is UI prop , 2 is driven prop (hidden) 3 is Prop which simply add 1 and 2 .

eg in ds we have prop A, then in blender generate, “drv_prop A”, “row_prop A,” and “prop A”.

set driver for prop A , the expression should be (“drv_propA + row_propA”)

we only set driver for drv_prop A. then row_prop A is UI prop which user can input value. at same time row_prop A never be used as another property driver target. and never set another driver (expression = drv_propA + row_propA only), but propA becom driver target of another prop.

1 Controller propC >> drive >> drv_propA(hidden),

2 prop A = drv_propA + row_propA (user input value for row_propA)

3 prop A(hidden) >> drive >> SubComponents. (so subcomponent props set driver as f(propA.value))

(so the driver expression should be same as daz dsf formula which saved for controller or sub-component)

of course if user hope to see real value (driven value + row value), we can set propA as visible (but we can not tweak the value it is always driven as (“drv_propA + row_propA,)), we can only use row_propA as UI controller to input value.

[engetudouiti]

No the above way may only work for 1st stage (add only). when mix use multiple, it can not represent daz way.

But “divide prop as 2” is actually what daz ERC do for all property. And what we actually need was not drv_prop. but raw_prop A = user input value. which user change as slider, or swithc. then it need to be separated real prop value.

actually daz offer 2 property for every propoerty. 1 is Raw property (which user set value untill ERC change)

2nd is Final property which we see value in Parameter as the prop value.. Row property is hidden from UI but we actually can get Raw value with parameter setting tab. (that means daz separate prop value as 2)

‌

Then daz use the raw_prop A.value to get actual prop A value (which incude ERC formula effect)

prop A (in UI) ={ (raw_propA + porpB + prop C…. <1st stage> ) * (prop D * propE * propF ….<2nd Stage>)}

so if we generate raw_propA which we input value, for all custom property prop A in blender, it can represent daz raw value. we need not set driver for raw_propA. We set driver for prop A (in UI) only, then the driver Expression should be same as daz formula of prop A.

The only difference is, in daz we can set prop A value directly. like 0.8 . ( at same time ds auto set raw value of propA with reverse circulation)

but in blender, we need to use raw_propA to input value. (prop A have driver, so we can not set value for it)

That means, we can only input value which not include driver expression (ERC formula effect), so when import daz property value like preset.duf which only describe prop.value. not raw value. Then the final value will be different without we do reverse circulation as same as daz, and get the raw_propA value, and set it. (it will be circulated again ,and auto-set propA value by driver functions.)

At same time, Current add on represent “daz bone transform value,” as

driven value(drv_boneA transform value) + raw value (child pose boneA tarnsform).

so in daz satudio, if bone A have ERC like this

rotation_X.value = bone A.rotation_X. raw_value(30 degree) * propB.value (0.5)

actuall bone rotation X value = 15 degree. it is real pose value of bone A.

we can not represent it as same as daz.

1 set 30 degree as bone A.rotation_X value.

2 the value will be multipled with 0.5 = 15. this value will be used as drv_boneA rotation X value.

3 actuall pose value is drv_boneA.rotation_X (15) + pose boneA.rotation_X (30) = 45.

It should be limit of current add on pose controller which drive bone transform I think. (we can not mix use, pose controller (drv_bone trnasform) with manuall posing (child bone trnasform) when driver include multiple epxression.

[engetudouiti]

Then if as future, add on enhance current drv-bones, it may change bone hieralchy.

at current add on generate drv-bone.(which only represent driven bone transform), but add on may need to generate duplicated raw_bone for each pose bone. (we do not generate drv_bone anymore)

it is bone we input value as raw transform value. (actually we may need not add new bone, but if user hope to use blender UI transform prop, adding new bone show them , so I may add those raw_bone)

then raw_bone and pose bone locate in same hieralchy. not set child of others. after generate raw_bone, all pose_bone transfrom value need to set driver, which driven by raw_bone transform values. as same as daz.

eg

bone A,.translate X value = (raw_bone A. translate value [user input value] + other prop values <1st stage delta add> )* mutliple (propB * propC * propD <2nd stage multiple>)

Then we can still free move those raw_bone. it drive each real pose bone (deform bone) which inculde other prop value (driver expression ).

we do not set value for those deform bone, but we set driver for all pose bone transform value (rotation, scale, trasform) = we do not change those drform bone transform. (it only driven by driver)

If pefreclty represent daz pose controller, these things may need. at least current drv-bone can not manage 2nd stage ERC (mutliple with). but I just discribe what can be, so I do not request it seriously, (and it may effect current bone hieralchy I afraid, stability breaking, so it is just my explanation what we may need to represent daz ERC)

[Thomas Larsson]

The three first cases should now be correct. Bone drivers (e.g. for eye look down) are still ignored, but all FACS morphs load and they look quite reasonable to me.

I experimented a little with morphs that change the rest pose, but the results were confusing and the feature is disabled for now. It is better to test it on some FBM where the effect is more pronounced. It seems that almost all files either contain pose morphs (translate, rotate, scale) or rest pose morphs (center_point, end_point), so there shouldn’t be any collision if both translate and center_point affect the bone location.

[engetudouiti]

Thanks. if case 3 work well, many product shape adjust morphs which had not been worked correclty, may work without edit driver. I expect it. (like leg shape adjust morph with posing etc,,)

case 4 (eye around morph with eye bone relation) maybe most complex one. as I said the ERC relation is hieralchical. and it include prop which we need to cotnroll as UI property, at same time it need to be driven by other controller.

And I noticed you try to change , bone center point (= blender bone Head) as same as many daz vertex morph adjust it. But as you said, maybe it not work, (with up-date things, blender can not manage, rest (Edit) bone change with pose bone transform. by driver.

Though I might test them. (if it work well I think we will change current import way.. because now we may need not bake rest pose and deformed shape. (which include all morph effect ) but we will import each base figure with import morphs which currently used, (like AIko or VIctoria etc etc) and set each FBM or PBM morph values.

It is huge break through, at same time, I can imagine we need to import too many morphs. (FBM PBM) when import current daz scene character. Anyway I test case 3. and see how it work thanks.

‌

[Alessandro Padovani]

In my own opinion. This sounds all exciting and an excellent solution to mimic the daz technology in blender. What I feel is we don't necessarily need to. I mean, I'd rather try to keep things simple and import the basic features, the blender way, not the daz way.

Then I understand daz figures can do true magic with morphing armatures, but will this work with a rigged figure in animation ? I mean a true ik rig as mhx or rigify. May be there's a reason if daz can't get ik chains to work fine.

Then perhaps I'm just scared of what I don't understand, as the cave men with fire. And what I call the hell of drivers may just be the paradise of rigging.

[engetudouiti]

What Thomas tried with some commit (at current it disable as default), is try to adjust center point of bones, when daz new  FACS morphs adjust it with change morph value (shape keys value) as same as daz.

new FACS depend more shape keys than G3 and G8 facial morphing. (so daz easy change their mind.. because daz said before, use facial bone make things more realistic than use many shape keys, but now it mix both huge)

The more depend shape keys, actually we may better to adjust bone position to fit current vertex position. Unfortunatelly ? actually most of new  FACS related morph (almost all) adjust center point too.. at current plug in ignore it.. (because it not work for blender),

So eventhough it not used when import character (for FBM or PBM), at least many pose morphs will move more reasonable when daz adjust center point. . (I just said assamption if it work for all FBM PBM.. it never means we should choose it,)

Then I do not think, we must need to import base character + each morphs. (and set value).. even though as future if it can be,, I may prefer baking most of morphs when import. but character MCM JCM may work better, we do same thing as daz.

After all,, without check actually it work,, Thomas never do it, and never force it user.

[engetudouiti]

Then actually at current we do not make so complex driver at all.. you may see more complex bone driver, when you import blender animation character rig.. (though use constrain is more good for peformance) the only difficulity is how import and generate driver like daz way.when we import morph files. almost it is all about this topic. (then it include rest pose bone transform,, but at current it is just experimental,, if it work well I simply suprised, then approve it.. but if it not work well, ,I think it is blender side limit. (some daz user already ask blender dev but, we can not request it only for daz figure,,, if many character rig do same thing (in game engine etc),, blender may try to make it work I suppose.)

‌

[engetudouiti]

Thanks Thomas, So there are too many case 2 mix type MCM morphs,, I can not test for all mix case, but now it seems work . (with compare driven values) I may check if there remain some clear wrong case, with eye related  FACS units, but if it not huge problem I may close it.

Then may test personally see expression correctly work or not. if I find some clear problem may open as  FACSexpression topic,. but I do not know. (I am G3 main user). then what I expect is these recent enhancement may work well even though I tried it as import custom morphs?

(that means,, set driver correctly, when I import same logic morph products for G3 as import custom morphs…) or it is G8.1 FACS specific enheancements?)

[engetudouiti]

Yes only a little pity thing, is (for G8.1 user?) eye bone have no relation with around eye bones like eye lids bones, then may not efficently show Facs morphs when we pose eye. (manually move eye bone, or use eye pose controller like side to side)

for G3 eye bone only need to link with some eyelids bones, so it could be solved. (Maybe G8 use same logic I supposed) About G8.1 it mixing, with bone pose deform + hielalchical ERC morphs, so maybe it need more time. to solve it (if do same as daz).

I afraid if it may show problem when expresison include pose eye bone… but without G8.1 user request it,, I may need not As for me this topic can be solved. (and it seems better, may open more specific case when others need, I suppose) if Thomas hope to keep this , open please as you need.

Anyway I hope these enhancement of FCNS morphs improve , import custom morphs too (that was may main reason, why I report thosee.. )

‌