(-16*A-32*B+4*C-13*D-23*E-20*F-7*G+9*H+22*I-5*J-10*K-7*L+5*M+1*N+8*O-10*P-13*Q-24*R-46*S-10*T-37*U+8*V-10*W-13*X+13*Y+0*Z+1*a+50*b-39*c-21*d-29*e+9*f+7*g-45*h-9*i-40*j)/1000
where A-j are driver variables, one for each rig property. In this case the data path of the A variable is ["DzVEE"], so A is the value of the rig property DzVEE, corresponding to the viseme EE. The problem is that in Blender the length of scripted expression is limited to 256 characters. If we load many face units, expressions and visemes, this limit is easily exceeded.
To circumvent this problem, about a year ago I introduced handlers, which are functions that are called every time the scene is updated. Instead of directly driving the bone locations by rig properties, the rig properties drive a number of intermediate bone properties, and the bone locations are then updated by the handlers. The advantage of this method is that each intermediate property is only driven by part of the original rig properties, so the length of the scripted expressions can be kept under the 256 character limit.
However, handlers introduce new problems of their own. It does not seem possible to combine handlers with other drivers, because the handlers are not drivers. This becomes a problem e.g. for eyelids, which are driven both by the eye rotation and by face units such as Eye Close. But the most severe problem with handlers is that they slow down the viewport. All handlers are called each time a scene is updated, which is very time consuming.
Following a suggestion by Alec Vallintine I have introduced yet another way to drive bone locations: using custom driver functions. This method seems to solve all the problems with the previous two methods:
- There no limit to the number of driving properties.
- Driver functions can be combined with other drivers.
- Performance is much better than with handlers.
