Maxwell Render | Official public forum

Even a scene with a library plane and default material takes up to 30 seconds to open/save. I remember there were some preferences one could delete to get back to normal, but I can't find the topic/post on the forum.

Any ideas?

I'd tend to look at the Resources Browser panel to see which directory it's trying to enumerate at startup (make sure it's not on a slow share, or something like that). Deleting preferences (somewhere in the registry; you can search for Maxwell-related stuff in regedit) would have the side effect of "fixing" that problem, if it was the problem, since the application would go back to the default of looking at the Maxwell 3 materials database directory. If I couldn't figure it out that way, I'd probably use process monitor to try and see what's taking so long.

"I'd tend to look at the Resources Browser panel to see which directory it's trying to enumerate at startup…"

Thanks, much appreciated; that could do the trick...

Under File > Textures List I can see that all textures used by embedded materials are stored locally, on the same SSD, where Windows, MR and all else resides. The referenced materials deployed for the scene also have all textures stored there.

Could you explain your monitoring method in more detail? Where exactly do I have to look in the Task Manager's Resource Monitor when loading or saving a scene to see what activity makes those (Not Responding in the window title bar for several minutes) troubles when opening and saving?

http://screencast.com/t/SnbauRzyJ

I saved one of the scenes giving me trouble (7 MB in size) under a new name, and that was now much swifter, also when opening it. But a subsequent saving of that scene (same name) slows it all down to a watching paint dry experience again...

Many thanks!

By Process Monitor, I was referring to this application, which can monitor file system (and registry, etc) access by applications on the machine. It can generate a lot of output, and so provides ways of filtering based on process name, etc.

As far as trouble with shares and the like, even when the files you're accessing are on the local machine, it may be that they contain paths referencing non-existent shares. If you open such a file, it may take some time before the OS gives up looking for a referenced texture that's supposed to be located \\somewhere\that\doesnt\exist\tex.jpg. If there is a tex.jpg able to be found in the search paths, then when you save the file again, the path will be "fixed" in the newly-saved file, but this will only work for those textures that are able to be fixed. You have apparently tried exactly this strategy, already, with only fleeting success.

For files referenced, which are not able to be fixed, though, another factor may come into play: if you try to find a file on a non-existent share, the OS isn't going to wait the full timeout for every request; it's going to say, hey, I just checked, and this server doesn't exist, so it may quickly tell us that, no, we don't find that file. However, after some period of time, or when closing/re-opening the application, etc, it may make the full effort once again.

So, it may be useful to actually know the paths you are dealing with, and for that, you can use a little python, like this:
All this said, I can not give you a definitive answer as to what may be causing the slowdown in your specific case. If you run the above script in pymaxwell, you'll see that its textures point to a share that doesn't exist, and here on my machine, I have no lag at all with opening that file in Studio. In other cases, I know that I've waited a while (on the order of tens of seconds) for the OS to give up looking for something on a non-existent share. So this is all just meant as general information, which might or might not help in your specific circumstance.

Thanks, that's very helpful - I try that over the weekend. Since no other users complain, it must be something not related to 3.1 as such, but some local mess on my computers.

Ok, I have used your script on various MXSs (3-7 MB, 8-13 MXMs) that used to open near instantly (the PCs have SSDs) but now take over a minute to open and save - no non-existing shares, etc. come up.

Also, Maxwell Studio itself still hangs half a minute on "Creating Menus..." when starting up.

Any other ideas you suggest I can try?

Thanks!

Not that I know of... maybe try checking that you don't have some aggressive anti-virus or similar running, locking or otherwise interfering with the application's ability to access files or the registry? As I say, I'd use process monitor to try and get an idea of what is actually being waited for.

No antivirus apart from MSE. Other software is not slowed down. I best check now with your Process Monitor - what should I look out for and where, not having used that software ever before? It looks a bit daunting...

Well, you'll just start it monitoring, and see the thousands of file system (&c) calls that are made. You will want to filter events on the Studio process, to limit the volume of output. Then, it is just a matter of looking at what is being accessed, and whether there are any accesses that seem to be taking a long time. Please remember, though, that I have no way of knowing what's actually happening on your machine, and that you may therefore find nothing at all by this method.

Ok, interesting: When not connected (WLAN) to the internet, Maxwell Studio opens instantly and files open and save as fast as expected.

This is not so convenient, having to disconnect from the network when opening Studio or files. Any ideas as to why this is?

Thanks!

Sorry, but no -- were that happening on my network, I'd probably try to use something like fiddler to figure it out.

Ok, thanks - with Fiddler, I do what? Connect to the WLAN, start Maxwell Studio and also open/safe MXSs, and then watch out for... what?

I tried it, and I don't find Studio communicating through any channel that fiddler can see. But, I see activity (naturally, what with licensing, perhaps update checks, or similar) in the network tab of Windows Resource Monitor. There's not much more I can tell you at this point, but I'll post again if I think of anything.

When you disconnect network, is Studio still licensed? Have you tried also a test with all firewalls / AV off on both this computer and your RLM computer (in case they are separate).