Website Youtube GitHub

About naming shown in channel Host


#1

Hi Folks,
I found some component’s naming shown in channel Host is always “chain”. (see pic below .In this case ,I use shoulder component).
2019-08-21_113720

Is there any way to modify the naming shown in channel host?

Thanks for help!


#2

Hi Arthur,

In the guide settings, you have “Use Classic Channel Names”, which uses a unique name for each of them, instead of the component type.

In my opinion, this is not a good option for the animators, because it also changes all the other attributes to be unique as well. So for example, you cannot scrub both the left and right channels at the same time, because the attrs don’t match.

example attrs when using Classic Channel Names:
“armUI_R0_ctl.arm_R0_blend”
“armUI_L0_ctl.arm_L0_blend”

Example when Classic Channel is unchecked (good for animators).
“armUI_L0_ctl.arm_blend”
“armUI_R0_ctl.arm_blend”

So, if you want to customize it so the headers are unique, but the attrs remain the same, you’ll have to edit some code. I think you’d find the code that adds those attributes in

mgear_3.X.X/scripts/mgear/shifter/component/__init__.py

If you search for “EnumParam”, you’ll find a method like this. That would be the first place I would start to search from.

    def addFullNameParam(self):
        """Add a parameter to the animation property.

        Note that animatable and keyable are True per default.

        """

        # attr = self.addAnimEnumParam("", "", 0, ["---------------"] )
        if self.options["classicChannelNames"]:
            attr = self.addAnimEnumParam(
                self.getName(), "__________", 0, [self.getName()])
        else:
            attr = self.addAnimEnumParam(
                self.guide.compName, "__________", 0, [self.guide.compName])

        return attr

When classicChannelNames is off, it is using self.guide.compName in the enum list, which is the name of the type of the component, instead of the name of the component. You could edit it to be self.getName() there too. But I don’t know if that method is used in other important places that would affect anything else.


#3

So here is an idea to consider. I tested it, and it does seem to only affect those header attributes. Something like this might be more readable for animators.

Instead of underscores as the attribute name, and the component name as the value, I switched it to be the uppercase name as the attribute, and underscores as the value. And added the word “_SECTION”, which might be overkill. :slight_smile:

(But the animator attributes all stay the same.)

    def addFullNameParam(self):
        """Add a parameter to the animation property.

        Note that animatable and keyable are True per default.

        """

        # attr = self.addAnimEnumParam("", "", 0, ["---------------"] )
        if self.options["classicChannelNames"]:
            attr = self.addAnimEnumParam(
                self.getName(), "__________", 0, [self.getName()])
        else:
            attr = self.addAnimEnumParam(
                self.guide.compName, self.getName().upper() + '_SECTION', 0, ["__________"])

        return attr

new_attributes


#4

2019-08-22_104913

Hi Chris,
The code you provided works perfect! Thanks so much for the help.
Have a good day!

Arthur.


#5

No problem. I’m actually going to implement this in my rigs too. I always found it a bit confusing to see which section was which.

Would anyone else vote for this being a pull request to the official mGear? (Or anyone have any better suggestions than “_SECTION”?)

Also since the underscores are moved into the enum attribute, they can have characters that attribute names cannot, like dashes, or “=” or even unicode characters! (Which might be less safe for cross-platform international compatibility… so I wouldn’t recommend unicode characters for everyone. Just ideas here.)

Here it is with “========” and with unicode “Lower One Quarter Block” for extra readability:

image


#6

Oh I like this very much! The attribute names are much more helpful. As for the values they are all good. As long as the names tell us what it actually is instead of just the component type :slight_smile:


#7

That is a really good idea. I am taking note :smiley:


#8

I was testing those unicode characters on MacOS. Unicode characters don’t universally and safely display on every OS or localization. So this likely isn’t a good idea. Justin discovered, and I can confirm that on Windows 10 in English and French, they just show up like ?????????


#9

ops!! too bad :frowning: thanks for the heads up! :wink: