The length of scripted expression strings is limited to 256 characters. #47896

Closed
opened 2016-03-23 03:10:32 +01:00 by Thomas Larsson · 13 comments
Member

System Information
Win 7 64 bit

Blender Version
2.76

Short description of error
The length of scripted expression strings is limited to 256 characters. A misfeature rather than a bug, but something that I ran into and I don't know how to get around.

Exact steps for others to reproduce the error
I have a script that imports duf/dsf files from Daz Studio. In the Genesis3 character, the face is deformed by bones, but it is more convenient to manipulate high-level facial expressions and visemes, which I have mapped to object properties that drive the face bones. The problem is that Daz has created many of these, and the length of the expression string grows too big.

As an illustration, the first expression that becomes too big is the following:
Expression:
0.000+(0.0187x00)+(0.0627x01)+(-0.0017x02)+(-0.0006x03)+(0.0627x04)+(0.0588
x05)+(-0.0003x06)+(0.0017
x07)+(-0.0067x08)+(0.0602x09)+(0.0058x10)+(0.0009
x11)+(0.1198x12)+(-0.0083
x13)+(0.0012x14)+(-0.0119x15)+(-0.0187x16)+(0.014
8
x17)+(-0.0043*x18)
Variables:

x00 : ["eCTRLCheeksBalloon"]
x01 : ["eCTRLCheeksBalloonPucker"]
x02 : ["eCTRLLipBottomUp-DownR"]
x03 : ["eCTRLLipsPart"]
x04 : ["eCTRLLipsPucker"]
x05 : ["eCTRLLipsPuckerWide"]
x06 : ["eCTRLMouthCornerBackR"]
x07 : ["eCTRLMouthCornerUp-Down"]
x08 : ["eCTRLMouthFrown"]
x09 : ["eCTRLMouthNarrowR"]
x10 : ["eCTRLMouthOpen"]
x11 : ["eCTRLMouthOpenWide"]
x12 : ["eCTRLMouthSide-SideL"]
x13 : ["eCTRLMouthSide-SideR"]
x14 : ["eCTRLMouthSmile"]
x15 : ["eCTRLMouthSmileOpen"]
x16 : ["eCTRLMouthSmileSimpleR"]
x17 : ["eCTRLvAA"]
x18 : ["eCTRLvEE"]

ERROR: Cannot add driver ["eCTRLvEE"] to bone rLipLowerOuter.
Expression too long.

**System Information** Win 7 64 bit **Blender Version** 2.76 **Short description of error** The length of scripted expression strings is limited to 256 characters. A misfeature rather than a bug, but something that I ran into and I don't know how to get around. **Exact steps for others to reproduce the error** I have a script that imports duf/dsf files from Daz Studio. In the Genesis3 character, the face is deformed by bones, but it is more convenient to manipulate high-level facial expressions and visemes, which I have mapped to object properties that drive the face bones. The problem is that Daz has created many of these, and the length of the expression string grows too big. As an illustration, the first expression that becomes too big is the following: Expression: 0.000+(0.0187*x00)+(0.0627*x01)+(-0.0017*x02)+(-0.0006*x03)+(0.0627*x04)+(0.0588 *x05)+(-0.0003*x06)+(0.0017*x07)+(-0.0067*x08)+(0.0602*x09)+(0.0058*x10)+(0.0009 *x11)+(0.1198*x12)+(-0.0083*x13)+(0.0012*x14)+(-0.0119*x15)+(-0.0187*x16)+(0.014 8*x17)+(-0.0043*x18) Variables: ``` x00 : ["eCTRLCheeksBalloon"] x01 : ["eCTRLCheeksBalloonPucker"] x02 : ["eCTRLLipBottomUp-DownR"] x03 : ["eCTRLLipsPart"] x04 : ["eCTRLLipsPucker"] x05 : ["eCTRLLipsPuckerWide"] x06 : ["eCTRLMouthCornerBackR"] x07 : ["eCTRLMouthCornerUp-Down"] x08 : ["eCTRLMouthFrown"] x09 : ["eCTRLMouthNarrowR"] x10 : ["eCTRLMouthOpen"] x11 : ["eCTRLMouthOpenWide"] x12 : ["eCTRLMouthSide-SideL"] x13 : ["eCTRLMouthSide-SideR"] x14 : ["eCTRLMouthSmile"] x15 : ["eCTRLMouthSmileOpen"] x16 : ["eCTRLMouthSmileSimpleR"] x17 : ["eCTRLvAA"] x18 : ["eCTRLvEE"] ``` ERROR: Cannot add driver ["eCTRLvEE"] to bone rLipLowerOuter. Expression too long.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @thomasl-3

Added subscriber: @thomasl-3
Member

Added subscriber: @JoshuaLeung

Added subscriber: @JoshuaLeung
Joshua Leung self-assigned this 2016-03-23 04:22:16 +01:00
Member

Eek! That is quite a horrendous "little" thing :P

I never expected anyone would have any need for something quite that long! (Annoyingly, it just tops out at 260 characters too)

Is this the longest one it generates, or is this on the short end?

Eek! That is quite a horrendous "little" thing :P I never expected anyone would have any need for something quite that long! (Annoyingly, it just tops out at 260 characters too) Is this the longest one it generates, or is this on the short end?
Author
Member

It is the first string that contains more than 256 characters. The expression is put in an ordinary string before assigning it to the driver, in order to generate a better error message.

I don't expect that anybody human would write such a thing, but a script can. The script halts when it has created a too long string; otherwise it would add more variables. As you might guess from the variable names, there are at least half a dozen more visemes waiting to be loaded. With some work the expression could be trimmed somewhat, but hardly enough to squeeze in six or eight more variables.

The easy fix would be to increase the limit to 512 characters. This would probably solve my problem, but the problem would remain in principle, and I don't think that my script is important enough to increase the memory consumption for everybody else.

It is the first string that contains more than 256 characters. The expression is put in an ordinary string before assigning it to the driver, in order to generate a better error message. I don't expect that anybody human would write such a thing, but a script can. The script halts when it has created a too long string; otherwise it would add more variables. As you might guess from the variable names, there are at least half a dozen more visemes waiting to be loaded. With some work the expression could be trimmed somewhat, but hardly enough to squeeze in six or eight more variables. The easy fix would be to increase the limit to 512 characters. This would probably solve my problem, but the problem would remain in principle, and I don't think that my script is important enough to increase the memory consumption for everybody else.

This issue was referenced by 322f86d6b3

This issue was referenced by 322f86d6b330ebeb1da5c1f527714745dc901460
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Author
Member

With some extra work I did manage too squeeze everything into 256 characters. The worst case is the following expression that weighs in at 190+.

Expression:
(+95B +95C +90D -9E +45F -65G +97H +33I +74J -31K +121L +12M -7N -4
2
O +43P +9Q +22R +37S +4T +9U -2V -18W +10X +21Y +128Z -15a +52b +
22
c +57d +96e +108f +28A)/1000
Variables:

A : ["eCTRLCheeksBalloon"]
B : ["eCTRLCheeksBalloonPucker"]
C : ["eCTRLLipsPucker"]
D : ["eCTRLLipsPuckerWide"]
E : ["eCTRLMouthCornerBackL"]
F : ["eCTRLMouthCornerUp-Down"]
G : ["eCTRLMouthFrown"]
H : ["eCTRLMouthNarrowL"]
I : ["eCTRLMouthOpen"]
J : ["eCTRLMouthOpenWide"]
K : ["eCTRLMouthSide-SideL"]
L : ["eCTRLMouthSide-SideR"]
M : ["eCTRLMouthSmile"]
N : ["eCTRLMouthSmileOpen"]
O : ["eCTRLMouthSmileSimpleL"]
P : ["eCTRLvAA"]
Q : ["eCTRLvEE"]
R : ["eCTRLvEH"]
S : ["eCTRLvER"]
T : ["eCTRLvF"]
U : ["eCTRLvIH"]
V : ["eCTRLvIY"]
W : ["eCTRLvK"]
X : ["eCTRLvL"]
Y : ["eCTRLvM"]
Z : ["eCTRLvOW"]
a : ["eCTRLvS"]
b : ["eCTRLvSH"]
c : ["eCTRLvT"]
d : ["eCTRLvTH"]
e : ["eCTRLvUW"]
f : ["eCTRLvW"]

ERROR: Cannot add driver ["eCTRLCheeksBalloon"] to bone lLipCorner.
Expression too long.

With some extra work I did manage too squeeze everything into 256 characters. The worst case is the following expression that weighs in at 190+. Expression: (+95*B +95*C +90*D -9*E +45*F -65*G +97*H +33*I +74*J -31*K +121*L +12*M -7*N -4 2*O +43*P +9*Q +22*R +37*S +4*T +9*U -2*V -18*W +10*X +21*Y +128*Z -15*a +52*b + 22*c +57*d +96*e +108*f +28*A)/1000 Variables: ``` A : ["eCTRLCheeksBalloon"] B : ["eCTRLCheeksBalloonPucker"] C : ["eCTRLLipsPucker"] D : ["eCTRLLipsPuckerWide"] E : ["eCTRLMouthCornerBackL"] F : ["eCTRLMouthCornerUp-Down"] G : ["eCTRLMouthFrown"] H : ["eCTRLMouthNarrowL"] I : ["eCTRLMouthOpen"] J : ["eCTRLMouthOpenWide"] K : ["eCTRLMouthSide-SideL"] L : ["eCTRLMouthSide-SideR"] M : ["eCTRLMouthSmile"] N : ["eCTRLMouthSmileOpen"] O : ["eCTRLMouthSmileSimpleL"] P : ["eCTRLvAA"] Q : ["eCTRLvEE"] R : ["eCTRLvEH"] S : ["eCTRLvER"] T : ["eCTRLvF"] U : ["eCTRLvIH"] V : ["eCTRLvIY"] W : ["eCTRLvK"] X : ["eCTRLvL"] Y : ["eCTRLvM"] Z : ["eCTRLvOW"] a : ["eCTRLvS"] b : ["eCTRLvSH"] c : ["eCTRLvT"] d : ["eCTRLvTH"] e : ["eCTRLvUW"] f : ["eCTRLvW"] ``` ERROR: Cannot add driver ["eCTRLCheeksBalloon"] to bone lLipCorner. Expression too long.

This issue was referenced by 6a0c187653

This issue was referenced by 6a0c18765307fba22a2fab78cadcabc73c9b10bb

Added subscriber: @WCN

Added subscriber: @WCN

This limit appears to still be in place. Is it necessary to keep it around, or would it be harmless to increase it?

For my example, I have the following driver that simulates the motion of a gear:

(lambda rootObj: (lambda Ratio: (lambda BaseAngle: -BaseAngle-rootObj.rotation_euler[2]*Ratio)(BaseAngle=atan2(*(rootObj.location-self.location)[:2])*(Ratio+1)))(Ratio=rootObj["Teeth"]/self["Teeth"]))(rootObj=bpy.data.objects[self["RootName"]])%(2*pi)

So far, it does nearly everything I need it to. But I want to add just one more term to align the gears' teeth in some circumstances, and I can't as the expression is already 251 characters long.

  • "Why are you using bpy.data and self instead of driver variables?" The expression would need five or six driver variables with the same target object to access all of its needed properties. Going through bpy.data lets me reassign the root gear of a simulated gear by editing only one custom property. The workflow improvement is worth the performance and depsgraph cost.

  • "Wouldn't it be better to move the driver into a text file at this point?" Arguably, yes. I probably will. But adding a text file also creates one more datablock to keep track of, link, append, break, lose, sync, etc.

If the character limit isn't strictly necessary, then increasing it just gives the user more options. Maybe 1024 or so could still discourage abuse while being enough for most human-written uses.

This limit appears to still be in place. Is it necessary to keep it around, or would it be harmless to increase it? For my example, I have the following driver that simulates the motion of a gear: ``` (lambda rootObj: (lambda Ratio: (lambda BaseAngle: -BaseAngle-rootObj.rotation_euler[2]*Ratio)(BaseAngle=atan2(*(rootObj.location-self.location)[:2])*(Ratio+1)))(Ratio=rootObj["Teeth"]/self["Teeth"]))(rootObj=bpy.data.objects[self["RootName"]])%(2*pi) ``` So far, it does nearly everything I need it to. But I want to add just one more term to align the gears' teeth in some circumstances, and I can't as the expression is already `251` characters long. * "Why are you using `bpy.data` and `self` instead of driver variables?" The expression would need five or six driver variables with the same target object to access all of its needed properties. Going through `bpy.data` lets me reassign the root gear of a simulated gear by editing only one custom property. The workflow improvement is worth the performance and `depsgraph` cost. * "Wouldn't it be better to move the driver into a text file at this point?" Arguably, yes. I probably will. But adding a text file also creates one more datablock to keep track of, link, append, break, lose, sync, etc. If the character limit isn't strictly necessary, then increasing it just gives the user more options. Maybe 1024 or so could still discourage abuse while being enough for most human-written uses.

Added subscriber: @TakeshiFunahashi

Added subscriber: @TakeshiFunahashi

Dear developers please change limit from current 256. I actually face this problem now. please re-consider remove current limit . At current it seems as 256. (or make this topic Open again, because it is not solved at all)

I have many morph controller script auto generate, but it work without problem. Only problem is, I can not use some morphs, just for this expression limit problem. The more rig importer enhanced, the more current limit cause problem.

Though Custom python function for driver expression can solve this issue, but it cause heavy performance issue. (actually if I do not use python custom function, the character driver work really well even though we set long expression with many variable props and drivers)

For OP specific case (and my purpose), I think "new driver type sum with step value" will solve this issue. "sum with step driver type"
I know here is not request place, but if blender keep the expression limit, consider it please.

Dear developers please change limit from current 256. I actually face this problem now. please re-consider remove current limit . At current it seems as 256. (or make this topic Open again, because it is not solved at all) I have many morph controller script auto generate, but it work without problem. Only problem is, I can not use some morphs, just for this expression limit problem. The more rig importer enhanced, the more current limit cause problem. Though Custom python function for driver expression can solve this issue, but it cause heavy performance issue. (actually if I do not use python custom function, the character driver work really well even though we set long expression with many variable props and drivers) For OP specific case (and my purpose), I think "new driver type sum with step value" will solve this issue. ["sum with step driver type" ](https://blender.community/c/rightclickselect/zjhbbc/) I know here is not request place, but if blender keep the expression limit, consider it please.
Sign in to join this conversation.
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#47896
No description provided.