- User Since
- Jun 24 2016, 1:06 PM (138 w, 4 d)
ok sorted it out.
there are two misleading information in this thread. I'll post this for other people eventually coming here reading.
Mon, Feb 18
@Alexander Gavrilov (angavrilov)
still no luck with your repo and 2.79 same os as above:
I've got a feeling you are under an impression that https://github.com/eigen-value/rigify/tree/rigify_0.6_beta is for 2.8 - that's wrong.
@Damien Picard (pioverfour) please download the 2.6 beta and test it. Should be updated to your recent pulls (except for pantins related commits). If it works then it's os-related, if not, you probably did some modification to without stashing the related commit, so in that case we need to pull that too (without pantins related commits).
My external rigs work with the expected minor modifications (mainly the matrix multiplication operator).
This is happening way before, just clicking on the add-on enable button. So to be clear rigify is not loaded at all.
I start a public request to commit third-party contributions already
Fri, Feb 15
I wonder if we can at least speed up committing the already accepted patches (including custom rig pack support from @Damien McGinnes (damien) Picard (pioverfour) that is directly relevant to this bug)
@Brendon Murphy (meta-androcto)
2.8 is a release with big change in critical areas.
Python rig-is should be deprecated in next rigify major update my opinion.
Still is not clear how/if/when armature system is going to get a redesign. We discussed with the foundation several option of pickers and ui implementations for armatures. All those required ui hacking to work in the viewport (2.79) and we abandoned the project. Until armature plans for 2.8x are more clear i'd put on hold any big effort in changing something is going to be abandoned anyway.
i'll try to have a deeper look on what happens here anyway.
The only bug i can confirm is misplaced tail tweak layers. It seems i forgot to set the spine property correctly. This is an easy fix even for the user, just select the bone in pose mode and in the 'Rigify Type" tab just deselect layer 2 and select layer 5. This will enable the 'spine tweak' layer in the rig ui and place the tweak bones accordingly.
Mon, Feb 11
Well, if you were an official maintainer of a module in the C core of blender, I would have already asked Brecht or Cambell to review it instead, and they would likely have done it. This is basically what happened with all my recent animation and NLA patches. Being an official maintainer without actually doing any code review is holding the module hostage.
being the official maintainer implies a responsibility for timely review and intergration of changes contributed by others.
Fri, Feb 8
@Luciano Muñoz Sessarego (looch),
i think there's a misunderstanding about rigify samples, metarigs and rig types.
Dec 18 2018
@Brendon Murphy (meta-androcto)
can you explain why the particle option has been deprecated?
i find it very useful. Just reinserted the line removed by this commit and seems to create no problem at all in 2.79b.
Is this option really causing issues or what?
Dec 7 2018
Nov 6 2018
Sep 10 2018
There is a double deformation problem in the foot after generating
Aug 27 2018
Aug 19 2018
rigify is not involved in the issue. The metarig is exported/imported through BVH import/export add-on. Until rig generation (i.e. press the 'generate rig' button) there will only be a simple armature object named "metarig" in the scene. It's not any different from handling any other armature object.
Aug 3 2018
Hey @Luciano Muñoz Sessarego (looch),
The feature is there. If you switch to edit mode, in the tool panel you will find a 'Rigify Dev Tools' panel displaying the 'Encode Metarig to Python' and 'Encode Sample to Python' buttons.
Oct 25 2017
Once created, can the pivot point be modified?
(As in version 2.78)
i think you refer to the original non-stretchy spine since in the 2.78 the super_torso_turbo had the exact same behavior (plus lots of bug and limitations). That kind of spine has been replaced by the new one as default. The only way of using it for now is enabling the legacy mode and use the old method.
Sorry but I can not find the pivot slide. I selected each bone in the spine and tail and found only "head_follow", "neck_follow" and "tail_follow". Could you tell me the name of the bone?
The spine of the cat looks very good. Should the "Basic Quadruped" or wolf spine work in the same way?
indeed it should. And... it isn't. Seems the problem is a prop on the metarig.
I can confirm the issue. Trying to rollback to the commit that broke it. Will report results asap.
I'm not sure that the spine works well (quadruped rid 2.79). It has only two bones to control the curvature. It is complicated to bend the spine. Sorry for commenting here, I was not sure about reporting this as a bug. Would you mind checking this out?
Oct 10 2017
Cannot confirm issue. The problem is related to incorrect delete of face bones. All face bones are child of a single bone named “face” that is placed on the same position of “spine.006” (the head bone). If “face” is not deleted and has no child bones (i.e. All face bone are deleted except “face”) the generate process will raise an error. As described accurately in the rigify wiki, all face bones are placed on armature layer 1. To correctly remove all of them it is suggested to make only layer 1 visible, select all bones, and then delete it. if done this way no error will be raised and the rig will be correctly generated.
Please read the wiki before posting next time, maybe you can find an easy solution without waiting for answers.
Sep 15 2017
Hello @Nathan Vegdahl (cessen) ,
thanks for the feedback.
Aug 6 2017
@Rombout Versluijs (rombout), the header was done before the documentation, so the only chance is you missed it.
I think there are only two different scenarios here:
- the user has blender2.78 or previous. In this case he can easily see the bundled version is 0.4 and mismatches the documentation header. The documentation and release changelog state also with extreme clarity what's changed in 0.5 (Please Read: What's new in Rigify 0.5) so if the feature you are looking for is in 0.5 updates list he just grab the 2.79 and goes. As long as he can read english i can't see a real problem.
- the user has blender2.79 or newer. The problem doesn't exist at all.
@Rombout Versluijs (rombout) is the official rigify wiki page and, as i wrote previously, there's no other one since it documented for the first time in 0.5. Please look further before posting next time. And stop posting here if your question is not relevant to the topic and you already had support.
@Rombout Versluijs (rombout), maybe you missed the first lines of the page. There's a header that states the version of the add-on and the blender release.
Aug 5 2017
@Rombout Versluijs (rombout)
Rigify 0.5 is bundled with blender 2.79. The documentation is referred to the upcoming 2.79 release. Since 0.5 is a major change and the old rigify was never documented and its code is going to be deprecated anyway, we decided to refer the documentation explicitly to Rigify 0.5.
If you want to test it grab your test build here: Blender 2.79 RC1
Jul 28 2017
@Karlis Stigis (karlisstigis)
Another option for the child of problem is having a look at new limb features at: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Rigging/Rigify#Limbs
In particular, if you use the IK following option setting it to 0 (Zero), the hand will not follow any part of the rig anymore acting like any other object in the scene, so when the child of constraint is turned off that position should be retained. This could help in particular situations. Keep in mind that this is a boolean value so no interpolation can be done. Moreover this could not work in an already animated file, but i thought it might be useful while planning future animations tough.
The main one was with the rig layers panel which after linking all those characters in the scene was not showing up for some of them and for others there was as many panels as there where characters.
@adam earle (adamearle),
your last post refers to a separate issue. Please do not continue posting in this thread if the content is not related to the bug report you opened, especially if the thread is closed and you do not provide new and useful informations about the reported bug.
Moreover, before opening a new thread, please try to use the search field or google for your query.
If you did you'd probably found this:
Jul 27 2017
I can't conform that.
It could be related to some script running in background, or just a graphic driver issue.
@Lucio Rossi (luciorossi) @Brendon Murphy (meta-androcto) Can anyone else please confirm this is happening?
@adam earle (adamearle),
first, take in consideration that all the first part of your post is not a bug report. I could take it as a sort of design proposal. I'll take the time to answer anyway but please next time consider that a bug is considered something the program is explicitly meant to do and doesn't.
Jul 22 2017
A Vertex Group doesn't appear until you click in the view port and the bone seems to have no weighting.
Jul 3 2017
@Bastien Montagne (mont29) since 2.79 is going to be last stable build till the official 2.8 release, i thought it could be worth a look at this patch since, even if doomed, BI will stay as long as needed to make 2.8 stable. What benefit could come from not having a workaround for that issue in 2.79 as long as it doesn't break anything else?
@Paolo Acampora (pkrime), i remember you wrote for us a patch to fix that while we were rendering our animated feature GL previews. I think it's here https://developer.blender.org/T48983. @Bastien Montagne (mont29) We are stil using it in studio, even if rejected (and still unclear to me why) i think it could be at least a good starting point to address the issue, can you please consider it?
Jun 30 2017
After a first look it seems something has changed in the way blender handles the snapping functions.
Jun 29 2017
I can confirm the issue. Causes are still unclear. We are investigating right now.
automatic works as designed.
The option is on the limb's first bone in the metarig. Just select it (upper_arm.L i guess) in pose mode and switch from automatic to the axis you want. Default is X. Then you have to take care of bone rolls though.
Jun 23 2017
hey @Brendon Murphy (meta-androcto) can you please have a look at this?
Jun 10 2017
closing the tasks as resolved since rigify 0.5 addresses all 3 issues.
i am closing this task as invalid since it was already reported, fixed and, after a double check on commits there's no trace of other issues introduced by recent commits.
I remember the issue. We never fixed that in legacy mode. Legacy mode is intended to maintain the legacy feature unchanged during the migration to new 0.5 code.
The reported issue is related to rigify's original design, we took care of it redesigning the rigs in 0.5.
there's more than a issue here.
May 29 2017
@Julien DUROURE (julien) with the next 2.79 release all your requests should be addressed. Have a look at the release notes and follow the upcoming wiki page to know how to use it.
May 15 2017
About the rig-id part:
Seems you are writing the rig-id on the meta-rig and then the meta-rig passes it to the rig. Even if the idea seems cool at a first glance, again, the consequence of this change are breaking other rigify features.
It seems you never generate again the rig-id on the meta-rig once is created. This is bad. Rigify metarigs are created to be shareable through blender files. For example, you have rigged your character with rigify, the next one is similar to the first, so you append your meta-rig form the first to the second file, then edit it as needed and generate. Standing to your patch in this case the metarig will bring in the second file the same rig id and - even not finding the rig itself - will always generate rigs with same rig-id. Since there is no rule to know when to re-create the rig id, you will force the user to manually delete it.
The idea behind the patch is good though.
I'll try to think a workaround for this second part, but for now -as this patch is submitted - I consider this part rejected too.
from a first look i have some big concerns about rigify WGT patch proposal:
looking into the patch right now.
This is fixed in 2.79. Now the property is moved to a visible bone laying at the base of the limb.
- New rigs created starting from 2.79 code will work automatically.
- Old rigs should be upgraded re-assigning the rigify-types property in pose mode.
Feb 8 2017
This is the metarig i re-created from the ORG-bones in your file. That's how the arm bone should be oriented to make it correctly work. You can restart from there.
on the the sample file i see more problems than you reported. Most of the controls are turned in the rest pose and there is a dependency cycle on the right leg. I suspect the metarig is misaligned or some modifications were made after the rig-generation.
I can see from the ORG-bones (that are the exact metarig copy) that your arms have bone rolls not correctly aligned. the Z-axis should point downward, in your rig instead is flipped.
You can go in the front view (numpad 1) select the arm bone-chain on the metarig and hit CTRL+N > Recalculate Roll > View Axis. Then regenerate the rig.
Jan 28 2017
@Luciano Muñoz Sessarego (looch)
please provide the blend file with the metarig that's generating the error. And a detailed description.
About the finger, have you tried to replace basic fingers with the pitchypoi super finger?
That should do exactly what you asked for.
Jan 27 2017
Not sure it's a complete solution tough.
Then if hand_fk is not visible the problem remains. I guess exposing a separate bone at the limb's first bone to handle all the properties is a better idea. This bone can be on both FK and IK rig-layer meaning it's always visibile if at least one of them is.
Will look further into that.
You can use the method you prefer. Rigify can make mixed rigs.
- Add Human-Metarig
- in edit mode add a sample face
- parent the face bone to the head
I can confirm the bug. Looking if @Joshua Leung (aligorith) 's fix is breaking something else.
Following those steps i can't reproduce this error on 2.78a. All DEF and ORG bones are on the respective layers and correctly displayed.
Jan 24 2017
We could have a fix that adds the feature you requested on the pitchypoi leg.
Jan 23 2017
@Julien DUROURE (julien)
I looked into the FK toe snap problem.
@Julien DUROURE (julien)
i will have a look at the standard rigify bug. But that part if the code is untouched since nathan coded it.
@Julien DUROURE (julien)
The firts 3 reports should be all grouped into a single thread since are all related.
Jan 22 2017
@Luciano Muñoz Sessarego (looch):
Yes all our work relies on the pitchipoy code.
@Luciano Muñoz Sessarego (looch),
All the major changes presented at the conference are already in master since 2.78.
Sep 22 2016
This is the commit of an urgent fix that will make the snapping functions work with new additions to the super_limbs:
Sep 12 2016
The feature suggested by @johan tri handoyo (johantri) is now committed.
Aug 20 2016
i tested your rig.
As i wrote in the previous post, this cant't work "out of the box" with rigify rigs.
Aug 19 2016
i maybe didn't understand well what was done on the rigging side on the garfield series, but i suppose it wasn't done in blender. About your method:
Jul 19 2016
adding the missing super_palm.py file.
@Campbell Barton (campbellbarton) @Nathan Vegdahl (cessen) the inherit scale modification is necessary to prevent undesired results after non uniform scaling on the hand control. If you want to check it just generate the rig leaving inherit scale values active, then rotate the hand and scale it non uniformly (ex: S Y Y) and you will see the fingers controls and deform bones exploding in all directions. Anyway our modification is applied to a new rig type with a different name. The old one is still there and will not be affected by the modification.