If I am working in a display mode in which Shade-highlight is true, and I am working with a command like BlendSrf trying to pick an edge that is right up against something else, I kind of like that the entire surface is now highlighted in an ambiguous pick, but it makes it hard to see that Rhino is also showing me the edge that I am trying to pick because it is also in the same highlight color, and I miss seeing those arrows as confirmation. Perhaps the arrows could get some help to visually stand out better?
I’m not able to reproduce this here. I turned on shade highlight selected surfaces and polysurfaces in the shaded mode settings then used BlendSrf but the selection highlight of the surface is disabled once the command is running. Maybe your display mode has some other tweaks? Send it over if you can and let me know if I’m misunderstanding how to repro please.
As for the results of TestVersionNumbers, I am on 109406 in branch trunk. I think though the difference between my image and yours is the angle at which you are viewing the plane. I can get get my display to look like yours if from my camera position I swing around a bit to more closely match yours. Maybe arrows could be in Selected Objects color, and the surface could remain in Highlight color?
One other thing I am seeing as well though is that when jumping back and forth between the edges, the arrows that are no longer active are getting redrawn in the surfaces’s normal color, not the highlight color, so it looks like they are still on, but in a different color. This is also quite dependent on view angle.
Thanks for letting me know what you found regarding angle of view. Unfortunately, I’m still not able to reproduce the first screenshot you posted where you can’t tell arrows from shaded highlight. Do you have any lights in this scene? I see these affect the display mode you provided as well so maybe that’s the difference. I will file a request or bug as soon as I can be sure the developers will be able to reproduce it.
OK, in this file I have two saved views. One with the arrows that look like yours, and one where the arrows look like mine. Over here, both views show the bad arrow redraw when flipping back and forth between the edges.
Hey Sam, what would you suggest here? The problem is that you’re working in a lighted, shaded/rendered view, and you just so happen to choose a very specific viewing angle such that the shaded highlighted surface yields the exact same shade of pink as the unlit, un-shaded direction arrows. The arrow color isn’t the problem, it’s entirely the given situation. Even if I were to darken or lighten the arrows, you will still be able to adjust the view so that the shaded surface now matches the arrow color, and you’re right back at the same problem. The only thing I can think of is that the arrows use a completely different color if/when ShadeHighlight is ON…but even then there’s no guarantee that there won’t be some viewing angle where the shaded color closely matches the arrow color… Flat, planar surfaces can take on all kinds of different shades and colors in a rendered view…but I know you know that.
I will experiment with some ideas here…
Also, it sounds like there’s another problem being reported here as well? The arrows somehow take on the color of the surface? Can you elaborate on that one, and give me a more detailed step-by-step process and what to look for… Right now, flipping back and forth between surfaces yields the same pink arrows.
Hi Jeff, I would agree that just adjusting the saturation or value of the arrows would not solve the problem, I would think using a different hue would be needed. It seems the possible paths when ShadeHighlight is on would be to changing the hue value of the highlight color for the arrows by some set amount; using some other existing color, such as the selected objects color; making an entirely new Selected edge color (this seems like a PITA); drawing the arrows using some XOR drawing mode. I don’t really have a preference as to what method is used, as long as the arrows have increased visibility. While I understand that this might sound like just a perfectly wrong viewing angle thing, personally I have been finding that having difficulty differentiating the arrows from the surface is not all that uncommon.
As for the other issue, in the ShyArrows.3dm file posted above, start a command were you need to pick an edge such as blendSrf, then in the selection window that pops up, toggle back and forth between the two edges, and you should see that the edge who is not highlighted in the selection window arrows are redrawn in a way that they are still visible. Perhaps an image will clarify:
Interesting… Those arrows aren’t even supposed to be there. If you do the selection from the other side (looking straight on the edge), you will see that flipping between the two surfaces only highlights one surface and one set of arrows. This looks more like some kind of depth buffer writing issue that’s keeping the previously drawn arrows from getting overwritten…they’re acting like some kind of mask for the color buffer…very weird.
I’m seeing it here too, so hopefully that means it’s easy to fix.
