Toolmaker wish: polysurface with different surfaces colors

Using groups may be part of your problem. . You can use layers, names and colors to create subsets of surfaces for IGES export. Also it is a good idea to join all the connected surfaces which have the same color. If surfaces are joined in Rhino (open polysurfaces) that also will organize the surfaces in the IGES file.
There are lots of options for sending color and surface information via IGES. I’ve been sending color information by IGES to CAM and CAD programs for about 18 years and never had a problem. You can also do the same thing to send color info by STEP format.

Also in Rhino you can accurately compute the volume of a closed polysurface even if you separate it into color coded parts. So you can extract surfaces from a closed polysurface and group the components by joining surfaces that you want connected and assigning colors and still get the same volume calculation as long as you select all the parts that make up the closed polysurface.

But this is also just an workaround.
You can not use Volume operations (or just with other workarounds).

Other systems (for example Creo) ca handle difrent colors on one volume-part.

In the next version of Rhino you will be able to color different Brep (polysurface) faces differently - but only with a render material. A single object in Rhino has a single layer and a single display color - these are object attributes. I’m not certain that sub-objects like individual Brep faces can be made to have different object attributes without a major rewrite at the core level…

However, as IGES explodes the polysurfaces on export anyway, perhaps the IGES export could be modified to have the option to export the surfaces with the render color as object color… Probably not possible with STEP, as STEP keeps objects joined and I’m not sure how object colors are handled via STEP. @chuck?


I never looked at it that way since you are exporting a collection of surfaces and boundary information regardless of whether you add color or not.

You can use volume calculations on a collection of surfaces And if they all came from a single closed volume, then Rhino will give you the same answer whether they are joined or not.

As far as I have seen, there is no problem with other programs handling what I export. I have used color coding of surfaces to send information for customer approval. The files are sent up the supply chain and opened with a variety of programs like Pro-e, unigraphics, solidworks, Catia …

I have nothing against coloring surfaces within a polysurface, but I don’t see it as adding much that hasn’t always been there. This is really just about where information is stored in the database.

In a STEP file, a face in a BREP has its own color, so it would be possible to assign render colors as face colors. An option to do this has been requested a few times in the past. Confusion arises when you read the file back into Rhino and the colors are not there since the per/face colors in the STEP file are now object colors rather than materials. There are other issues too. I guess if we put a disclaimer next to the option it might be ok. @pascal? We’ve been over this a few times and always decided it wasn’t a wise thing to do. Any further thoughts?

When he talks about volume operations I think he’s talking about “solid” operations like Booleans, not getting the volume of a enclosing set of surfaces. I know you don’t use them much if at all… :smile: --Mitch

I thought the discussion was about sending (exporting) information to other applications or to other people. Colors are a useful way to identify surfaces for purpose of conveying information about how different parts of the model will be treated. For instance to show where stock or draft is going to be added or to show proposed parting splits. As far as I know the applications that import these models have had no trouble turning the model into solids.

I often work with large complicated solids that I divide up into pieces (usually along the lines of tooling components). I give the different parts different colors or even different layers . I don’t see that as an obstacle - it actually allows for getting the work done a lot more efficiently.

PS Booleans are not volume operations and thinking that they are is one of the things that gets people into trouble. My advice to new users is to learn to model without booleans because you will get your work done a lot faster and more important you will learn Rhino a lot faster. All too often I have seem inexperienced users ask why their boolean is failing and the reason is because they went to an extraordinary amount of time and trouble to make it fail because of this sort of misconceptions about how it works. In other words, even if the boolean had succeeded they already had spent more time than it would have taken to get it done by basic surface operations.

Trust me I know how to model complex toolparts in rhino. I do this since decades now.

Lets bring it down to something simple.
When I design a plate it is a cuboid at first.
Then there might be holes to drill in.
Holes have colors by function.
To color that hole I have to explode the cuboid and can never join it again. So I work around by grouping them.
Also the sides of the Plate get an other color than top an bottom because of the tolerances.
For example now I can’t use any solid or Boolean options like a simple chamfer. Joining by color is also useless now.

And this is just al very simple example.

Over the years I tried a lot to work with this issue but the only straight way would be to can join surfaces by keeping their individual color.

I often have parts with 5000 and more surfaces. There must be a very simple way to handle colors.

Many toolmaker would give you many kisses (and for me I would also pay a lot for it!) if this is possible.



I don’t understand why you think that you can’t make a chamfer.
I also don’t understand why you would even want the lousy surface that the ChamferEdge command makes when you can make a nice accurate revolved surface and propagate copies to all the hole locations.

I generally use points to mark hole locations. The points can be color coded by function and hole type and put on separate layers so the can be turned on or off.

But lets suppose that Rhino did allow you to have surfaces that are part of a polysurface that had different colors. If you made your chamfer on a hole would you expect the chamfer to become the color of the hole or the color of the plate or would it become some other color?

Sorry for my bad english/writing.
I meant the outer edges of the plate.
For this the edge chamfer command is very useful.
For complex chamfers and drill holes I agree the command is very poor.

About the color management of command results I think there should be 2 things.

When a bolean function is used the colors should be the same as in the source poly surfaces.
When you create new surfaces like chamfer It gets the color by layer and you can use “sel last” and then apply a difrent color if needed.

With this two the handling of multicolor poly surfaces is very easy I think.

At this time we have 5 licences of rhino 5 running here.
To point out again how important this feature is to us - an update with only this single function would be worth 1000$ and more per license to us.

Hi there,

just following up to see if there was ever any development / conclusion on being able to assign different display color to independent surfaces of a joined Polysurface?



I would also be extremely happy about a variant where you could color the surfaces of a polysurface and output them during data export. Most CAD systems can do this without problems.

Also .step supports colors (when importing into Rhino there is even a dialog that says that these colors are lost when connecting the surfaces).

Colored surfaces during construction and import and export are fundamental for my work, but unfortunately they are poorly or not implemented at all in Rhino. Only some workarounds remain.

Therefore - a big please, please from our CAD - team here in the Erzgebirge.

Hi Andrew - that discussion was continued here:

The feature request is on our list as RH-37306.

It is also very important that the colors of individual surfaces are preserved when connecting, as well as the colors of a polysurface when breaking up.

With boolean operations the colors of the parts must also be adopted correctly.

These things would save us hours of work in tool design.

At the moment I work with a self-created toolbar (on the right side of the picture), with which selected surfaces can be colored.

The problem is, that no joining is possible and that you have to work with groups and without boolean operations.

best regards


Added a Bug item to preserve per-face color/material in Join command.
Are there other solid editing command that you commonly use that need to be preserve per-face color/material.

HI Wim,

Thanks for following up on that.

Regarding this new function, will it ever be available as a service update for Rhino 6, or would that just be for the New Rhino 7 when it is realesed? the reason I ask is that I just purchased Rhino 6 not long ago.


Hi Andrew -

This will not be available in Rhino 6, no.
As for the availability of Rhino 7, as a user of Rhino 6, you can already download and use the WIP versions of Rhino 7 and, as such, this feature is now available to you.

Hi Wim, Thanks for that.

I have downloaded rhino WIP 7, and just though I would drop a line to see if I am doing something wrong, as when I select a surface, I then see I have drop down menu for Surface Color, however, when I choose custom, and try to change, it keeps reverting back to ‘From Object’

Is there a problem here? or am I doing something wrong?




Just to let you know, I have found out what the issue was… I created a cube, and tried to change the face colours, which did not work…

however, after exploding the cube, and then joining it back together, It would then allow me to change the individual surface colours. Great Feature,

Plus, the new colour wheel palette is amazing!.. Thanks to all and whoever made that development…

This feature only works for Polysurfaces not Extrusions.

You can use ConvertExtrusion to convert extrusion objects to polysurfaces and UseExtrusions to controls whether extrusion objects or polysurfaces are created by commands like Box.

1 Like