[kami]

Hi Jeremy

Lately I've experienced something weird when closing rhino.
Rhino would not be closed correctly but still running in the background. I noticed that when I wanted to reopen a file, I closed a few minutes before and it said that it was still in use.
So I checked the processes in the task manager to find a rhino.exe process running at 12% CPU constantly and using 5GB of RAM. It was not listed under 'applications' or shown in windows and without checking the tast manager I would never have noticed that there was still a rhino running.
I have no idea, if this has something to do with Maxwell, but I have no idea how to investigate further, as I've noticed that quite a lot lately on different machines ... Maybe you would have a hint?

Thx, Christoph

[JDHill]

The only thing I can figure, if it is due to the plugin, would be that FIRE was still in the process of stopping (I'd tend to expect more CPU usage than 12%, but that depends how many threads you've allocated to FIRE). I haven't seen anything like that here, though, so I'd try disabling/uninstalling any plugins but Maxwell, and see if you still observe it.

[polynurb]

the other day i was experementing with pretesselated displacement, had some bad settings with subdivision and rhino ate 30GB of ram

it didn't crash, but it would not give free the ram. even after closing fire window and clearing mx cache data.

if i would try to stop the tesselation process.. which took minutes, i basically ended up with the same situation Kami described.

[JDHill]

That seems like something which could (not that it should) happen, but over which the plugin would have little (read: no) control. Meaning, you could clear caches all you want, but it wouldn't be likely to do much, since it wouldn't be the plugin's code holding onto that memory.

[philip99]

yes something strange happening, rhino not closing properly
-Philip

[JDHill]

The question is: when and how? Open Rhino, try to close it as soon as it's finished loading, and it doesn't close? Or open it, and export an MXS before closing? Or render the model in FIRE? What is in the model -- materials, etc? Does it happen with every 3DM, or a specific one? And which version and SR of Rhino is being used, V4, V5 32-bit, V5 64-bit? As I wrote above, I am not seeing this here, so I really can't help without more details.

[kami]

It is pretty difficult to narrow it down, as I didn't find any clear pattern yet. Today I noticed the following in one scene:

I had to add some stuff from an older project into my current file. As the old project had been moved to the archive server and our material library was changed slightly during the last weeks, the path had changed and there were a lot of missing textures. A Maxwell_PathStatusReport showed 10 materials with bad textures. When I copied the elements into my newest file, he was looking for missing textures in the path specified in the plugin settings. (That takes quite a while as our material library is quite large)
After a few minutes he had found all the texture but one. I corrected that material manually. Now Maxwell_PathStatusReport shows no wrong path.
I saved the scene. (not important I guess )
Then I rendered it. Even though the scene is not huge, it took 5 minutes before he even started to export the meshes. That is a different problem I'm having quite often lately, but maybe it has something to do with the problem ...
After that, I closed the scene (without saving it again). Now rhino did not close and kept running on one thread, even though the file was saved completely and I did not see any open rhino windows. I once noticed that it'll close after a while by itself, but it takes several minutes until it is not listed under processes anymore. In my case I killed the process.

Now I reopened the scene and closed it again -> no remaining processes
And I open the scene and redered it -> now the mesh export starts immediately and is done after 10 seconds. When I close the file, no process will remain.

Any clue?
I am pretty sure it has something to do with any wrong path he had found. But even after fixing that path, he still has problems.

[JDHill]

I don't yet see much specifically interesting in that scenario, except that you say you have at least once observed the process to complete successfully on its own. Whether the delay in closing is indeed due to the plugin, or to some other component, the fact that it can eventually close implies that there may be nothing actually wrong; it only indicates that there is a thread doing some work, which eventually completes. What the nature that work might be, and whether it should somehow be completing quicker, I can't yet speculate.

Incidentally, I would suggest, in a situation such as you describe, making sure Options > Search Paths > Check File Version is set to No. This is not related to any question of Rhino being unable to close, I just mention it because what that option does is check the actual file date for referenced textures whenever they're accessed, in order to update their thumbnails and previews when you've changed them in an external program; this can be quite expensive, though, especially when a network is involved. It should also be quite rare that it would matter -- even if you did edit a texture (in Photoshop or whatever), it's probably not usually the case that you absolutely need to see the change in the plugin's UI (and this option only affects the plugin UI -- the render engine uses its own rules for checking files).

[kami]

hmm, but were you able to reproduce it?
I don't have 'Check File version' enabled, but thanks for the tip.

could you maybe try the following:
make sure you have some larger folders specified under 'Search Paths' as 'Textures Folder', maybe even a network folder, so you have an extreme scenario.
prepare a file 'A' with a material that has missing textures. (delete that texture, so it can never be found)
now create a new file 'B'. open file A as well and copy an object which has the broken material assigned to it from file A into file B.
the pasting of the object into file B should take a few minutes, because he is looking for the texures. I think that is where the problems start.
now save file B.
start a rendering. Rhino stops after 'Maxwell: Exporting new data, press Esc to cancel' and becomes not responsive for several minutes. Then the rendering will start.
After that, just close the file without saving.
The rhino window closes, but in the task manager the rhino process remains. Is always has a CPU usage of one core and the memory conspution goes up pretty heavily (from 1.5GB to 2.5GB). It took me 30 minutes this time until the file was closed.

I'm pretty sure it has something to do with the missing texture.
Sorry that I am insting so much on that topic, but these pauses of several minutes sum up to a few hours every day for my team. So I'd really like to have a fix there.

If I repeat that procedure, but fix the missing texture manually before starting the rendering - it is still the same.

Finally, I did the procedure again, but this time I disabled the 'Perform Path Checking' and removed all 'Textures Folder's just in case.
Now, the rendering starts immediately and rhino closes correctly after closing it.

For me that narrows it down to the 'Search Path' feature, which is something I really need, so I can't just disable it.

[JDHill]

Yes I have tested it, for example, opening a 3DM located on a mac machine, from my main windows machine, which references textures that are missing, but which may be found four folders deep on different (windows and linux) machines. It works fine, and I don't observe the behavior you describe.

The thing is, technically, what you describe cannot be related to plugin code for checking paths, because there is no code related to that, which runs on its own thread, independent of the plugin UI. That means, any code involved in checking a path has already stopped running before Rhino's UI can close. What you describe is code running on its own thread, and sounds much more like what might be expected if one of your materials was using pretesselated or vector displacement, where the engine may take awhile to stop rendering and cleanly de-allocate the memory it is using. That also fits with your description of large amounts of memory being used, which is not something that would be associated with checking paths, which are just some small strings.

[kami]

What am I supposed to do right now?
I can reproduce it every time on several machines in our office. (didn't try all machines yet) I don't have any textures with displacement in my file.
And disabling 'Perform Path Checking' makes all the symptoms vanish immediately.
I need to fix this... Could you tell me how I can find more out about the problem? Or if you like you could have a teamview access to a computer.
Thanks for any help.

[JDHill]

There is very little code run when Rhino closes, but looking at it, perhaps I see a possible factor: the last thing it does is release the license, and this is of course something that only applies to Maxwell 3. I seem to recall you having various issues with the license manager, so maybe it could be that the plugin is waiting for the licensing code to contact the server and release its license. Unfortunately, I don't know really how that works, and whether it could be a factor, and neither do I know off-hand whether a wait at that point would still allow Rhino's window to close, so I will have to do some tests. Depending, maybe I can send you a special build which doesn't try to release its license -- from my understanding, the RLM server will still release it eventually, regardless. I think that's a long shot, though.

Meanwhile, if this were happening on my own machine, what I would do is use ProcessMonitor, and/or Network Monitor, to try to see what is trying to be accessed, and why it may be taking so long. Though, as I say, the plugin itself will not be running code after Rhino close based on whether Perform Path Checking is enabled, there is an outside possibility that its querying of the network causes some other software to become involved.

[kami]

Maybe if we don't focus on the closing process, which for me is a minor issue, but on the fact that he often hangs after he has fixed some missing textures. I just thought that they might be related, as it were only happening after he had to look for textures.

For example the fact stated above:
When I copy an object with missing textures into my file he is looking for the textures. That's where the problems start. Even when he finds them and corrects the path, starting a render freezes rhino for several minutes. Sometimes even double clicking on materials freezes for several minutes, or selecting an object in the viewport. If I close (and kill) Rhino and restart the file, I can work fine with it. The most important part is, that the problem is gone completely (both the hanging before rendering or after exit) when I disable the 'Perform Path Search'.

[JDHill]

When a missing file is found, its path is fixed in the in-memory object (e.g. a material) that references it. The fixed path is then stored in the 3DM when you save it, so next time you open it, the file will no longer be missing. However, if the path in question was not read from the current 3DM, as would be the case when referencing MXM or MXS files, or linking 3DMs, then this path-fixing process would need to be repeated every time you opened the 3DM. The only solution is to open the referenced files and fix the paths that they contain. For MXM and MXS files, there may be a double payoff here, since if you use Pack & Go, both the plugin and the render engine will need to resolve their paths .

The upshot is: if you use files that contain broken references, and if you have Perform Path Checking enabled in order to fix them, then the plugin will try to do so. This functionality, however, is not intended to enable the establishment of workflows where referenced files are routinely missing, or expected to be found at locations other than the paths written into your files. If it were to be misused that way, then the price paid in terms of waiting for the OS to confirm the existence of files could be high, depending how much searching ended up being done. On the local machine, a successful file access is effectively instantaneous; on a network, it depends, but should not be bad, if the network is healthy and fast. Asking the OS about non-existent files, though, and searching through tens or hundreds of directories, trying to find matches between missing filenames and potential candidates, can take a lot of time, but the plugin will do it, if that's what you tell it to do.