[kami]

I think I've came across a weird behavior while wanting to work with linked mxm.

My steps:
(Make sure Ignore linked MXM is disabled)
Import an mxm from my library
double click on in to open the material editor
change the mxm to make it suitable for this project
now go to 'Options' > 'Save as MXM' and save it to a new location (from where I want to have it linked)
It asks me if I want to import the mxm data as linked MXM.
When I say 'Yes', the material is in linked mode, but not with the newly saved mxm but with the original one in the library.

[polynurb]

I have noted another issue with linked mxm:
If the linked mxm contains procedurals in any slot (i know they are not supported within rhino atm)
And the material is modified and updated (mxm link) from within rhino, the original mxm looses the procedurals.
It would be great if slots with procedurals would remain untouched when updating the linked mxm.

[JDHill]

I see what you mean, Christoph, I'll put this on my to-do list.

Regarding procedurals, this is a limitation that will not likely be overcome, because it is not so much that the plugin updates an MXM, but rather that it writes its current material state to the specified file. The way of working with linked files that use procedurals, then, is to double-click the MXM in the Database Manager to edit it in MXED directly, rather than editing the structure as it appears in the plugin material editor.

[polynurb]

Regarding procedurals, this is a limitation that will not likely be overcome, because it is not so much that the plugin updates an MXM, but rather that it writes its current material state to the specified file. The way of working with linked files that use procedurals, then, is to double-click the MXM in the Database Manager to edit it in MXED directly, rather than editing the structure as it appears in the plugin material editor.

thanks, I was just thinking about maintaining a good workflow within fire.
but i just realized that, although not "live updating", hitting ctrl+s in mxed updates within fire immedeatly!
works good..

in theory, is anything opposing having a live mode in mxed? so that every change is instantly written to disk..

[JDHill]

I doubt any thought has been given to that -- the only reason it works is because you have Options > Auto-update Linked Materials enabled, which means the plugin puts a file system watcher on the linked MXM, which then ends up triggering an up date in FIRE when you save the file. Honestly, I don't think this particular aspect (auto-updating FIRE) had ever occurred to me; the main purpose of that functionality was to keep what you see in the plugin material editor in sync with the linked MXM.

[polynurb]

I was thinking about it because of the procedural limitation which is present in many host applications right now.
also because i am still hoping we get a node based mxm editor at some point. which would probably be impossible to implement in each plugin separately. now if the link to the host application via mxed provides the same/similar functionality, why not manage materials like that?

[JDHill]

There are technical hurdles (things which may be relatively easy to do in .NET on Windows, or in Qt on all platforms, may not be so easy to do in robust and generic ways, for consumption by arbitrary plugins), but I do think things should move in that general direction.