MacOS UI Bug:
When in subobject selection selection mode, the ‘Face Color’’ attribute becomes available in the Properties panel:
You can select ‘Custom’ from the dropdown, However, as soon as you click the color wheel panel, it defaults back to 'From Object" which means you cannot ever actually set the color on the face:
thank you very much,
@ed.p.may
Hi Ed - thanks, this seems to be true for extrusion objects - if you ConvertExtrusion, it should behave as expected.
-Pascal
Thanks @pascal that worked! I’ve never heard of ConvertExtrusion before? Is that something I should be doing regularly to my geometry in order to clean it up or something?
Regardless: that worked! Thank you.
One small item: it appears that when ‘Flat Shaded’ is checked (in standard ‘Shaded’ view), the color does not display, which seems odd? (but it does appear to be assigned correctly at least).
thanks!
@ed.p.may
Hi Ed - you should not need, in general, to care about extrusions, but fyi, here are some details:
https://wiki.mcneel.com/rhino/rhinov5status_extrusions?s[]=extrusion
The issue here is, extrsion objects do not have faces in their definitions as polysurfaces do. Assigning per face color could presumably convert them automatically, which would be my preference, I think, at the moment anyway, but we have not really decided what, if anything to do here…
I’ll check the flat shading, thanks for the heads up
-Pascal
Very interesting - thanks @pascal , I was not aware of that background.
Makes sense, and yes: either an automatic conversion when a user tries to apply a color, or at the least a warning / note / dialog of some form rather than just silently switching back to “From Object” with a suggested fix (“ConvertExtrusion”) would probably suffice for most users?
Certainly good enough for me for the time being - thanks!
Hi Ed -
Just for what it’s worth - while the default behavior of Rhino is to create lightweight extrusion objects when possible, you are unlikely to benefit from that behavior unless either your computer is very old, or you have a humongous amount of very simple objects. The UseExtrusions command lets you change the default behavior of the type of object that will be created.
Thanks. Looks like we have that one on the list as:
RH-69328 Display: When flat shading is on, _SetPerFaceColorByFacePack does not change SubD faces’ colors
-wim
But this case simply illustrates yet another way that they are not fully “transparent” as has been advertised since their creation I don’t know how many years ago…
At last, someone from McNeel is willing to admit that having this as default behavior is just… wrong. I have campaigned against this default behavior since day one and I have never heard a valid argument justifying its existence since then. But to no avail, the refusal to change is always categoric.
Extrusions are a sort of ‘expert’ object for those who know they need them - mostly for @wim 's second case, humongous numbers of objects - which for me does not describe a ‘default’ workflow. ‘Experts’ will know about how to enable UseExtrusions, all others who don’t need them should never even have to worry about them - and this from the time Rhino is first installed.
While that would certainly be a good idea - so people will not post here wondering why they can’t set a per-face color on their simple boxes or other extrusions - changing the default Rhino behavior to not use extrusions would already eliminate 99% of these situations before they happen.
Also just to note that while there is a significant difference in object memory use between extrusions and their polysurface equivalents, with basic render mesh settings, this difference does not come from the display meshes - which are basically the same in many cases.
I created 1000 boxes as both extrusions and polysurfaces. The file size for the extrusions was around 5Mb, the polysurfaces nearly 22Mb. However, in just extracting the render meshes from each and exporting those, the file size is nearly the same - about 3.5Mb. So the difference in memory use lies in the underlying structure of polysurface vs. extrusion, and will affect file size, but probably little else - certainly not display speed, which seems to have been one of the main concerns. And again, only if one has ‘humongous’ numbers of objects.
Hi Mitch -
I’ve spent a few hours on this now…
FWIW, you state the valid argument here:
I just tried the test command Pascal mentioned in that thread, and that fails miserably. Also, it requires you to pick an edge for every single object…
At any rate, the aim has always been that extrusion objects are converted on-the-fly when necessary. When it doesn’t - as in the case of this thread - that’s a bug that needs to be fixed.
With all that said, my default is, and will be, to create polysurfaces when extruding something…
Also, and off-topic, thanks for making me look -
I’ve turned ON CheckNewObjects on this new machine now…
-wim
Yes, but again that was not really an argument against having extrusions as the default result, but just an acknowledgement of the ‘expert’ need of (perhaps) having to convert from from polysurfaces to extrusions and not being able to.
I am not calling into question the existence of extrusions (despite the fact that they are mostly useless as objects in a Rhino document), but simply arguing that they should not be turned on by default.
Let’s look at one of the most likely scenarios for having extrusions in a document - some kind of architectural/structural arrangement that is composed of thousands of different beams and columns. As soon as one needs to punch bolt holes, cut notches or chamfer the ends of the extrusions to make them fit together/fasten with other elements, by definition they can no longer be extrusions anyway and get automatically turned into polysurfaces. So their applicability in any kind of real design situation is again completely theoretical. I would certainly be interested in hearing from anyone who absolutely needs extrusions in their work and the reasons why.
Also, I question their usability as objects in a real-life situation as objects in a Rhino document, however as a programming construct in RhinoCommon, Grasshopper etc. they can be useful.
