- User Since
- Jun 24 2016, 1:06 PM (155 w, 6 d)
Fri, Jun 14
can confirm that modifying the config as described fixes the issue (using 2.79b official and Troy's config with Brecht's edited line).
Thanks, @Brecht Van Lommel (brecht).
Sun, Jun 9
and these are the registered events for a single stroke in console
@Brecht Van Lommel (brecht),
i have drawn 3 strokes. All affected by the pressure issue.
here is the console output for the events:
Wed, Jun 5
seems blender is not aware that button exists though. Attaching a video to show what happens.
btw shouldn't be better to map basic keys like viewport pie menu to a key it's present in almost any language?
Tue, Jun 4
@JoshBowman (JoshyB) Thanks for the tip, compiled blender with that option and works like a charm with both Astropad on iPad Pro/iPhone and Inklet with Trackpad.
At least works for grease pencil. For other modes I think some more files should be edited.
Mon, Jun 3
@Jurek (solartistic) in the attached file the superfinger rotation axis option is set to "Automatic". this means rigify will calculate it through the average of the bone rolls. To work correctly the bones should be slightly bent.
You can also specify manual orientation from the option menu and specify the X axis.
@Annemie (MiminatorEndGame) basic informations are missing in this report.
You should at least write down the exact steps to reproduce the error or upload the a sample file.
May 14 2019
Gif1 - Colorwheel goes crazy
Gif2 - resulting values and sliders going crazy
May 13 2019
Can’t tell if was an intended fix or not.
What i can tell is that was working on e6acb4fba094 and is not working anymore.
I feel like i am writing this for the 3rd time in different words...
What’s missing in my report?
2.79 is affected. 2.8 seems work quite fine with replaced ocio configs.
As i wrote above this was not working in 2.79b official.
Used to work on e6acb4fba094 and some other previous nightly build downloaded from builder (unfortunately i haven’t saved all the downloads). But i still have e6acb4fba094 and replacing OCIO there makes both ARRI filmic and color wheels work.
If both versions are wrong it’s really strange that there are some versions where this was wrong and working, don’t you think?
What other information you need?
May 9 2019
@takeshi funahashi (waitinfuture) i am not sure to understand either the problem and the suggested fix you are proposing.
@Luciano Muñoz Sessarego (looch)
I think this thread is confusional. I suggest to split the single tasks in separate threads.
before doing it let's try to summarize and file this list:
May 2 2019
@JoshBowman (JoshyB), yeah thanks. That's why I was linking the topic. Hope some developer cares enough to have a look at it.
@Sergey Sharybin (sergey) it works with almost any pressure enabled software out of the box through inklet and Astropad (you can easily test krita). Believe anyway it should work just like pinching, zooming and rotating with two fingers on the trackpad are working using the regular APIs.
Apr 10 2019
i am closing this as resolved since after more than a week no more related issues are reported
Will move my proposal:
Unfortunately the script part is from rigify. So we have here 2 options in my opinion:
automatic: if rigify is enabled, and detects an old rig, re-generates the python scripts
manual: if rigify is enabled, and detects an old rig, displays the user a warning and the option to re-generate the python scripts
- in both systems the space switching is very limited, I modified a new rigify rig to allow multiple spaces in a more flexible way: with the help of @Julien DUROURE (julien) 's add-on to create space switches, with a bit of tweaking of the rig, now each controller has several different spaces that the animator would usually need like: head, chest, hips, cog (center of gravity), root. I have replicated the process manually but instead of a dropdown with just a slider that indicates different spaces like: 0 root, 1 torso, 2 hips.... etc.
Here is a sample video of the one i created with Juliens add-on.
Apr 6 2019
@Brecht Van Lommel (brecht) actually any macbook pro from 2016 to now has a forcetouch trackpad you can use to test it with inklet. This shares the same osx input and stroke event as astropad on ipad.
It’s very hard to believe that there isn’t any developer out there using a recent macbook pro.
@Brecht Van Lommel (brecht) who can this be assigned to?
Confirm the issue, just a metarig parenting problem. It's an easy fix, just need to re-encode metarig.
Mar 28 2019
the thing about the buttons is that FK2IK Action and IK2FK Action should snap all the FK keys to the IK positions, and the IK to the FK positions, but now it's vice versa. In contraposition the FK2IK & IK2FK Pose buttons are correct.
There’s a difference between the two functions. If you read the descriptions overing the mouse on the buttons it will be clear.
• The pose buttons are intended to snap, so ik2fk means snap the ik to the fk position.
• The action button are intended as bake, so ik2fk action means transfer the ik action to the fk controls. This is also similar to what the operator calls inside the code actually using blender’s bake operators.
Mar 25 2019
Seems there's more than one issue here:
"The buttons to transfer animation from one to the other dont work, also they are named incorrectly the one to transfer from IK to FK is named FK2IK and vice versa"
In my tests there's no error on newly generated rigs, but still seems it just does nothing at all.
This will require a more in depth investigation. Hope @Lucio Rossi (luciorossi) find some time to have a look at it.
This is more a backward compatibility issue.
The affected part is the rig-ui and Rigify tools python script generated in previous versions.
Mar 16 2019
Mar 14 2019
the addon by @Paolo Acampora (pkrime) posted in https://developer.blender.org/T57536 seems to address the issue in our tests. As for now it's destructive for the rig itself but can easily be modified to create a non destructive workflow like creating a data block copy of the original rig armature, make the bake on the reparented bones armature created by the script and after the export reassign the original rig data block to the armature object.
from the picture it seems some required leg bone is missing(deleted) or unpainted. I can't spot the heel.002.L (and .R) bone. This could be the problem but I'm just guessing since there are no information. Since the thread is not updated since more than one month and the error it's not reproducible I am closing this as invalid.
I am also point one more time that before reporting bugs users should have the good practice to read the wikis (that people take time to write) and check if the issue is caused by misuse of the tool rather than a bug.
rigify wiki here
closing this since it works now. @Alexander Gavrilov (angavrilov) can you open a task for:
another issue (it fails if the Widgets collection is selected)
and fix it if you can?
This is not a Rigify bug. Cannot reproduce it except generating from your file.
This usually happens when you remove/unparent/parent some face bones. Unfortunately the current face sample has this limitation: you can only move the bones to correct position according to your model. You cannot rename/unparent/remove any bone or the generate function will fail. This is going to be addressed in rigify 0.6 but for now the easiest way to fix is remove completely the face bones (make only armature layer 1 visible, select all bones on layer 1 and delete it) and re add a face sample (in edit mode select and add the superface sample). Then reposition the bones paying attention to not remove or reparent anything except for the small face bone that has to be parented to the spine.006 bone.
Moreover, you should either apply the scale in object mode since the armature object appears to be scaled up as pointed in previous posts.
Try to follow more accurately the rigify wiki
@neil richmond (neilford) you should probably change the tags or create a new task if you want this to be solved quickly.
This should be handled by blender itself onload. All armatures using shapes are affected. it's not an add-on related bug.
Since after a month no issue is reported and can't reproduce the breast problem I am closing this task.
Mar 12 2019
Just tested this successfully. I'd like to polish a bit the 'Feature Set' panel, but that's way over this task's topic.
Feb 23 2019
Feb 19 2019
ok sorted it out.
there are two misleading information in this thread. I'll post this for other people eventually coming here reading.
Feb 18 2019
@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 0.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 accepted to https://github.com/eigen-value/rigify/tree/rigify_0.6_beta
Feb 15 2019
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-uis should be deprecated in next rigify major update in 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. After some tests i know @Paolo Acampora (pkrime) made an ui picker with pyside QT that's working with 2.8. 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 in the next days 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.
Feb 11 2019
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.
Feb 8 2019
@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.