Questions Bugs Suggestions

[ViM]

Hi guys,

I have multiple topics I want to talk about and I don’t want to start multiple conversations and spam this forum. Also, I’m not able to include multiple images, so no images.

Questions.
Q1. Can the elbow/knee follow Global or something else, not just the arm? Atm it has a life of its own and it auto-follows, is it possible to make it static/space switched to local or global? [edit: nvm, I was able to solve this with space switching local or global for the up vector.]

Q2. How would you guys handle an octopus tentacle that needs to function as an arm, or leg, and interact with the floor, objects, so on?

Q3. I can’t manage to make sense of the coloring. Sometimes custom controllers get auto-colored, sometimes they don’t, depending on whether they are mGear generated or not, or if they are Index or RGB based. Atm I can’t tell why or when things will be colored as expected. Is there something different about mGear ctrls that allows mGear to color them correctly?

Bugs.
These looked like bugs to me, but in case I’m doing something wrong, maybe they could qualify as questions rather than bugs.

B1. Switch FkIk often over range doesn’t work unless it bakes the entire range. By default it’s set to “only keyframe frames”. So the default doesn’t always work, the full bake normally does. Also, it resets settings all the time and doesn’t detect IK or FK mode. So when in IK arm, it would make sense for that menu to show switch-to FK by default [the long button right above Space Transfer].

B2. Mirroring often doesn’t work. Get the biped template and rig, or just rig a simple arm 01, duplicate sym. Pose left arm, mGear Viewport Menu > Mirror or Flip. Doesn’t mirror or achieves the wrong pose. [Edit: I’ve figured out meanwhile that the tr and rot inversion/mirror settings need to be set up manually or in a post script after rigging. I believe the default settings for the arm, or leg, or the entire biped template, should work correctly by default, without needing a fixing script and without asking the user to go ctrl by ctrl and check each tr and rot setting.]

B3. Chain 01 only builds FK, the IK or IK-FK rigs do not work - there is no way to bend the IK chain, there will be a straight, stiff line of joints.

B4. Some custom controllers lose their shapes when Extracting and end up as simple groups stored under the controllers_org. Mass extracting controllers can be a recipe for disaster, with controllers disappearing after rebuild.

Suggestions .
S1. You have support for 2joint elbows/knees, but instead of building 2 joints that split rotations in 2, you add 2 joints to the already existing elbow joint, which creates a messy, tight spaced 3 joints. Look at Fahrenheit Digital for an example of a 2-joint elbow/knee, where the rotation is split.

S2. The wrist end effector is kept in the joint hierarchy, and creates 2, very close, tight joints. Oddly, the foot setup doesn’t need to include the end effector in the guides hierarchy, but still creates 2 tight joints. The end joints shouldn’t be part of the deformers hierarchy/skeleton/skinning, and skinning 2 joints that are very close to each other is difficult and not a good idea [maybe 1 of 2 can be skipped, but that defeats the purpose of having those joints there; joints are a deformer, not a generic node in the hierarchy].

And S3. Unclear, confusing naming. Pls consider renaming these, for clarity:

• Space Switches are currently called Reference Arrays, in the guide settings. Otherwise, generally this is named space switching.
• Range Switch is renamed to Space Transfer is you open its menu. The “only keyframe frames” space transfer attribute is odd English, I suggest you rename it to Smart Bake. And rename everything here to: Match FK-IK / Match FK-IK Range. Not transfer, not switch.
• Selection Sets are called Groups, which is not Maya terminology.
• And the Synoptic is the AnimPicker I think.

Cheers!

[chrislesage]

This giant list isn’t the most productive format to get any of this addressed. Especially when you’re ninja-editing the post too, instead of replying. A useful bug report won’t be considered spam. So please feel free to make separate topics.

For the bugs, you need to provide more information so it can be recreated.

Q1: Yes. It’s the “Pin Elbow Reference Array”. Add whatever spaces you want. What does “a life of its own” mean?

For all the bugs, I suggest making one topic per bug, and actually displaying information that would help recreate the problem.

B1: “Doesn’t work” is not enough information.

B2: “Doesn’t work” is not enough information.
B2 commentary: I get that you’re suggesting default settings for inversion/mirror. And perhaps you’re right, and that should be the default. But do keep in mind that Shifter isn’t meant to be a magic one-button solution. It’s part of mGear which is a full rigging framework, and you should expect to be doing some setup and definitions yourself to meet your specific needs. Everything can be scripted. You can save your own templates. You can modify your own custom components.

B3: They “do not work” isn’t enough information. It looks like chain_01 only builds FK. I’m not sure what the rest of this comment means. No way to bend? Can you demonstrate what you mean? (Again, bugs should be their own thread, which is why I originally suggested you not to bury your comments in a long discussion.)

B4: I’ve never experienced this. I’m not saying it isn’t happening for you. But you need to demonstrate how it’s happening, or share a rig file where it can be reproduced, otherwise there isn’t much that can be done.

[ViM]

I edited my content but did not remove text, only added. I didn’t see any harm in editing text as long as there was no reply. Thanks for replying btw! I will not start making bug reports though, I’ve added one that I felt was more significant. I’m not allowed to post multiple pictures in a post anyway, and writing bug reports for each bug I find is time consuming business. ^ ^

About Q1, it’s not the pin elbow reference array, it’s the pole vector that locks the pole vector in place, so it doesn’t have “a life of its own”, or in other words: so it doesn’t behave unpredictably, following other controllers, like the Wrist. I don’t think that kind of automated behavior is good for animation, but it may be a personal choice. I think almost everything in a rig should be segmented and static, without automatic behaviors. As an animator, when I plant something somewhere, I want it to stay there until I move it again, it shouldn’t auto-move on its own.

About B1, it’s a simple fail case. Pose an IK arm in 2 different poses [set 2 keyframes 100 frames apart], Range Switch [in fact… match] IK to FK with default settings. It will normally fail. More specifically, it won’t switch space, it stays in IK, and nothing happens, no keys are being created. I’ve seen it work once or twice, I don’t know why. Maybe like with mirroring, is there some setup that needs to be done for this to work correctly? I wouldn’t expect so, because if you disable the poorly named “Only Keyframe Frames” and bake/match on every frame instead, this works fine, the rig switches from IK to FK, and all FK arm ctrls are being keyed.

About B2, I spent an entire day scripting a fix that could work with a wide range of setups. It would be nice if you guys took mirroring into consideration when publishing components and either fix this problem or at least offer the user a tool for easy handling mirroring in general. Not only there is no documentation at all for the components or for mirroring, but it’s very time consuming to handle this, and it also doesn’t make sense for mirroring not to be handled correctly by components. There are 2 weird settings in arm components for example, that I haven’s seen explained anywhere: Mirror IK Ctl Axis Behavior and MirrorMid Ctl and UPV Axis Behavior. Miquel mentions them briefly in an intro tutorial on YouTube, without explaining anything about them. Well, these 2 settings only complicate things by changing rig behavior, but do not fix mirroring. At least the first one I disable all the time, and probably it’s safe to disable both…? But it would be nice if I could understand what they are trying to do.

About B3, again, chain 01 has 3 modes, FK, IK and FKIK. Only FK is functional. Like in the other cases where I said something similar to “doesn’t work”, I think the problem is so simple, it doesn’t really need detailed steps for recreating it. For example, create a chain_01, in Component Settings set the Mode to IK or FKIK, build rig. The IK will not be a functional chain rig, it’s broken, or as I said, doesn’t work. The FK chain, by comparison, is functional, and does what a chain rig is expected to do.

And let’s forget about B4… no biggie. Can be solved by deleting the broken controlBuffer and recreating it.
Cheers!

[chrislesage]

@ViM

I’m not allowed to post multiple pictures in a post anyway,

Ah sorry! I had forgot you mentioned that. I just boosted your member level, so you should be allowed to post multiple pics now.

@ViM

and writing bug reports for each bug I find is time consuming business.

Ah well. So is fixing bugs. This is a free and open source software, and community support is never guaranteed. Though Miquel does offer support contracts (according to the website main page).

@ViM

I think the problem is so simple, it doesn’t really need detailed steps for recreating it. For example, create a chain_01, in Component Settings set the Mode to IK or FKIK, build rig.

B3 - Well, see? You didn’t mention to set the mode. I didn’t realize that component could have IK/FK switching. Now that you mention the steps, I can recreate it and see what you’re talking about. But I don’t personally know if that is by design, or an error. It has been this way since at least 3.7.11. There are however several spline and spline_variable components.

@ViM

There are 2 weird settings in arm components for example, that I haven’s seen explained anywhere: Mirror IK Ctl Axis Behavior and MirrorMid Ctl and UPV Axis Behavior.

B2 - These mirror settings mean that the IK controls will either mirror when transforming, or they will move/rotate in world space, in the same direction. (What I don’t know is if this has any impact on the mirror tool functionality.)

Two separate builds to show the settings:

(I do like your Q1, B2, S1 notation though. This is actually pretty useful for multi-point conversations. I still highly recommend separate bug reports with information though. You’ll raise the chance someone will see it and take it on.)

[ViM]

Thanks Chris! Very useful info, especially thanks for explaining B2, the mirror settings.
I might give it some time in the weekend and rewrite some of this as bugs.

Meanwhile… B4 strikes back, with a vengeance. You asked for an example of what can happen to the control buffers.

They keep getting messed up, for no clear reason, even though I’ve added them one by one carefully. And this is not only a cosmetic problem, this rig will not build, it will fail to build the spine and neck, and without errors or warnings. I have a feeling that this may happen when tweaking guide settings… like removing the Bird IK or changing the number of arm divisions. But I’m not sure, it may be unrelated.

[Btw, naming suggestion, kill the Chicken, call it Bird, any flying bird has independent head ctrl. Or Independent Head IK?]

EDIT: Ooook I found the problem. It’s during mirroring controllers Left > Right. It kills some of my custom shapes, not all, a random selection… And they are nothing unusual btw, I’m using mGear ctrl shapes. I’m mirroring Left side ctrls… and it kills Center shapes. O o

[chrislesage]

@ViM

And S3. Unclear, confusing naming. Pls consider renaming these, for clarity:

• Space Switches are currently called Reference Arrays

I just came across a POST script I wrote that changes the names in the rig. I doubt very much that this will ever get changed in mGear. But you can change it in your rigs, so it is more friendly for your animators:

This is a snippet from one of the POST steps I run on all my rigs:

import pymel.core as pm

def rename_space_switch_attrs():
    '''
    Change ikref nice name to "Space Switch", etc.
    The default names are overly technical.
    This doesn't change the attr name, just the "nice name", so it shouldn't break anything.
    '''
    sources = ['ikref', 'rotref', 'rotRef', 'upvref', 'elbowref', 'kneeref']
    newNiceNames = ['Space Switch', 'Space Switch', 'Space Switch', 'Pole Vector Space', 'Elbow Space', 'Knee Space']

    for source, newNiceName in zip(sources, newNiceNames):
        for each in pm.ls(type='transform'):
            ikrefAttrs = [x for x in each.listAttr(keyable=True) if source in x.name()]
            for eachAttr in ikrefAttrs:
                pm.addAttr(eachAttr, edit=True, nn=newNiceName)

rename_space_switch_attrs()