Rigify doesn't generate if advanced option is set to "new" #71678

New Issue

Ivan Cappiello · 2019-11-19T17:11:07+01:00

Ivan Cappiello commented

2019-11-19 17:11:07 +01:00

System Information
Operating system: Darwin-19.0.0-x86_64-i386-64bit 64 Bits
Graphics card: Intel(R) Iris(TM) Graphics 6100 Intel Inc. 4.1 INTEL-14.0.69

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-12 13:28, hash: blender/blender@1252577580
Worked: 2.80

Short description of error
When rigify advanced generate options are set to "new" rig, the generate function will raise error.

Exact steps for others to reproduce the error
• Add a human metarig from the Add Menu
• In Armature panel, under "Rigify Buttons" panel click on "Advanced Options" to activate the options panel
• Set the generate option to "New" and insert a name in the "Rig Name" field
• Click on "Generate Rig" Button

Rigify will raise the error:
'Generation has thrown an exception: name 'obj' is not defined'

**System Information** Operating system: Darwin-19.0.0-x86_64-i386-64bit 64 Bits Graphics card: Intel(R) Iris(TM) Graphics 6100 Intel Inc. 4.1 INTEL-14.0.69 **Blender Version** Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-12 13:28, hash: `blender/blender@1252577580` Worked: 2.80 **Short description of error** When rigify advanced generate options are set to "new" rig, the generate function will raise error. **Exact steps for others to reproduce the error** • Add a human metarig from the Add Menu • In Armature panel, under "Rigify Buttons" panel click on "Advanced Options" to activate the options panel • Set the generate option to "New" and insert a name in the "Rig Name" field • Click on "Generate Rig" Button Rigify will raise the error: 'Generation has thrown an exception: name 'obj' is not defined'

Ivan Cappiello commented

2019-11-19 17:11:07 +01:00

Added subscriber: @icappiello

Alexander Gavrilov was assigned by Ivan Cappiello

2019-11-19 17:11:40 +01:00

Ivan Cappiello commented

2019-11-26 11:54:10 +01:00

Added subscriber: @pioverfour

Ivan Cappiello commented

2019-11-26 11:54:10 +01:00

seems that merged patch by @pioverfour Rigify: store advanced options in armature instead of window manager fixes it for 2.82.
still there are some minor issues relative to naming and python ui.

the patch removes the '_rig' suffix from rig name, still this name is retained for the python ui script: Creating a rig with no name should roll back to default 'rig' as rig name and should logically output 'rig_ui.py'. If advanced option is set to "new" and a new name is set (for example 'new') the python ui script should named accordingly (new_ui) but will instead still append '_rig_ui' to the name. The python ui script and the rig should have consistent names.

If options is set to new and no name is set, generate will roll back to use 'rig' as name. if another rig is present in the scene a new 'rig.001' is created but the associated ui will be 'rig_ui.py.001' instead of 'rig.001_ui.py'

seems that merged patch by @pioverfour [Rigify: store advanced options in armature instead of window manager ](https://developer.blender.org/D5675/new/) fixes it for 2.82. still there are some minor issues relative to naming and python ui. - the patch removes the '*_rig*' suffix from rig name, still this name is retained for the python ui script: Creating a rig with no name should roll back to default '*rig*' as rig name and should logically output '*rig_ui.py*'. If advanced option is set to "new" and a new name is set (for example 'new') the python ui script should named accordingly (new_ui) but will instead still append '*_rig_ui*' to the name. The python ui script and the rig should have consistent names. - If options is set to *new* and no name is set, generate will roll back to use '*rig*' as name. if another rig is present in the scene a new '*rig.001*' is created but the associated ui will be '*rig_ui.py.001*' instead of '*rig.001_ui.py*'

Damien Picard commented

2019-11-26 14:52:25 +01:00

Added subscriber: @jesterking

Damien Picard commented

2019-11-26 14:52:25 +01:00

This bug was introduced by 3423174b37.
@angavrilov It seems that a 2.81a release is planned , should the fix be backported before then? @jesterking said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue.

@icappiello You are right about the Python script’s name, for it to be registrable, it must end with .py. Perhaps it should just use the generated rig’s name, something like:

diff --git a/rigify/rig_ui_template.py b/rigify/rig_ui_template.py
index bb5a9cbd..e9168483 100644
--- a/rigify/rig_ui_template.py
+++ b/rigify/rig_ui_template.py
@@ -1163,9 +1163,13 @@ class ScriptGenerator(base_generate.GeneratorPlugin):
 
         # Generate the UI script
         if metarig.data.rigify_rig_basename:
-            rig_ui_name = metarig.data.rigify_rig_basename + '_rig_ui.py'
+            rig_ui_name = self.generator.obj.name + '_rig_ui.py'
         else:
             rig_ui_name = 'rig_ui.py'
+            i = 1
+            while rig_ui_name in bpy.data.texts:
+                rig_ui_name = 'rig_ui.%03i.py' % i
+                i += 1
 
         script = None

About the _rig_ui vs _ui issue, it doesn’t bother me too much, I feel _rig_ui is more descriptive.

This bug was introduced by 3423174b37. @angavrilov It seems that [a 2.81a release is planned ](https://devtalk.blender.org/t/25-november-2019/10554), should the fix be backported before then? @jesterking said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue. ----- @icappiello You are right about the Python script’s name, for it to be registrable, it must end with `.py`. Perhaps it should just use the generated rig’s name, something like: ``` diff --git a/rigify/rig_ui_template.py b/rigify/rig_ui_template.py index bb5a9cbd..e9168483 100644 --- a/rigify/rig_ui_template.py +++ b/rigify/rig_ui_template.py @@ -1163,9 +1163,13 @@ class ScriptGenerator(base_generate.GeneratorPlugin): # Generate the UI script if metarig.data.rigify_rig_basename: - rig_ui_name = metarig.data.rigify_rig_basename + '_rig_ui.py' + rig_ui_name = self.generator.obj.name + '_rig_ui.py' else: rig_ui_name = 'rig_ui.py' + i = 1 + while rig_ui_name in bpy.data.texts: + rig_ui_name = 'rig_ui.%03i.py' % i + i += 1 script = None ``` About the `_rig_ui` vs `_ui` issue, it doesn’t bother me too much, I feel `_rig_ui` is more descriptive.

Ivan Cappiello commented

2019-11-26 15:03:00 +01:00

Added subscriber: @BrendonMurphy

Ivan Cappiello commented

2019-11-26 15:03:00 +01:00

In #71678#818028, @pioverfour wrote:
This bug was introduced by 3423174b37.
@angavrilov It seems that a 2.81a release is planned , should the fix be backported before then? @jesterking said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue.

i already wrote @BrendonMurphy and this could eventually be included in 2.81a

In #71678#818028, @pioverfour wrote:
About the _rig_ui vs _ui issue, it doesn’t bother me too much, I feel _rig_ui is more descriptive.

i don't agree. If you remove the _rig suffix from generated rig name for a reason, the same reason applies to python ui script. Please make tools consistent. Either you remove _rig from both or you leave it both places.

> In #71678#818028, @pioverfour wrote: > This bug was introduced by 3423174b37. > @angavrilov It seems that [a 2.81a release is planned ](https://devtalk.blender.org/t/25-november-2019/10554), should the fix be backported before then? @jesterking said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue. i already wrote @BrendonMurphy and this could eventually be included in 2.81a > In #71678#818028, @pioverfour wrote: > About the `_rig_ui` vs `_ui` issue, it doesn’t bother me too much, I feel `_rig_ui` is more descriptive. i don't agree. If you remove the _rig suffix from generated rig name for a reason, the same reason applies to python ui script. Please make tools consistent. Either you remove _rig from both or you leave it both places.

Alexander Gavrilov commented

2019-11-26 22:03:47 +01:00

This is a simple editing mistake that happened when splitting a huge function into class methods:

--- a/rigify/generate.py
+++ b/rigify/generate.py
@@ -114,7 +114,7 @@ class Generator(base_generate.BaseGenerator):
         self.widget_collection = ensure_widget_collection(context)
 
         # Remove wgts if force update is set
-        wgts_group_name = "WGTS_" + (self.rig_old_name or obj.name)
+        wgts_group_name = "WGTS_" + (self.rig_old_name or self.obj.name)
         if wgts_group_name in scene.objects and id_store.rigify_force_widget_update:
             bpy.ops.object.mode_set(mode='OBJECT')
             bpy.ops.object.select_all(action='DESELECT')

This is a simple editing mistake that happened when splitting a huge function into class methods: ``` --- a/rigify/generate.py +++ b/rigify/generate.py @@ -114,7 +114,7 @@ class Generator(base_generate.BaseGenerator): self.widget_collection = ensure_widget_collection(context) # Remove wgts if force update is set - wgts_group_name = "WGTS_" + (self.rig_old_name or obj.name) + wgts_group_name = "WGTS_" + (self.rig_old_name or self.obj.name) if wgts_group_name in scene.objects and id_store.rigify_force_widget_update: bpy.ops.object.mode_set(mode='OBJECT') bpy.ops.object.select_all(action='DESELECT') ```

Alexander Gavrilov commented

2019-12-03 11:32:13 +01:00

Changed status from 'Open' to: 'Resolved'

Alexander Gavrilov closed this issue

2019-12-03 11:32:13 +01:00

Alexander Gavrilov commented

2019-12-03 11:32:14 +01:00

Fixed for 2.81a in ed5b81f501.

Fixed for 2.81a in ed5b81f501.

Toni Alatalo commented

2019-12-03 15:19:14 +01:00

Added subscriber: @antont

Toni Alatalo commented

2019-12-03 15:19:14 +01:00

In #71678#818622, @angavrilov wrote:
This is a simple editing mistake that happened when splitting a huge function into class methods:

Hi, little nitpick, meant just as a friendly note:

Those are not class methods but instance methods (refer 'self', not 'cls'). Python has also class methods, but they seem to not be used there.
I think a Python Linter would catch such errors, kind of like a compiler, note that 'obj' is unknown there. Maybe helpful to use as a part of the Blender Python workflow somehow

> In #71678#818622, @angavrilov wrote: > This is a simple editing mistake that happened when splitting a huge function into class methods: Hi, little nitpick, meant just as a friendly note: 1. Those are not class methods but instance methods (refer 'self', not 'cls'). Python has also class methods, but they seem to not be used there. 2. I think a Python Linter would catch such errors, kind of like a compiler, note that 'obj' is unknown there. Maybe helpful to use as a part of the Blender Python workflow somehow

Sign in to join this conversation.