A problem that’s been troubling us for a while is an alleged bug in Rhino itself. We are working in Rhino 7. Block instances in their original file will load in with the proper material and color. The bug, however, has changed our material names to numbers and created duplicates of each material. Many materials now share the same number and therefore when a block is inserted into a model as a block instance, the materials are incorrectly sourced and give the parts in the block the wrong colors/material effect.
Example of the names: “New Material 008 [our material for bolts], New Material 008 [our material for filters], New Material 008 (1) [our material for gears]”
I know there are ways to fix this as it happens manually while working within a model comprised of block instances, but it has been affecting all the models we have, new and existing.
What I am looking for are suggestions on how to navigate this automatically. For example if there is a command in Rhino to help at least replace all certain blocks in a full model with the correctly colored original block with colors and materials sourced from the original file of the singular block instance.
Recently there was a post here that seemed to help for a time, suggesting the command :
RenderImportConflictOption
and giving some instructions, but it isn’t achieving our goal after all.
Any tips would be greatly appreciated. I can explain in more detail if anyone has an idea on how to navigate this inconvenience.
@johnc - do you have an idea what may be happening here? This seems somewhat, vaguely, familar but I thought it was fixed if I am thinking of the right thing.
@LG4 - can you please run SystemInfo in Rhino and copy/paste the results here?
Windows 10.0.19044 SR0.0 or greater (Physical RAM: 15Gb)
Computer platform: LAPTOP - Plugged in [100% battery remaining]
Non-hybrid graphics configuration.
Primary display and OpenGL: AMD Radeon™ Graphics (AMD) Memory: 1GB, Driver date: 8-30-2021 (M-D-Y). OpenGL Ver: 4.6.14756 Compatibility Profile Context 20.40.68.03 27.20.14068.3000
> Integrated accelerated graphics device with 6 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port
- Secondary monitor attached to adapter port #1
- Windows Main Display attached to adapter port #2
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: ATI Technologies Inc.
Render version: 4.6
Shading Language: 4.60
Driver Date: 8-30-2021
Driver Version: 27.20.14068.3000
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 512 MB
Rhino plugins that do not ship with Rhino
C:\Program Files\Badger 1.0 (64-bit)\Badger.10.v60.x64.rhp “Badger”
Yes, this issue is definitely reproducible. Here is what we see (the names of materials) in every model we have, including original block files. The example below is what is going on for a majority of our blocks within complete models.
The red highlight is the listed “Triplex” filter’s layers that make up the block. The colors in the model are incorrect, as well as the name of the materials. The blue arrows are pointing to an example of the software presumably being selective about what correctness it retains when naming materials.
When we try to insert another block instance of this filter, it sources the material name/color from the model rather than the block’s original file.
The red arrows, for quick example’s sake, shows the material discrepancy between what shows in the picture above, and the picture below. The “Lid” of the filter and the two “filters” below.
This image is the original block file. The colors appear correct, but as you’ll notice, the names are the same as the ones in the model despite the colors being completely different. I believe whatever bug it was had changed up the names we originally had to differentiate parts (i.e. the bolts and actuator body). Both models are set to the “Render” view style.
Since our team has yet to find a way to “reverse” the name changes and set it back to usual due to this being a bug, we are searching for a work-around that would allow us to import the original block and have what we input into our models source the correct materials found in the original block models. So far, we’ve been making the corrections manually by going into the layers and choosing the “correct” material. It works, but in terms of saving time, we’re looking for a way to bypass the manual work and have the block that we insert into our model source from the original block file rather than the discrepancies found in the model.
In my original post, we had found a suggestion posted in the form of a Rhino command that seemed to help out as a small fix for a bit, but the issue still exists.
I hope this post explains the problem sufficiently. Thank you for your time!!
Thanks, I can see there’s a problem, but I can’t tell what to do to reproduce it - if it is a consistent one, it would be very helpful to have an example file or files - just boxes if that is easier - that shows the material naming problem so we can see how they they have been inserted etc. If you can do that please send to tech@mcneel.com, with a link back here in your comments.
