Member of the Animation & Rigging module
- User Since
- Sep 17 2007, 11:10 PM (713 w, 1 d)
Wed, Apr 28
If I understand correctly, I agree, Max and Min values are set by the user for a reason so they should always clamp the value.
Apr 14 2021
Hi! But why would you remove uniform scale?
Mar 16 2021
Hi @Sybren A. Stüvel (sybren)! Well, I have been involved in many of the discussions regarding these features. I would welcome any improvement in bbones as there is a lot of space for that. These features look really nice, as they simplify the setup and at the same time they enable us to add more complexity to the deformation of bbones.
Mar 1 2021
Jan 17 2021
Looks good, yes. I don't think anyone could be using preserve volume + scaling as part of their daily workflow , unless they are doing some weird compensation. Therefore, any improvement is welcome.
Jan 12 2021
Ok, so I've also been thinking about this too and as Demeter mentions, all of these solutions still have the original problem of being shared across modes.
Jan 11 2021
Ok, so I had not worked with master in a while and I had to check what all these changes do, so correct me if I'm wrong in anything that I say...
Dec 17 2020
OK, as I don't own this task, I don't think I can add subscribers??? haha, you guys do it if you can.
I'm gonna take the liberty to add Campbell and Daniel Lara to the conversation because I think both worked on this topic in the past, but I don't remember what solution they got to...
Dec 10 2020
Oct 9 2020
Nice! Having all these new options is great!
Sep 29 2020
@Sybren A. Stüvel (sybren) ok, I'm not sure what to say here. You're right, I was testing 2.83 and 2.90 and it didn't work there, but the behavior is different in master.
Sep 28 2020
Sep 15 2020
Nice to see it works within bone space!
Jul 10 2020
Cool @Demeter Dzadik (Mets) ! Yes, that's what I was imagining. So if you have this script referenced within a custom property, does it work when the character is linked?
Hi! Ok, here go my two cents..
Jul 1 2020
Jun 30 2020
Star Wars Prequels shouldn't exist, but this patch should :)
Jun 29 2020
Oh no this is good, I was criticizing the current (new) layout actually, never mind.
My only suggestion would be to keep the horizontal layout for the source and destination axes. Like a column for max X and min X, a column for max Y and min Y and a column for max Z and min Z. It's harder to visually understand which axis you are working with in this all vertical layout. So I would keep the original 3 columns while keeping the vertical layout for the rest of the UI, which looks cool.
May 25 2020
OK, well, I understand that the patch isn't compatible with the target bone thing.
Ok, about functionality, if the Fallback value is similar to scrubbing the timeline of the action, I can think of the following functionality example:
Ok, here I'm bugging you again with the same thing... But, can the fallback value work along with the target option? I think people could find many different ways of using this if both options could coexist and interact with each other.
May 21 2020
@Anuar Nor (anuarnor) I don't know, I haven't tried the patch, if it's only a subrogation and it can't interact with the bone transform, then what I said doesn't make sense. On the other hand if it is indeed capable of interacting with the bone transform, you could use the Fallback value driven by something else to achieve different effects.
May 20 2020
And if that slider can interact with the bone transform settings, it will make everything even more controllable.
May 15 2020
Guys, maybe I'm understanding things wrong, but there seems to be a misconception here. I don't think the 'Armature display type" label should be changed. It is in fact only a display option, it doesn't affect the functionality of bones in any way. So changing it to just Armature Type would imply that setting it to bbones or stick would make the armature behave in a different way when it doesn't.
Apr 30 2020
I don't know guys, Blender is all about flexibility and control. I wouldn't restrict what they users might be able to do just because of a UI issue. Users always find unexpected ways of using features, so having more options is better in my opinion.
I don't fully understand why you are suggesting changes in the UI. Why just not leave it as it is? I would even have the fallback option enabled even when you do have a target. That way you could have the normal behavior of the constraint, driven by a bone, but you could also counteract the effect with a driver on the fallback value.
Apr 28 2020
This looks interesting, to tell you the truth, had never noticed this behavior before. Maybe because I mainly use location for my facial rigs and not rotations so much. But yeah, it definitely looks like the desired result.
Apr 18 2020
I don't know @Stanislav Ovcharov (Stan1) , here I tried and it worked on FK and IK also.
Guys, ok, I know what it is, but I don't know why the behavior of blender changed with it.
Apr 16 2020
@Philipp Oeser (lichtwerk) BlenRig doesn't use coding in the armature, it's a simple armature, so if there anything that is not working with it and blender tools, I guess it should be fixed in Blender.
Jan 28 2020
Mar 25 2019
Mar 22 2019
Oct 19 2018
Andy, well, yes, the thing is that you've gotta have a control armature and a deformation armature. So, in the control armature you set all the constraints up, spline IK and stuff. When you have everything working, you create the deformation armature that consists of bones that might be parented just to the root so that they don't have a child/parent hierarchy. You then add a copy transforms constraint to each of those bones, pointing to the spline IK bones of the control armature. That way the deformation armature will mimic exactly what the control armature does, but it won't have a hierarchy that ruins the export.
From my experience, you might want to use a copy loc + copy rot + copy scale + damped track + stretch to constraint on each of the deformation bones, instead of just a copy transforms constraint. This has given me better results on export.
Finally for exporting, you just select the mesh and the deformation armature, you don't export the control armature.
Andy, what I mean is that all bones should be parented to the root bone or some bone that doesn't scale. When you do that, the result is more or less reliable, although it's never 100% correct for some reason.
Oct 18 2018
I agree with Alexander, the inherit scale option shouldn't be turned off by default. You want it to be on in 99% of the cases.
Jun 13 2018
No Aligorith said he looked into it but couldn't figure it out. Hopefully he can see about it again soon.
May 18 2018
Not right now! :D
May 16 2018
Regarding PyController Removal + Drivers/Custom Properties Creation Script thing , even though the rig works without it, I realized that the animations in 2.79 are keying these api defined properties, so I should add the script with the drivers trick anyway so that animations work properly.
Apr 15 2018
Apr 13 2018
Apr 4 2018
We should subscribe Aligorith to this bug :)
Yes, this is a general issue with baking. It happens when you scale a parent bone, for some reason the scale affects the transforms of the child bone in a undesired way. I'm attaching a simple example. The armature to the left has constraints, the one to the right is the baked result. This is a really big problem for exporting to game engines.
Feb 15 2018
Feb 1 2018
Jan 13 2018
Hi Adam! Thanks for the link!
Jan 12 2018
I'm having the same problem when trying to export a complex rig to FBX. From what I can see, the problem could be related to the scaling of the bones. In other words, the scale of the parent bone affects the transforms of the child bone, thus, rotations end up looking totally sheared. I really don't know what kind of math could solve this, but it seems a pretty nasty issue if you are exporting things to a game engine.
May 24 2017
Apr 13 2017
Nov 24 2016
Nov 15 2016
Aug 27 2016
Jun 11 2016
May 13 2016
Damn, typo in the title, I meant "flipping parameter"
May 9 2016
Mar 23 2016
Yes yes, I mean I'll have to ask Bassam to see where the heck those operators are in the addon, haha.
Mar 22 2016
Mmmm. I just use the copy loc rot and scale operators from that addon, I should have to go into the addon or ask Bassam to see if I can append those operators to my addon.
Sep 4 2015
Mmmm well I don't know if this helps but if you unparent 2 from 1, the offset is solved.
Bastien, but why is this corrected by 2.70a? At least from a user point of view
Oh man I'm so sorry, I thought I had deleted the rest of the bones!!!
Mmmm, no actually I don't know of a method to do so. Some time ago I spoke to Zanqdo about this and he also told me that he had seen such behavior with the Apply Pose operator, like if it messed up some things.
Sep 3 2015
Yay! I've been wanting this for ages! :D
Jul 12 2015
Jul 8 2015
It's the same result with the 3 options, normals only, edge or face, just try it in the file I attached.
Jun 16 2015
OK, I think I've found the bug!
Apr 18 2015
I must also say that every time this happens, I'm editing an objects that has several modifiers... so perhaps it would be a good idea to check if modifiers could somehow cause the propagation process to not work properly?
Oh, that's interesting!
Apr 16 2015
Apr 7 2015
Ok you win, just don't make blender slower :p
OK... well if it makes things simpler, I would also contemplate the possibility that the breakdowner doesn't take into account custom properties!
Apr 1 2015
If I understand this correctly, the undefined results causes a crash.
Mar 17 2015
Mar 4 2015
Dec 6 2014
Jul 23 2014
Keep the fix, I'll deal with Mariomey later :p
Jul 21 2014
Yep, old behavior was better and I relied on it too. -1 for mariomey, I will take care of him when I see him in some conference....