Problem when importing more than 1 FACS custom expressions

[thisis sparta]

When importing more than 1 FACS expressions as custom morphs, a random FACS unit shapekey is set to a random value. For example, everything is fine when I import the ‘True Emotion’ pack but if I import any other FACS expression, say ‘Z Pain & Hurt Expressions’ then the shapekey driver for the mouth smile FACS unit is set to a value like 0.673 but in the FACS unit panel within the addon the slider for that value is set as 0, so I cant change it either.

[engetudouiti]

I supoose if it is driver expression length limit caused by blender. you may try only pick 5 or 6 custom morphs first. then check if it work or not. I suppose it work. When I test it , I use Z expressions for G3, untill expression String limit, all work fine. when import new morph , everytime add on need to change Facs Unit driver expresison. then when It come to String max limit, blender cut out expression.

For a while (to solve it, we have really a few choice so maybe it need more time, consider pro and con. ) you need to limit custom morph count. which may drive other morph props. or you may try to convert the morph as simple shape key morph. (not drive other prop) then import them.

[engetudouiti]

To confirm it is caused by expression limit, or your min and max setting of raw slider (you need to set no range , if you often mixing many morph slider . it not matter if you only use one morph slider ), can you show the problem driver expresison of the Face Unit which have broken?

you may open driver editor, then copy and paste the driver expression please. (If it is not max string limit of expression, I think it need more detail when it may happen. eg you set new category when import each morph pack etc)

[thisis sparta]

the driver expression only says x

[engetudouiti]

Is it really custom prop of Fin morph driver expression? or you check Face unit shape key driver expression?

if you check the morph shape key value driver expression, it should be one variable. so it is not problem. the variable X is Fin custom prop value of the morph. so you need to check not shape key of the Face Unit, but need to check Custom prop of the shape key name,, (rig data custom prop which driven by raw slider )

then if it is the Face unit fin custom prop dirver expresison, I suppose, it is not limit problem.. it seems perfectly overwritten when you import new expression which drive Face unit.. (but I do not see such issue with recent version. you can check the x variable deta path. in driver editor.. what is X data path?

[thisis sparta]

the data path is ["facs_bs_MouthFunnel_div2(fin)"]

[thisis sparta]

and when i check the driver for “facs_bs_MouthFunnel_div2(fin)” the expression of that is: a+0.34_b+0.2_c+0.2_d+0.112782_e+0.240601_f+0.218045_g+0.0526316_h+0.0955882_i+0.205882_j+0.110294_k+0.0603448_l+0.0676692_m+0.182609_n+0.0075188_o+0.218045_p+0.162791_q+0.162791_r+0.674419_s+0.674419_t+0.418605_u+0.418605_v+0.0697674_w+0.0697674*x+0.67441

also, scrolling down the drivers list that is in the picture, i see few invalid variable names:

‌

[engetudouiti]

To thisis sparta

Thanks you check by your self . Then I can confirm, it is the expression limit problem.. so untill we solve the limit issue, it never work.

you may notice even if we set all variables as 0, (each slider morph value), the final value = 0.67441 it never happen. and add on never generate such expression which add fix value like 0.67441

it should be (a + b*step value + c*step value………. (some variable) * (step value). if there is no limit .

‌

>>> str = "a+0.34_b+0.2_c+0.2_d+0.112782_e+0.240601_f+0.218045_g+0.0526316_h+0.0955882_i+0.205882_j+0.110294_k+0.0603448_l+0.0676692_m+0.182609_n+0.0075188_o+0.218045_p+0.162791_q+0.162791_r+0.674419_s+0.674419_t+0.418605_u+0.418605_v+0.0697674_w+0.0697674*x+0.67441"
>>> len(str)
255

so the expression cut by the limit without author intention.

[Thomas Larsson]

A test for the expression string length was actually in place, but the limit was set to 511 characters instead of 255, since that was the limit in some version of Blender. Now the limit has been lowered to 255, and there is a better error message if it is exceeded (i.e. you don’t have to look in the terminal window).

However, this is only a temporary workaround. The permanent solution is to use sum drivers, as is already done for driven bones. That would remove the limit on the number of morphs altogether.

[engetudouiti]

Yes we may need to use sum drivers, . (add dummy bone then atach props, or you use new collection property. etc)

At same itme,, I think there seems one more issue about variable limit, which you currently use ,, a to z? (though it will be solved, if you add new prop for Sum value for driven bone transform values.

[Thomas Larsson]

If we use a sum driver there is no reason to use single-letter names. Instead they will be called something like t0001 - t9999 as is the case for bone drivers.

[Thomas Larsson]

This should be solved with the last commit.