Guidelines in "Colour by tag" mode (Pro 2022)

Hi. The quidelines appearance was changed in 2022 update. Now the quidelines colour is the same as tag and it makes them impossible to see against surface when “Colour by tag” mode is used.

In the clip there are two crossing guidelines drawn on a pipe side. Both the pipe and the guides are drawn to the same tag and …well… you see the result. Tagging quides every time to another tag is a roundabout, but it is very frustrating to change tags all the time during intense drawing.

Have you tagged the raw geometry?

Is the default tag something other than Untagged?

Don’t do that.

If you have, reassign Untagged to your existing pipe geometry (raw edges and faces), and guidelines.

Change the default tag to Untagged AND LEAVE IT THERE. Always draw with Untagged as the default tag.

Make the pipe into a component (or a group).

Tag only groups and components, or non-geometric items like guidelines, text or dimensions.

In future, your guidelines will remain Untagged as you draw them.

No John, it is a new ‘fault/feature’ of 2022.
Previously Guides stayed black no matter what tag they were assigned. So a guideline within a group that was assigned Tag1 and had a colour setting of red would still be black when the rest of the geometry in the group was showing red for the Tag.
Now Tags within groups or even untagged take on the colour of the tag.
It’s not good.

@colin you might want to pass this along to the appropriate developer.

Looks like I’m wrong on this.

I am not sure the behavior changed at any time, but the default or ‘untagged’ color did change from red to white.
Guidelines should be seen as temporary entities with an overide color to be set in the Styles panel, I believe.

Ok, that is strange, when I tried it earlier the guides remained black in 2021, but now not. Still think it is a bad option even if it has always been that way.

While guides are being created in 2021 and earlier, their color had been an arbitrary shade of gray, which for many cases made them hard to see while working with the default material behind them. With 2022 they are now drawn with the color they will be when you finish placing them.

For the special case of being in Color by Tag, they will of course now match that color all of the time, and not only when you have finished placing them.

I will pass on that concern, but it would be useful to describe some use cases where you are creating new guides after changing to Color by Tag.

The problem is only different now during the time the guide is being created. In 2021 you also would not be able to see the guide after you finished placing it. Note too that you have to be looking from a narrow angle range for the lighting to be such that the two match.

I think that it would be best to have Guide colour either as a style or global setting.


I rarely use guides so It’s not something I come across much but I did have someone the other day post a question here because their guides had disappeared. I took me quite some time to realise the model was in Color by tag mode.
I’d be interested to see an example where it would be useful for the guides to be the same as the geometry in the tag. Should be black in my mind unless specifically changed.


(Seems there is a limit to reply with only image at once; therefore cleared this post and I will paste the captures to one image to another post)

Thanks for care @colin. Here you see a simple test result. All the items are otherwise the same but all on different Tag. The used tags you see in the side.

You see the guides are practically impossible to see and use nowadays when drawing in the “Color by Tag” mode. For me it is the preferred mode due I draw complex entities and instant tagging is the best key for survival in such conditions. And like i wrote in the first post; drawing guides to another tag is not very practical roundabout


The guide colour in that style setting is overridden when viewed in Color By Tag.

1 Like

If you have Use sun for shading turned on the guides will be hard to see from any direction.

I’m not against the idea of having a separate style setting for the guide line color, but if you could give some use cases where you need to keep color by tag turned on, that might make the issue be more important.

I know @JQL made a request for this once, maybe he knows some use cases.
As said before, one doesn’t learn how to use the software, per se, merely learns to deal with it’s limitations.

Hi @MikeWayzovski I’m pretty sure my request had to do with this exact issue. I use Color by Layer a lot, and I also use guides and sometimes they also disappear against faces. This is really annoying and lead me to the same request that is being made here.

Guides color, as set on styles, should override their own tag’s color.

I’m with you on this @oheimala , I feel your pain.


You asked use cases drawing in the Colour by Tag mode; here one example :slight_smile:

To keep a model organized, you can use groups, components, colours and tags to separate different items from each others. The tags are the most powerful of them due turning the wanted/unwanted parts on/off can be done with one click; especially when tags are foldered. Tag colours shows you instantly how they are placed in the tag hierarchy.

Just directly colouring items does not give you such power. In the tags the colouring is done automatically, but it does not affect the final colours/textures used. Directly colouring items for an organized drawing but changing all the colours when render can be done in simple cases, but in complex drawings it does not make sense, due all the organization will be lost when doing that.

In the clip you see one model with several tags used. There are only two final textures used for rendering, but to understand and edit the entities you really need more colours. Due there are so many items to take care, switching easily only the relevant tags visible is also very important. In this model there are not lot of quides, but this was mostly an example of Colour by Tag use.

1 Like

Yes, I too regularly use color by tag to see what is what in a complex model.


And no; there is no sun shading used.

I got an idea that a Tag with a black color would be assigned to construction lines (points) on the fly.
The following snippet will do that. It will create a new Tag “_Black guide” with black color and assign it to the just created Construction Line or Point.

Note: It is just a concept yet. Does work only in a current editing context. (If you go to edit a component/group or close it you have to start again manually yet, see below)
I recommend to have a backup of your modell if you want to try this snippet. Use your own risk!

Copy-paste the snippet below to Ruby console and hit Enter (Return).
To stop assigning tag type:
To start again (or changed the editing context), type
And hit Enter (Return).


module Dezmo
  module BlackTagClCp
    extend self

    class MyEntitiesObserver < Sketchup::EntitiesObserver
      def onElementAdded(entities, entity)
        case entity
        when Sketchup::ConstructionLine, Sketchup::ConstructionPoint
          entities.model.start_operation('Tag It', true, false, true)
          layer = entities.model.layers.add("_Black guide")
          layer.color = [0,0,0]
          entity.layer = layer
          puts "Tagged: #{entity}"
    def start
      model = Sketchup.active_model
      @ents = model.active_entities
      @obs =
    def stop
      @ents.remove_observer(@obs) if @ents && @obs

@JQL , @oheimala , or others, let me know if you like or not … :innocent:

1 Like

A fresh idea :slight_smile: In some cases such way of tagging guides to their own tag can be very useful!

This has also limits. In a complex model the there may be very many guides; for example center points for holes, bolts, nuts etc. for making aligning parts easy. If all of them are in a same tag, closing tags those the guides refer will leave a cloud of irrelevant guides float in the model. Grouping will change the situation a bit, but then a group may contain items with several tags and it can make the control a bit fuzzy.

1 Like

Yes you are right there is a limitation, like almost all “workaround” have…
(I can think about the workaround of the problem what the workaround caused… but, I guess the a straightforward solution would be better :wink:)

1 Like