Still need to be able to change colours of polysurface faces

i think the logic is that every item, every geometry comes structured in some sub-sub-sub hierarchy tree… groups contain objects, objects can be polysurface etc… polysurface contains faces, edges, vertices. i think the best solution is the availability to assign attributes with options “by parent” (parent for polysurface edge would be polysurface itself, parent for polysurface would be group if in group, parent for group would be upper-group if nested…), by “layer” (it would be stupid to assign different layer to subobjects in general), “or unique” to every item available for selection.

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