Hi…,
to bring this on the agenda again. This is an important wish of a long time toolmaker Rhino customer, who wishes to color surfaces in a polysurfaces differently (without explode and group tricks, which limit you in modelling tools drastically).
Thanks
Michael
www.flexiCAD.com
This works now in the v6 WIP by sub-object selecting (ctrl + shift + click) surfaces in the polysrf and then right clicking a material swatch to ‘assign to selection’.
Hi Michael,
Please note that this is material only, not object color. Exports to some other file formats, STEP in particular, will only use object color, which is just one color per polysurface. As you know, the STEP format does support a separate color per face. The problem is in deciding which to put in the STEP file. Object color or material. I suppose we could do it based on which color is visible at the time of export, but then this doesn’t work from a rendered view if the materials are more complicated than simple colors. Also, when importing an object with multiple colors, I suppose we could warn that the display mode has to be set in a way to see the colors.
Hi Brian and Chuck,
first of all thank you very much. I see now, that I can change the material colors by surface, this is already very good. Intuitively I think tool modellers are using more object colors, than materials. But of course materials are more powerful.
Thanks
Michael
From another toolmaker…
Object colours for sure. We almost never apply materials, but we use colours to signify tolerancing for the CNC programmers. We have to provide surface files to maintain the colours, but it would be great to be able to send polysurfaces too.
Dan
Would it be useful if I gave an option on STEP export to get surface colors from material colors? Along side the option would be something like, “Warning:If a polysurface has surfaces of different colors, those colors will be lost when reading back into Rhino.” I’ve avoided this in the past because it seems like it would be more confusing than helpful. I should already give a warning on importing such a polysurface, since all I do is grab the color from the first surface in the polysurface.
This looks great. Object colours as default would be my preference, but as you say, an option in the STEP export dialogue could allow users to choose.
What prevents Rhino from reading multiple colours in a single polysurface when importing a STEP?
Do the big-name solid modellers all handle colours in the same way when importing STEP files?
On a different (but related) tack, it would be VERY useful if there was an option to attach Property Names to parts when exporting to STEP, such that solid modellers have them appear in their model tree on import. At the moment, the only reliable way I’ve found to do this is by making each Rhino polysurface a block, but this is both time consuming and restrictive when one needs to carry on working with the Rhino model afterwards. I know that the name tags are currently exported, as I’ve had success in sending models to someone using an old (UNIX) seat of Catia (without using blocks), so a lot of the blame should be put at the feet of the ‘big boys’ and their lazy approach to non-native file import. Not for the first time, either…
Anyway, thanks for the work on multicolour polysurfaces, irrespective of whether they can be saved to STEP or not. It’s a very useful feature. Oh, and please make sure this works when saving out a 3D PDF! 
The thing prevents Rhino from reading multiple colors in a single polysurface when importing STEP is that Rhino polysurfaces have a color attribute but the surfaces that make up the polysurface do not. They have material, which is much more complicated than color. One of the main issues is that material is only visible in a rendered viewport. Otherwise, you just see the single color of the polysurface. Currently, STEP import just assigns a color where it can, not a material.
I’m adding my vote to having surfaces have their own color attribute so that we can use shaded modes to see different colors on a polysrf. As Dan, we basically never apply materials but there are cases where different colors would be helpful in a regular working mode (i.e. shaded). That, and it seems like it would solve the headaches with STEP import.
With this functionality we will definitely need a commands to ExplodePolysurfacesByMaterial and ExtractSurfacesByMaterial.
Nice ideas, I added these feature requests
http://mcneel.myjetbrains.com/youtrack/issue/RH-29500
http://mcneel.myjetbrains.com/youtrack/issue/RH-29501
Hello,
Despite being an old theme, I would like to make my vote for this to be considered … as soon as possible.
Poysurface with different surfaces colors are very important in the mold industry.
Thank you.
Vitor
Hello, to bring out the topic again - for us as a toolmaker it is extremely important to be able to store the surfaces in color.
This must also be retained during the export (we use .igs for transmission to the CAM).
Until now we color individual surfaces and group them. This removes all possibilities to use volume commands and makes everything much more complicated. This costs us a lot of time too (I think 25% … 30% of my worktime).
My wish: Object colors on surfaces remain intact when connecting.
This function would be worth more to us than all the new features / improvements of a new main version.
So Please, please add this Function for us toolmakers.
thank you in advance
Robert
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?
–Mitch
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… 
--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.