Problem textures resulting in very high RAM and CPU use

I’m starting this to split off part of the discussion from the thread linked below regarding very slow opening and saving of files.

The discussion had become confusing because of 2 or 3 potentially different issues being discussed within one thread. This happened because it was thought they may have been linked but this seems unlikely now.

@nathanletwory

Hi @nathanletwory

In reply to your post on the other thread

It hadn’t occurred to me to try importing instead of exporting. It is amazing how the problem file imports extremely quickly. Then changing to any other view than wireframe results in the very long delay experienced when trying to open the file normally, along with the high RAM and CPU use.

Just turning off (unchecking) the texture within the chair material seems to have solved the problem and that avoids needing to reset up the environment, sky etc.

One thing, I can’t figure out how to detach the texture completely? It seems like we could do with a :wastebasket: icon to remove textures completely without having to choose an alternative.

I had tried ‘right’ clicking on the texture and had no luck but I’ve tried again when clicking on the file name and it comes up with a contextual menu which includes the option to remove the texture.

That’s good but it is now taking a very long time to actually remove it. Similar to the delays experienced when opening and saving.

Having now removed it (and the ‘stone’ texture too) things seem to be much more manageable.

Yes, starting Raytrace is still taking a long time for me but opening and saving the files has improved dramatically. Thank you.

On the issue of the model failing to render in Raytrace mode.

Removing the texture(s) seems to have resolved that too although, strangely the clipping still happens when rotating the view (ie in render view).

Once you have ensured the texture is no longer in use by any other render content you can use the Purge command. That should get rid of anything unused.

I’m sure @andy will get to investigating the memory leak problem soon enough. I’ll link this topic to the YT item, so you get an update whenever this is fixed.

Thanks, I’ll report back if it crops up again. I might have a go reducing the size of the texture and see if that helps too.

The memory leak should be fixed in the latest RhinoBETA. Please let us know if you see it spike again.

Hi @dan

It is not fixed for me.

Robin

edit: I should add that the big black area is supposedly rhino. This is after a couple of minutes of loading a file.

Daaaaamn.

Sorry, this was a mistake. The commit to fix this bug did not go into latest RhinoBETA. The issue itself - RH-53262 - said that it did, but that was an error. Upon further inspection, this went into the build that will be Rhino 6 for Mac SR17 (the first update). I’ll let you know when a testable build will be in the wild.

So you’re going to ship Rhino V6 for Mac with a major bug like this?!

Our plan is to ship the first service release candidate on the same day that we ship. You can choose to test the release candidate right away and in typically about a month the release candidate will become an official service release.