Hi devs,

Noticed the addition of dot color and text color in the DrawDot method of the display pipeline!

Waiting on today’s WIP release to test out the additional dot size property which I believe has been added to the WIP.

I also just had an idea which could be implemented:

Dot Modes:

  • Rounded (how I would describe the current mode, ( text ) )
  • Rectangular (square ends, | text |)
  • Diamond (pointy ends, < text >

The ability to differentiate by text, color and dot shape would provide a very intuitive tool for differentiated tagging of numerous objects.

Just a thought.

1 Like

Sounds like the kind of thing that could go in without much fear of busting something else. :smile:

@dale @stevebaer

I have tested out the new DrawDot methods of the DisplayPipeline. Very nice being able to control border, background and text color individually.

Since you have added a border color, I would also allow setting the border thickness (as it is not very visible at its current thickness)

I was hoping to see added control over the dot size in this WIP. What happened to that?

Other than that, I have not found any issues.


dot size is controlled if you call the DrawDow function that takes an actual TextDot as input. The TextDot class has a FontHeight property that you can set.

I would rather not expose a border thickness option if possible and just make it ‘look correct’ on user’s computers at least for now. I’ll try increasing the border thickness by a little bit to see if that looks better.

Got it. Works well.

I understand you don’t want to expose broder thickness. That’s fine. Just thought since we can set the size you would want to also set the border thickness in relation to that (the smaller the dot, the thinner the border).

What do you think about the dot ‘modes’ in my post above?

Makes sense and I’ve heard this request before. It is in our bugtracker at

The hardest part of that request is just the extra work involved in File I/O and properly exposed controls for setting this in the user interface. The actual drawing code would be trivial.

1 Like

By Diamond, do you mean a bar like now but with pointy ends, or a complete diamond shape with no horizontal edges?

I understood Guido’s request to fundamentally be that there should be a number of visually distinctive shapes available so that they could be easily differentiated when there are a large number of them visible in a viewport. I’m sure the exact shapes aren’t important, but could be left to a graphic designer to be pleasing, attractive and mutually distinctive. I’m not sure the number should be limited to three, though it probably doesn’t need to be more than a dozen. If the idea takes off, it might be good if the implementation was easily extensible to include more.

Personally, I think the implementation should include functionality to hide/unhide all of a given style; also select a single style while hiding all others; possibly ghosting all the hidden styles instead of disappearing them - or maybe as an option in addition to completely hiding them.

Sure this sounds like an application in of itself, but if you’re going to include a feature why not make it one users will be surprised and delighted at instead of disappointed and wanting.

bar + pointy ends… Doesn’t really matter what shapes they are. Just some easily distinguishable and readable versions.

Hi Steve,

You mention “the DrawDot function that takes an actual TextDot as input”, but I’m unable to find such a function: http://developer.rhino3d.com/api/RhinoCommon/html/Overload_Rhino_Display_DisplayPipeline_DrawDot.htm

Does it exist?

You are looking at the Rhino 5 API documentation.

Note the ‘/wip/’ portion of the following URL.

All WIP documentation has this ‘/wip/’ in the URL until Rhino 6 becomes the standard released product.