Per face color in practice

Hello everyone,

many thanks for the introduction of a long cherished wish - per face color.
The foundation stone for the function has been laid - now it is time to put it into practice.
However, as expected, there are still some problems / need for improvement.

As a practical example I have uploaded a construction of an exam part.
This is a very simple variant of the constructions we work on daily.

#1 - How can I quickly and easily transfer the existing data solids while keeping the colors?

To allow for different colors per part, we are currently still working with groups.
To use per face color in V7 this data must be converted accordingly.
I had hoped that a simple dissolve of the group and connect is sufficient - unfortunately this does not work.
It would be ideal, if one had the option “Apply object color as per face color” when connecting the surfaces and when splitting up
face color would be taken over as object color of the single faces.

#2 - Object color mixes with per face color

The color of the face color itself and the individual face color mix in the view.
For our application this is very unfavorable - only the per face color should be displayed - is there a possibility to adjust this?

#3 - new elements in object (e.g. chamfer / fillet) gets object color

If new surfaces are created on an object, then these get the object color assigned - however not as per face color.
This means that they all have to be selected again by hand to give them the correct per face color.
Is it possible to change this so that new faces automatically get the object color as per face color?

#4 - Splitting and merging parts creates unpredictable results

When a part is exploded, then edited even if you manually assign the new faces per face color) the result is
an unpredictable combination of object color and face color, which requires a lot of manual rework.
The problem here is very similar to #1.

#5 - export in Iges / Step

I have not been able to achieve any success in Iges yet - all per face color settings were not exported.
However, since we use Iges to transfer our data to manufacturing this is very important to us - is this adjustable somewhere?

In Step it looks more mixed - here it basically works, but some faces arrive in CAM with wrong colors.

I hope I have been able to describe the points sufficiently well.
#1 and #5 are the most urgent points - these currently prevent us from enjoying all the new possibilities.

Many greetings


corebox.3dm (6.3 MB)

Hi Robbe -

#1. I think what you are asking here is simply to keep object color as per face color on Join, correct? Currently if you assign per face colors the same as the object color, these are respected on Join. I do not know what is possible, but I’ll ask…

#2 Per face color only affects shaded faces, not the wireframe, is that the problem? What should happen on joined edges?

#3 How should it be done then? If you add a fillet to a solid that has per face colors, which input face should provide the color?

#4 As far as I can see if all faces have per face color then it is predictable, is that correct?

#5 I do not know about iges. Step should work, I believe, if there are cases that do not, please send them to us here or via


Hello Pascal,

thank you very much for your feedback.
It is indeed partly difficult to describe when what happens.
So I try to show each point one by one using the example from above.
This may take some time, so each one individually.


This one I was just able to reproduce well.

Here is a picture of the body in Rhino.

Here per Iges in NCGCAM

Here per Step in NCGCAM

It is good to see that with Iges no colors are transported.
With Step many surfaces arrive with wrong colors.

I have attached the data for this.

best regards Robbe

color (790.5 KB)


I’ll divide this into 2 points here an example of what I was trying to describe:

The problem is that the object color also tints the color per face.

Here is an example of this:


Here is the response to the feedback question:

Rhino already handles this very well for single, grouped faces - if this would work exactly the same for solids with per face color it would be optimal.

For example, the edges with faces of different color could get the newest per face color definition or simply the brighter (or darker) of the two colors.

Here is an example:


Yes, that is exactly it.
Having the option to keep object color as per face color on join would make the transfer of existing constructions extremely fast - if not economically possible at all.

Ideal would be:

  • single faces with object color -> join -> solid with object color of faces as per face color (and the layer color as object color)

  • Solid with per face color -> explode -> individual faces with their previous per face color as object color

Attached is the test part, in the way it is currently used in our constructions (individual faces in groups).

Please try yourself to convert this into a solid with face color.
Then it will quickly become clear how important the option is and also the other problem areas show up very quickly (e.g. #3 and #4 ).

As I said, this is an extremely simple component for our work area and yet I get problems again and again when converting the data.

test - part.3dm (1.3 MB)


Here is an example of such an event:

In this case the object color was not preserved and randomly reassigned.

There are other such effects, such as the per face color being partially lost when it matches the object color - together with the randomness of the object color when merging, this gives very mixed results.


It would be nice if the object color was taken over as per face color for newly created objects - so all surfaces in the solid have a per face color and there is no mix of object color and per face color.

I hope this explains the problems sufficiently.
It is quite difficult to communicate everything well via text and examples - on the computer itself or via online presentation would be much easier.

As I said - it can be understood best if you try to convert the test - part into a solid with matching colors yourself.
test - part.3dm (1.3 MB)

Thanks again for the introduction of the per possibility to color individual surfaces.
I hope that the expected teething troubles can be solved and so a big step for easier handling of the engineering in our industry takes place in Rhino.

best regards Robbe