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.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#47896
No description provided.