V6 per-face material is half-cooked

Hi RMA,

With the introduction of per-face material and its announcement in V6 new features we have realized that it may be a plan to release it as-is, which seems like a good idea that is not fully implemented, possibly creating issues down the road. Sure, it works nice on a simple model, but the practical use on more complex models can be problematic without some fixes or additions:

  1. We need to be able to explode the polysurfaces and have the sub-faces retain the individual materials

  2. We need to be able to explode polysurfaces by-material (basically separate the pieces based on custom materials assigned). Also ability to select sub-surfaces ByMaterial.

  3. Currently when the custom material face is selected, the Properties panel still shows the general object material with no info/ability to edit the selected custom sub-material. (Only the case if object’s material is ByLayer, if ByObject, then it shows it fine)

  4. when changing the entire object material, there should be an option what to do with faces that have custom material assigned: either keep them unaffected or change all subsurfaces to new material - currently Rhino resets all faces to new material.

  5. Boolean operations randomly change the per-face material assignments. They should stay unaffected. Same goes for Split command. Didn’t test it thoroughly but the idea should be the objects are still editable with all commands but keeping the material assignments.

Please consider these before releasing the new feature that can cause problems, especially with working with someone else’s models that use that feature or trying to export to other applications and trying to retain the material assignments.

thank you

–jarek

2 Likes

Hi
1 - https://mcneel.myjetbrains.com/youtrack/issue/RH-42470

2 - https://mcneel.myjetbrains.com/youtrack/issue/RH-42471
https://mcneel.myjetbrains.com/youtrack/issue/RH-42474

3 & 4 - This seems to be working for me. If I select the top level object, it says Varies as expected. If I sub-object select a face with an assigned color, I see it in Properties and I can change it.

5 - https://mcneel.myjetbrains.com/youtrack/issue/RH-42476

Hi John,

Thanks, for #2, I think being able to explode per-material is even more important than selbymaterial (selbymaterial would be weird if it automatically selected sub-objects, so maybe the command should have a switch subobjects=yes/no. But the ExplodeByMaterial could be a new command that keeps the areas with the same material joined?

#3 - see my note. the issue happens ONLY if the object has material inherited (ByLayer). Make a box, set material to ByLayer. Then select sub-face and add custom material. Now, if the object is selected, Properties material still shows “ByLayer” only. If you pick the custom material face, it also shows ByLayer instead of the actual custom material.
If the main object material is ByObject, all works OK.

#4 If I have a box with a material assigned to the whole object and then change a face of it to custom material, then when the material of the entire object is set, there are 2 issues with it: a) it is not undoable (sub material change) b) I have no way of retaining the custom material faces and changing only the “general” material faces. Both ways would be useful depending on the context but there is no option to retain custom face materials or easily select them ByMaterial.

#5 - Split also has problems. I did not test many other commands dealing with changing polysurfaces…

I think the idea was with this new half-baked feature, was to get it into the initial release of 6 and then chip away at it through service releases.

The alternatives were to leave it out entirely and maybe it’s a V7 thing, or delay V6 release to get more of these tools in place.

In it’s current pre-released state, I would not touch it. There are too many oddities to count on it.

If you have good, simple examples and command patterns that illustrate the points better, please post the models and steps.

Thanks John,

I thought the above are clear/repeatable and self-explanatory but I will try to prepare more info with examples.

IMHO having this half-baked feature may cause some problems without the tools to make use of it practically (at least having Explode keep the materials-otherwise some models that use that feature may be read-only/not exportable keeping the info).

–jarek

Not really. Going through your notes was the first time I’ve touched the per-face tools.
I’m busy with loads of other stuff and none of it is production modeling.
I’d do not use Rhino like you do. We need your help and examples to understand and repeat the issues.

Shouldn’t it work like known multi / sub-object material? I mean when u select brep u see multi material instead of varies? It will be much easier to refine listed materials under one “holder”. Of course all materials should exist on its own but assigned should be multi material which consists of different materials an for eg. you can choose one sub mat and change it to different without hassle and selecting sub objects to do that?

multi/sub-object material like in MAX? I guess this would involve a lot of changes to how Rhino handles materials across the board and a major change to the material and sub-object material assignment concept. While I like it, for now I am simply trying suggest making the sub-surface materials usable in actual real-world project work.

I don’t think it has to be big change. I think it should work like sth like:
Select brep -> assign material as usually (one mat is selected)
Select sub object -> assign mat and now behind the scenes rhino could make compound mat which consists for eg previously assigned mat and new mat or default and freshly assigned mat but there won’t be varies it could be a simple “container” which lists all used mats for brep sub objects. That way it will be easy to manage all materials used for certain brep and also replace for eg. one inside that compound with other mat. If u get what i mean it is just a rough idea but it seems pretty straight forward for me.

Item 5 would be great, would really help me achieve this look I’m trying to figure out in another post

RH-42471 and RH-42474 are fixed in the latest Rhino 7.8 Service Release Candidate