Hi Jeremy

What the topic title discribes happens to me in two different scenarios

A - I think we already talked about. Sometimes a render export hangs for up to several minutes before he continues exporting. This is not very regularly, sometimes it runs fast, sometimes it takes ages to export. I have no idea what could be causing this.

B - And this is more serious: In some of my files the material editor gets extremely slow when I try to render out a new material preview. Then the whole Rhino hangs for several minutes and you cannot do anything. After that time he starts rendering the preview. This is not due to heavy textures or anything but happens for the simplest materials. But I think it only happens in complex scenes. Would this help if I sent you a scene I'm having trouble with?

I think the first scenario isn't really a problem since it only happens from time to time. But the second one makes it very hard to continue working with these files.

A file would be necessary in either case. Regarding the second, what is the chance you are using pretesselated displacement in the material? There would also be the question of how many threads you have, how many you have allocated to Maxwell Fire (assuming it is running), and how many you have allocated to the material preview in plugin options.

With multithreading, it is not as though you can cleanly stop a process at a particular instant, each thread must instead check periodically whether it should stop, and this only occurs when it is in a state where that is possible. There is a balance between how frequently it checks, and how many CPU cycles are wasted in performing the checking, rather than doing real work. Fire checks quite frequently, in order to be responsive, but if much work must be done (e.g. allocating/deallocating millions of pretesselated triangles), or if the render is at a more progressed stage (higher SL), then there is some delay involved, and this is only compounded in the case that you are utilizing all threads in running two concurrent renders (in Fire, and in the material preview). It may help in some cases to experiment with different threads settings, to find ones that are most suitable to your situation, and/or to disable auto-updating of the material preview renderer when running Fire, so that it only updates when you actually click the Refresh Preview button.
I will be able to see in the files whether pretesselated displacement (or some other expensive rendering option) is in play, but please also let me know concerning the other variables I mentioned, i.e. whether it is mostly a problem only when Fire is running, how many cores are available on the machine, how many threads are allocated to Fire, how many threads are allocated to the material preview in plugin Options, and whether disabling auto-refresh of the material preview helps. A threads-related problem should also be much worse if you have Maxwell rendering in the background, so I would like to know if that's a factor too, and if so, how many threads are given to Maxwell.
You might haven been right with the other variables - I am not able to reproduce it at the moment. I'll try to narrow it down, the next time it happens.
I'm pretty sure that there was not displacement involved, that was what I checked. So it has to do with either fire or a background render running.
I think I got an idea now, when this problem is happening.
The freeze is really simliar in duration to opening a file with missing textures (it browses through all the path you put in the preferences). The same freeze happens when you paste an object with materials that have missing textures into another scene. Both of these freezes are "good" freezes, because they are meant to find the missing texture because it's destination has changed ...
The other freeze happens in some scene files when you try to update the preview of a material. Until now I didn't have a clue when this would happen, but I think I got it narrowed down to some missing textures. If you have ANY material in your scene that show's "Has Bad Path? = YES" then the freeze happens ... if you delete those materials it does not improve immediately, but only when you close and reopen your file. Is there any way you would be able to reproduce this and maybe improve it?
Besides, I thought it might be a nice extra to have the materials highlighted that have missing textures and making it more obvious that there is something wrong. My suggestion would be to frame them with a red border (as is done with the green border for linked mxm's).
Material thumbnails are already given a red border, when they refer to a missing MXM file, and an orange border when they refer to an existing MXM, but have been edited inside Rhino (meaning that the material inside Rhino is different than what will be loaded from disk by Maxwell). So how about painting the standard "missing texture" icon (the 2 x 2 red/black checker) over the corner of the material preview, when textures are missing?
that would work too! I've never seen the red board until now, only the orange and green one.

Is it possible that linked mxm don't work anymore as they should?
Here's what I do:
Open an empty rhino
create a new material
save the mxm to the disk
"Load the MXM data"
(now it has a green border)
save the rhino file
close rhino and reopen file
the green border and mxm link has disappeared

Is that a setting I got wrong or a bug?
Settings do not stick

Quick update - if you save the viewport again (in […]

I don't understand why it is so difficult to have[…]

Backplate rendering - reflections

Ok, thanks, so Arnold can do https://answers.arnol[…]

Nested Dielectics were introduced on maxwell 3.2[…]