[JDHill]

Similar behavior does not appear if you check using Object Properties > Material, this appears to be specific to layer materials.

[kami]

Repeat steps 8 & 9 as many times as you like

Okay, I'm still reapeating, nothing happens ...
Yes, I can confirm that behavior.

[polynurb]

I very rarely assign mxms by layer (surely not in the case I posted) but still ran into this.

same here

[polynurb]

Jeremy i can confirm what you described about the layer material assignment.

in fact i was just browsing my mail to look for my description concerning object based assignment from back then, and found a draft i probably never sent you

i"ll just paste the important part as there are a few people here, and it also refers to blocks like kami's problem.

The materials dissapearing, it is not that they are deleted, but the objects loose the assignment.
it is shown correctly in the rhino material properties tab, but in the maxwell one they are gone.
But they still do exist in the scene.Also, if in a concerned maxwell material i had selected a texture slot, so that the texture was displayed in the viewport, the corrupted "rhino" version of it will contain that texture.
(so eg. sometimes i see objects rendered with blue normalmaps as color)

It is not related to blocks, but it happened to objects inside embeded blocks too.

linked blocks i use with imported materials, so probably they are not affected.

also i never loose the actual "plug In" flag, the material is simply vanished from the maxwell tab.




and,
not sure if i ever mentioned that the texture loaded in the resulting rhino material will not contain the original texture, but a path to a "proxy" texture! this will be revealed if i uncheck the plugIn box to display the corresponding rhino material.

[JDHill]

This describes the opposite situation: the Rhino material shown was created by the plugin (the proxy texture path is not unexpected, it points to a file written by the plugin to stand in for a texture format Rhino does not understand -- mxi, etc -- in order to show it in the viewport), and it still holds a plugin ID, which is why it shows up with the "Plug-in" checkbox checked. However, there is apparently no corresponding Maxwell material in the model, so the trick will be to figure out how a model gets into this state.

[polynurb]

However, there is apparently no corresponding Maxwell material in the model, so the trick will be to figure out how a model gets into this state.

which would mean the IDs somehow mismatch,or?

because the actual material, still exists in the scene.

[JDHill]

Basically, yes, the ID in the document is not found to match that of any material in the scene. Material names are arbitrary, only being made unique because that's a requirement of Maxwell (meaning, it is not a requirement from Rhino's point of view, or from the plugin's), but perhaps one approach to this problem will be a command you can run to re-associate objects with materials based on name alone, if/when this situation arises.