Rhino is notorious for having extremely bad performance with mesh models, notably STL files with plenty of polygons. Is there a way to reduce the often crashes of Rhino by making some optimized settings?
Seems like the Undo stack causes a lot of problems, because Rhino freezes and crashes after several transformations (moving, rotating, scaling) of the same object. Even if I only move the same non-modified STL model (a bit over 30 million polygons) 3-5 times and do nothing else, my Rhino 7 crashes. This happens on both, my laptop and my desktop PC running Windows 10, I also tested on two other machines with 32GB and 64GB, so itās not related to the hardware.
The RAM usage gets super high after each moving of the model and will never go down to the original state. I canāt install a gazillion GB of RAM.
If I press the Undo button after moving the aforementioned STL model, Rhino freezes, my SSD starts to run at 100% and the RAM usage goes from 5 GB to 100% in seconds. If I have a luck, the program will not crash, but sometimes it does. Most of the time it will not save a back-up emergency file (it did so only twice after more than 50 crashes). It will also not offer me to send a crash report.
My question is: How to prevent these crashes, especially filling the RAM constantly!?
My second question is: Which directory Rhino 7 uses to store extra information when the RAM is filled entirely? I noticed that my SSD is working hard when the RAM is used at 100%. I had 28GB more space on my SSD just a hour ago, now itās occupied by some hidden files written either by Rhino or Windows. I restarted my Windows, but the space is still occupied.
Back in the old days Windows automatically used virtual memory when it ran out of RAM. I canāt remember what the virtual memory file is called, and I donāt know if todayās Windows still does it - although it is reasonable to assume it does.
When virtual memory is in use all memory accesses are done at ādiskā speed (SSD speed these days) instead of RAM speed so naturally things slow down big time. The only solution is to stick to smaller files or add more RAM - hopefully not āgazillions of GBā but just a stick or two.
Or maybe its actually something else that the McNeelies can provide good insight and suggestions about.
If you intend to only move/rotate/scale your STL scan then I suggest you create a block out of it. Moving those doesnāt change the geometry whereas moving a regular Rhino object changes the geometry.
Aha! and no doubt in the process there is a period where both the original object and the new one exist and so the memory requirement temporarily doubles? - a serious OOPS! if the original is already consuming over half the available RAM.
Just to clarify, Iām working with an STL file of a laser scanned front bumper. The main issue is that the scanned model is oriented in some random position, so I try to approximate the correct orientation by making a History-enabled mirrored copy of the bumper with different material, then I move and rotate the original model until both models align to each other. This requires tens of transformations, but Rhino crashes quite often. Not to mention that there is a very long delay after each operation. Even a simple task such like selection or deselection takes over one minute.
Another strange behaviour I found is that the viewport performance is very different depending on the position of the model. The framerate may be good for a while (more than 15-30 frame per second), then I rotate the model slightly by 1 degree or less and suddenly the framerate gets super slow (much less than one frame per second). Then I rotate the model again and the framerate is normal as before. No idea why this is happening.
I just turned off my virtual RAM, because I noticed that Windows 10 occupied 35 GB from my SSD, which, obviously, degrades it quickly. I canāt use more than 32 GB RAM total on my PCās motherboard. From my observations this particular STL file requires more than 60 GB of RAM, despite that it takes just 1,3 GB of disk space. Maybe itās time to upgrade to another PC with 64 or 128 GB RAM.
The sad thing about this is that programs like Z-Brush can handle much more complex models with a minimum amount of RAM, but Rhino is not optimized for rendering of 3d meshes.
It does not explain why exactly the same model could lead to poor performance or good performance, depending on its orientation in the 3d space. We talk about very little difference in the orientation, such like 1 degree of rotation or less.
If the issue is in the VRAM, then I can upgrade to a new video card with 12 GB ov VRAM, such like RTX 4070 Super (currently, I have GTX 1660 Ti 6GB). But Iām not certain that this alone will fix the issue I have with the huge memory leak caused by Rhino.
My motherboardās maximum capacity is 32 GB of RAM (supports up to 4x 8 GB DDR3 RAM). This is why I intend to buy a new PC with 96 GB DDR5 RAM (2x 48 GB). If this is still not enough, I will upgrade up to 192 GB total RAM.
I will experiment with inserting the model instead of importing it. Not sure whatās the difference.
Also, what you say about the PLY format sounds promising. I will try to convert the STL file to PLY and check if it will be lighter in Rhino. Thanks for the suggestion!
The advantage of inserting is that you donāt create a copy of the file saved in the Rhino file. The file size is smaller. The downside might be that you have to load the file everytime you use the Rhino file.
Iām inserting less and less scan files due to layer issues. My new method is to import the file through Grasshopper, using the new Grasshopper Rhino componentsā¦ Rhino 8 howeverā¦
The meshing process needed to Export selected as a PLY file took several minutes and my Rhino 7 froze for a while, but the good news is that the file size of the PLY is 183 MB compared to 1390 MB as a 3dm file. Now lets see how it will behave when I insert it as a block instanceā¦
Just a quick question. Which option should I choose from the following pop-up window?
After some clean up of tiny mesh particles, the model consists 28ļ¾ 655ļ¾ 574 polygons now. This is still too much for my PC, thoughā¦ It had more than 37 million polygons originally.
or add more RAM - hopefully not āgazillions of GBā but just a stick or two.
