Still need to be able to change colours of polysurface faces

Yes, being able to join surfaces into a polysurface and assign individual colours to the faces is the point of this request. It would be a “game changer” for us, at least with how we use RhinoCAM.



This is our current workaround:
select individual surfaces, then colorize them using the toolbar we created ourselves (see below) and then combine the surfaces as a group into “one part”.

1 Like

Unfortunately automatic feature detection in RhinoCAM doesn’t recognize grouping. I tried just now, but no luck. This is from the MecSoft help file:

So I end up right back where I started if I join the surfaces into a polysurface. One colour.

But for other applications, yes, grouping might be a solution.



@DanBayn the latest V7 WIP has support for setting individual face colors for a polysurface. I’m still working on SubD support and John Morse is helping with getting this hooked up in the properties panel, but there is enough in place at this point that you can start experimenting with this feature.

There are three test commands that you can use until color adjustments are available on the properties panel.

  • TestSetPerFaceColor - pick some faces and set their colors
  • TestClearPerFaceColors - clear all of the per face color settings for a polysurface
  • TestSetCannedFaceColors - automatically set all of the faces of a polysurface to a bunch of different “Easter themed” pastel colors.



Hi @stevebaer,

Thank you for this. This is going to have a big impact for us.

Much appreciated,


This is looking good. I see that overriding brep face colors is already (7.0.20098.14255, 4/7/2020) possible via the Properties panel with subobject selection.

BrepFace’s PerFaceColor is available in RhinoCommon even though it’s not yet on

Currently, it appears that more brep methods than UI commands can retain face colors.

Yes, the RhinoCommon function is available for BrepFace and hopefully soon for SubDFace. I’m not sure what the frequency is for when we rebuild our API docs; it will get there sooner or later :slight_smile:

I don’t follow this comment. Can you explain a bit more? Thanks

_DeleteFaces (and also subobject-selecting a face and pressing the Delete key) will remove the overrides from the remaining faces, whereas BrepFaceList.RemoveAt retains them.

I had thought that _Join was also losing the colors, but when I thought I was setting face color via Properties panel, I was instead changing the color of brep. Even though monoface breps can have their face color set via BrepFace.PerFaceColor, _TestSetPerFaceColor doesn’t allow monoface selection, and the Properties panel ignores subobject selection.

An example of where the colors are lost in both the UI and RhinoCommon is with _ExtractSrf and BrepFace.DuplicateFace.

Good to know, thanks! I’ll get these logged in our bug tracking system.

By the way I just checked in code to allow per face color setting for SubD objects as well. This will be available in next week’s WIP.

@DanBayn and @spb
I see the use case for the per-face color. Do you typically solid edit your polysurfaces after coloring the faces? For example perform booleans, face splits or merges.
I’m asking to gage the expectation and needs for solid editing commands to preserve per-face properties.

1 Like

this looks interesting indeed… is there any chance that this might also work for materials ? such a feature would be very, very useful for architecture…

any chance ?


It’s already there in V6. Please see the “per face material” video about half way down this page

Setting per-face colors before Boolean operations can save time when features of a part are the pre-Boolean breps.

Generally, I think face colors should be maintained whenever the entire or a portion of a face remains after editing. This includes setting per-face colors on a resultant brep of a Boolean when the input breps had different object colors but no per-face colors:


Per-face color of surface faces that are created by commands like _FilletEdge, even between 2 per-color faces, should not be set.

Maybe both _MergeFace and _MergeAllFaces should have an option added for whether to allow merging of faces of different colors.

1 Like

Added to the list:

1 Like

Please make this optional - in my case anyway, this is neither necessary nor wanted 99% of the time.


I think if you don’t have any per face color overrides, nothing will be different than what you are used to

Well, the request was to do this even if there are no per-face overrides, which was why I commented on it…

:grinning: It’s also why I’m commenting Mitch. I agree with your concern

Hi @rajaa,

In our case, the colouring will be post-modeling. It’s how we communicate the design intent to the CNC floor. For example, if an area of the model is unimportant we use a specific colour so that the CNC programmer/operator can hustle through that area and not be concerned with deflection, surface finish, etc. Other areas of importance use different colours so that they know that area has to be dimensionally accurate, good finish etc.

Currently we have to explode all our polysurfaces to accomplish this, but then the automatic feature detection and automatic machining features of RhinoCAM are not available to us as they only function on polysurfaces.

As for editing after adding individual colours, could there be a few simple “rules”? For example, if you fillet two faces of the same colour the fillet could inherit that colour. If the fillet is between two surfaces of different colours, maybe there could be an option to inherit the colour of the face with the largest area. I think Mitch is correct that behaviour should be determined through options so this works for a larger audience.



1 Like

uhm, @stevebaer,

What’s happening here?

using this build (rhino_en-us_7.0.20107.04575)