[kami]

Hello

I got a few questions concerning the material behavior with linked blocks and maxwell materials applied via layer. I'm starting to use this method more and more and would like to know if that could cause any problems. I'm not talking about referenced mxm's, but integrated ones.

There is the easiest possibility when you link a block (referenced and not embedded). Then it shows its material as BLOCK.3DM:Material Name. I am assuming it does not load the material in the material list then? And you would have to go to the original file to change a used material? But is it possible that there could be any issues if the same material also exists in the original file (and maybe not the exactly same material but a slightly changed one, but still with the same internal material id)?

The other possibility is to link a block as embedded and linked (I prefer to use this method because you can't lose parts of the model if some external file is moved or accidentally deleted).
Now all materials are copied to the new file. What happens if I change one of these materials eighter in the external block (and update it) or in the originale file? Is it always overwritten with the material of the block or does it use the material already in the file if possible?
And what happens if I move the layers of the block to a subfolder? When I update the block it creates the layers new according to the layers in the block, and the moved layers become empty, correct?

Could I avoid all these questions by only using referenced mxm's?

Thanks for a short insight on how external blocks work in combination with maxwell!

Cheers, Christoph

[JDHill]

I assume you're referring to this in the context of Rhino V5, correct? Probably the easiest way to answer this is that the plugin is not aware of the difference between Rhino's "Embed", "Embed and linked", and "Link" block insert options (I do not even have a full understanding of their operation in V5 at this point in time). When a block is inserted, Maxwell materials it contains are read and added to the current document; they are not subsequently re-loaded from the linked document, if you change and save and/or update the inserted block. That is to say, Maxwell materials always behave as though you were using the "Embed" mode for your block inserts.

Therefore, if you want to use linked block references in Rhino, you are probably best off using MXM-Linked materials; in that case, the material state contained in the document being rendered is irrelevant in all cases but one: if the linked MXM is no longer in existence, the material of course behaves as any other embedded material. Otherwise, the material will always render using the state contained in its MXM file, which naturally, is fully independent of all other factors.

[kami]

Yeah, you are right, I was talking about the block features of rhino5. Understandable that they are not really supported. However they still do work and I wanted to try to understand how.
Maybe in the same way as if you copy some objects from another file into the current one? How does the plugin handle the materials for this case?

I do sometimes get the question if it should change the layers material to the ones assigned in the copy of the file (I never get this question when updating an external block). But I noticed that with blocks, if I assign a material to a layer in the external block, the material assignment is only copied if the layer in the original files does not exist yet.

Working with linked materials works pretty well, but I noticed when I assigned the same linked material in several external blocks, I get multiple instances of this material ("chrome", "chrome (2)", ...). They all point to the same source so it should not be a problem when rendering, it's just a bit confusing. But this happens as well when copying objects from another file...
And I noticed that the name of the material displayed in the layer tab does not always match the assigned material (e.g. still showing "plaster (2)" when I renamed it to "plaster yellow").

[JDHill]

Don't worry too much about the names of materials, there are multiple levels of potential issues with them, but in the end, when you export, the plugin makes sure they all get a unique name. Where Maxwell has a requirement that they have unique names, Rhino does not, and the plugin doesn't either, though it preemptively renames materials to try to keep them unique for Maxwell. I see that changing the Maxwell material name is not currently changing the name of the Rhino materials it is associated with; I'll see what I can do about that.

The dialog regarding material-layer assignments serves only to determine what happens when you import or insert a layer into a document, where that document already contains a layer of the same name. In that case, the plugin cannot determine what might be your intention, without asking. I have not tested this in Rhino 5, so I cannot really speculate on what might be the sequence of events involved in this process there. The plugin, being a Rhino 4 plugin, still conceives of layers as things that cannot have duplicate names -- Rhino 5 changes everything here. As you may recall, I also put in code to handle this possibility in 2.6.15, but that is only concerned with export, and preventing failed exports due the previously-impossible situation where you have multiple layers using the same name.

Maybe in the same way as if you copy some objects from another file into the current one? How does the plugin handle the materials for this case?

Basically, if a material read from the inserted/imported document does not exist in the current document, it is added, otherwise, the one in the current document is kept. This is not determined by the material's name, but rather by its internal ID, hence the new Maxwell_MakeMaterialsUnique command that I added in 2.6.15.