Multiple mapping channels confusion

I have an issue with multiple mapping channels.

Why would the checkmark get greyed out ? How do I add a new channel without affecting the existing ones now ?

Here I have an object with two channels, but a third one cannot be added

You can only uncheck the checkbox if there is only one mapping channel.

The new channel won’t affect the existing one.
Here’s the example.
TwoMappingChannels.3dm (663.9 KB)

The material has a color texture and a transparency texture.
The color texture uses channel 1. The transparency texture uses channel 2.

So I can move the transparency texture on the object without moving the color texture.


Can you add a third and a forth planar channel now ? When I try it, it keeps overriding channel 1

I have an object with two cylindrical channels and I cannot add a third one of any kind (box, planar, or cylindrical)

1 Like

No, when the model is saved and reopened. Reported as RH-67348, thanks.

1 Like

Thank you kind sir :slight_smile:

1 Like

Kelvin, is there a UI reason why multiple channels aren’t on by default ? Why is the user being bothered with the question at all and then having to maintain the checkmark intelligence (and greying it out) instead of having the channel-list visible at all times ? … it just means most of the time the list will contain only one channel. No ?

A second point: Pressing F2 or double-click on the channel name does not open it for editing (like the channel number does). Also, the term “unnamed” doesn’t appear in the Name input box. The name input box is so faint that I kept missing it even existed; while looking for a way to rename a channel.

I think only one channel is used in most cases. It’s like simple and advanced settings.

I think the channel number can be edited on the list because it doesn’t have an edit box in the panel, and it uses a standard Windows UI element working with the F2 key.

This is kind of a UI rule. Object name for instance.

This should be because you have some UI colors customized. I see the problem if I change EditBoxBackground to any other colors in advanced settings. Reported as RH-67364.
Let’s fix the UI visibility issue instead of making pressing F2 key work for editing the name?

Did you change this color? If not, can you share your settings-Scheme__Default.xml in %AppData%\McNeel\Rhinoceros\7.0\settings?

Send me a private message with the file attached if you like. Thanks.

That particular color isn’t changed on mine, but other colors are.
Basically the outline of the other inputs (list boxes) are more vivid giving the impression they are editable, but the name is faint enough that I kept missing it existed.

I suppose it’s no longer a problem once I know about it. Maybe I can find the color of the input box outline and change that.

About the name “convention”. Sure it’s a Rhino convention, but having empty fields without sample text in them is often a minus on UI design. It is also inconsistent because then the concept of empty is displayed in two different ways either empty or “(unnamed)”. Why did someone feel there is a need to spell out “unnamed” in only one of those two locations if they felt mere emptiness would be sufficient ?

1 Like


The RH-67364 that I reported is because the color has the alpha value set to 0 that makes any colors, other than white, transparent.

Sorry, I don’t know how to answer this question. I can only let the developers evaluate this “issue”. (RH-67395)

1 Like

Interesting observation on the alpha channel. Thank you for that !

1 Like

As I read the discussion on RH-67364 one thing I’d add is this: why are borders A, B, and C different on the same color value ?

Border B seems to be the most prominent and border C is the greyed out version of border B … therefore border A implies to the user that it’s also a greyed version of something.

Because they are different types of Windows UI elements.

(A) allows entering text. Same with the xyz position/rotation boxes.

(B) and (C) are both dropdown list boxes, the enable/disable state makes the difference. If you select a Box mapping, (C) will be enabled and the border color is the same with (B).

Now I see your name box has low visibility because “Windows color 2” is set to white. :grinning:

… but why does that justify them having different border intensities ?
They are both elements that allow user interaction and with user inputs the convention is anything in FAINT-GREY means it’s disabled.

So, when Box A is fainter than box B it ought to mean something, the same way that Box B being different than box C means enabled/disabled.

If you are trying to convey disabled status to the user in BOX C then you are defeating it by box A. So you are sending mixed UI signals.

Sure, the focus is on the border of the boxes though; as in, I already know the window color is white. Still, doesn’t justify the variety of intensities … and the drop downs having unique visibility over other inputs.

Most Rhino UI elements apply Windows standard styles that might not be customizable in Rhino.

UI colors could be customized in old Windows versions from this dialog box. Looks like it’s been removed, or can’t be easily found, in Windows 10.

Fair point.
In that case we should see the same border inconsistency on the Windows UI (between input box borders and drop-downs), but we don’t.

Windows Explorer → No difference between input box borders and drop-downs

Settings → Also no difference between input box borders and drop-downs.

It is obvious Rhino is not updated to use some styles of the latest Windows UI. Anyway, I added RH-67412 for developers to evaluate.

1 Like

RH-67412 is fixed in the latest WIP

1 Like

Thanks guys.
(To clarify. That fix is on the Rh8 wip, not the Rh7 nightly)

Correct. (I didn’t see a question ? mark here, so I might be muddying rather than clarifying). It’s only in the RhinoWIP.

1 Like