- User Since
- Jul 19 2016, 10:40 AM (166 w, 33 m)
Apr 5 2019
Mar 7 2019
Feb 21 2019
on 2.8 the following commit solves the issue:
task is closed
The issue was solved on my github unofficial repo.
What follows is a list of commits you should refer to in order to have a bug-free rigify for your specific version:
Feb 11 2019
Dec 20 2018
Face is a name-based rig_type. You cannot remove a subset of its bones because the generate method will look for missing names and eventually crash
Oct 22 2018
Jan 25 2018
You should provide a better explanation of the steps to reproduce the problem (along with system info and blender ver., OS ver. and so on. Copy-pasting the description draft is not enough).
When you provide a .blend it should be as "clean" as possible, meaning: getting rid of any unnecessary elements like drivers, animations, custom properties, text files and so on.
This is useful for three main reasons:
Jan 24 2018
@Philipp Oeser (lichtwerk) I'll have a look asap
Jan 21 2018
There is a (supposedly) leftover property on the following bones:
several bones of the face ( but not all of them)
Jan 4 2018
Hi @Damien Picard (pioverfour),
I got your PR but didn't have time to look into it, sorry.
No redundancy, Metarigs imports had to be done so it's fantastic you had time to spend on it.
I don't know about custom rig_ui templates though, is it something you discussed at Bcon as well?
@Julien DUROURE (julien) yes it should be backported thank you!
Dec 5 2017
Nov 30 2017
@Joshua Leung (aligorith) the problem is with the property name and fixing it in Rigify is straightforward.
Nov 21 2017
This new feature is breaking any animation curve or driver previously defined on the bbone_in and bbone_out properties as you can see from the attached .blend
Animations and drivers defined on these props are not correctly translated to bbone_easein and bbone_easeout
You're right I'm sorry I didn't tell you first... I started thinking about a solution to the problem right after Bcon, but thinking leads to coding and you're down the rabbit hole before you know it. One should NEVER start thinking! :D
I agree with you get_rig_list() and maybe get_rig_type() as well should be recoded to work in both cases (omg how hate those functions!) if this doesn't disrupt the relative imports in the internal rig_type modules
Nov 20 2017
@Julien DUROURE (julien)
Here's a patch solving the issue. If you don't know how to patch, I attached the two files you have to overwrite.
Please note that:
- ui.py belongs to /rigify/rigs/limbs/ folder
- rigify_ui_template.py is in /rigify/ main folder
I can confirm the issue. I'm working on it
Actually I implemented a version of the feature on my repo. I had to put the external directory in the sys.path though... So I'm not sure if it's the right way to handle it (python imports are a mess!)
Could you please check it out?
Yes I confirm it's related to https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/a819ef65c07131ddb203a55bd8dc4e3207130b64
Oct 30 2017
Oct 25 2017
There is a problem on the blend file you uploaded. It does not have a rig_ui.py file (so no snapping functions are present for the limbs) and there are no keyframes. That is why the pole-rotation Switches in Animation tools were not working
I'm investigating the IK_Stretch issue so I'll answer the 2nd question first.
Sep 16 2017
Wonderful!!! See you in Amsterdam :)
Sep 15 2017
It's wonderful to hear from you!!! Rigify has always been a tremendous addon and I'm glad you appreciate the improvements we introduced to make it even better.
Jul 28 2017
Jul 27 2017
More precisely we are referring to the "Rigify Type" property of pose bones.
You can set it up in the Bone Properties panel.
Keep in mind the following:
- As you know, when you create a metarig from scratch you can add a subrig sample hitting "Add Samples" in Edit mode. For each one of these samples though only one of the bones you generate will have a defined Rigify Type property. That's the root-of-the-chain bone.
- When you copy a bone in Edit mode, the relevant pose bone properties are copied as well. The "Rigify Type" property is no exception.
You mentioned two cases "basic.super_copy" and "basic.copy_chain".
When you duplicate a basic.super_copy, all the bones you spawn will have the same Rigify Type... but that's just a single bone chain!
A basic.copy_chain on the other hand, is a different story. The sample you get when you hit "Add Sample" in Edit mode is three bones long, of which only the first one (the root-of-the-chain) holds the "basic.copy_chain" Rigify Type.
This means that if you copy one of the others belonging to the chain you won't get a bone generating any widget.
hi! you can find the answer in the main task
Hi try to substitute the files in the attached .rar:
- make a backup copy of the files ui.py and rig_lists.py you find in rigify main folder
- unzip the content in the same folder and overwrite
@Luciano Muñoz Sessarego (looch)
Could you please try the attached patch?
The problem was probably the Panel draw method calling a function that's importing modules at runtime
First time that I notice it, but there is a slight lag in that specific panel update... the poll function probably needs a recode, I'm checking
Jul 26 2017
Jul 24 2017
Jul 2 2017
Of course not, we need a script that fixes rig_ui at least. Functions and operators definitions should be moved out of this runtime generated file as well.
Jun 30 2017
Ok, I'm narrowing down the issue step by step:
@Maverick (maverick) I don't agree with the last statement
Follow these steps to clarify:
This is an example blend. Try to snap FK/IK and then slide IK_FK slider to 1. You'll notice a flicker on hand_fk
Jun 10 2017
I checked the commits after the introduction of Legacy mode.
Legacy mode was introduced as of 14/05/2017. After that date no commits were pushed regarding the original legacy "Human" (or Pitchipoy) metarig. Besides in that case (enable Rigify legacy mode, create a Human non-pitchipoy metarig) the fkik slider is on the hand control so it works as expected.
The problem regarded Pitchipoy rigs only, where the fkik slider is a property of a hidden MCH bone (e.g. MCH-upper_arm_parent.L)
As Ivan pointed out, this problem has been addressed with the introduction of the new Rigify 0.5 rigs and Legacy mode.
I did also check the Pitchipoy Rigs before the legacy mode commit, and still, the fkik silder is on the hidden MCH.
Jun 8 2017
Jun 2 2017
Jun 1 2017
May 14 2017
May 8 2017
The problem was the Auto run Python Scripts flag. When this is disabled drivers are skipped...
Apr 26 2017
Nov 1 2016
It was nice to meet you in Amsterdam. Can't wait to start working together on rigify!
I agree with you, the best and easiest way is that you propose patches so we can test them and then push on the addons repo.
Oct 16 2016
I recoded rig_ui_pitchipoy_template.py and pitchipoy/limbs/ui.py to account for the mixed case and the operators missing the "pole" property.
Please find it in:
You are right, I didn't consider the mixed case. I'll take care of that
Oct 12 2016
Oct 3 2016
Sep 28 2016
Sep 22 2016
I removed the dead code. please find the fix here:
Sep 14 2016
Thank you Johan!!! That's fantastic :D
Sep 12 2016
Aug 8 2016
No I didn't get any feedback up to now, but the code has been extensively tested during the movie production so... as you suggested, I pushed the 4 commits (I added a last one about front and rear paw limbs):
Jul 29 2016
In order to test the last two commits you can use a normal Human Pitchipoy rig.
About the paw limb refer to the cat rig made by @Ivan Cappiello (icappiello):
After some struggle I've added a new branch called rigify_fixes on which we can work happily ever after...
You can find the following 3 commits there:
Jul 26 2016
Hello! I'm about to commit the paw.py fixes, do you prefer that I push the current master on origin and branch from there, or I keep on committing on master?
Jul 25 2016
We will proceed (tomorrow probably) with committing the improvements on the Paw limb(s), then we will discuss the fk/ik switch implementation on pitchipoy rigs which is just a notch more complex.