Material assignment with blocks

Using Rhino 7 (Mac).
Dealing with an assembly model that is made up of components that are individual files placed as block files in the assembly model file.

Using active layer option. Layers in different component files have same names to define the building material (eg 3/8x0.035 XMoly). Objective is to have building materials in same layer on assembly file.
Does the active versus reference option in any way affect the way the render materials are carried over?

I am totally confused as to what is happening with the render materials shown to be carried into the assembly file that are assigned in the components (block files). When assigning render material in the component file, some seem to carry over when used as blocks, while others do not.
Is it the case that I should not assign render materials in files that are to be used as blocks and only apply render materials in the assembly file to the active block layers?

Assuming you have one object per individual file set the object to receive material By Parent.

Once this object is in a block it will receive the material that is assigned to the block instance. So placing the block instance on a specific layer and setting the block instance material to be the layer material you should get the material from the layer.

Does that help?

Thank you for that Nathan. Unfortunately no. Most of the block files are of components that have a number of render materials to them. However I did make the effort to ensure that in the block files, there was no application of render material to objects, but application of render materials to layers only. It hasn’t helped though.

I also can’t work out why when using the block manager to delete a block, it does not remove the now redundant extra layers that were unique to the deleted block, and also the render materials that were unique to the deleted block.

Maybe you should post your rhino file so that people could help you better.

Not sure which ones to post and they are probably too big to post directly so I will organise them for a dropbox link. Is that appropriate?

Dropbox should be fine

Ok. I will be a little while because I have to use another device.

Ok. This one shows a fuselage sitting on 2 milk crates. Dropbox - Sonerai Assembly.3dm - Simplify your life

This one is the milk crate.

The milk crate file has the render material as blue paint, yet in the assembly file the crates are red.

Also, here is the wheel and note how the names of the materials, “hub” and “tyre” have changed in the assembly file. Why?Dropbox - Sonerai Main Wheel.3dm - Simplify your life

There looks to be a bug here, I can repeat with very simple files.

OK. Thank you for your time Nathan.

I have logged this as bug RH-62518.

@hwansey for now in your original files you could rename the materials to something unique - pre- or append some string to your material names. That way you don’t have to wait for a fix if you are on a deadline.

While you are there, here’s another one.
Shaded view:

When switched to rendered view:

What happened to the wheels? They are in the file as a block.

Here is the file:

You probably need to upload the wheels as well:

Ah…Sorry about that:

As you can see from my render screen shot, the wheel is still there because it is in the shadow/reflection.

Is this an issue with the auto ground detection in the undercarriage file?

That looks weird indeed. I have reproduced this with your files and logged as RH-62541 Block instances become invisible in Rendered mode with reflective material on ground plane.

After some discussion with devs the solution for your case is to run the Rhino command _RenderImportConflictOption _AutoRenameIncoming. This changes an application-level setting and is persistent.

After running this command you will see your milk crate stays blue upon opening the Sonerai Assembly.3dm.

Thank you Nathan. Worked a treat.

For a file such as the assembly file, is it better practice to assign the render material in the assembly file and to leave the files used as blocks empty? I am deliberately adding the blocks as “active” as opposed to “referenced” in order to consolidate the building material in the assembly file and to be able to render by layer and not by object.

I was thinking this may have the added advantage of being able to save the block files as “save small”. Is this the case?

RH-62541 is fixed in the latest Rhino 7 Service Release Candidate