Recently my Rhino 7 crashes multiple times a day (and sometimes Windows 10 freezes forever) while working with 3d mesh scan data, so I guess it’s time to upgrade to a new PC with modern CPU and GPU that hopefully will not crash as often. My current PC is from 2014 and 99% of the time Rhino 7 performs quite well with large NURBS files up to 2-2,5GB, however, 3d scan data burdens it with ease and every moving or rotating of such a 3d mesh model is followed by at least 2 seconds of a delay, which is very frustrating. Sometimes a simple moving of a mesh model with a few millimeters to adjust its position causes crashes. Also, Undo it super slow in this case, unlike the super responsive Undo while working with NURBS models.
I thought about upgrading my system RAM to 32GB, but noticed that Rhino 7 crashes right after more than 5-6GB of RAM are being used, despite the fact that I have a total of 16GB. Is that limit related to the system RAM or the video RAM (using Nvidia GTX 1660 Ti 6GB)? I try to avoid upgrading my video card with a new expensive model consisting 12GB or 16GB video RAM just to figure out that the crashes are still present and caused by something else. My RAM is old DDR3, so it may be a part of the problem.
Do you have any recommendations about what CPU and GPU are proven and capable to handle scenes with several 3d scan models of car panels with up to 10 million triangles in the scene without crashing every few minutes?
My current PC has the following hardware:
Intel Core™ i5-4460 at 3.2GHz
4x 4GB DDR3 RAM at 1600 MHz (12,1GB free)
Nvidia GTX 1660 Ti 6GB
SSD Samsung 860 Evo 250 GB, SATA III
Motherboard ASRock Z87 Killer
As I mentioned above, I’m super happy with my PC despite its age. It’s the 3d mesh models that cause the crashes, so I do some research to see if the issue is related to the old hardware OR there is some limiting factor in Rhino 7 itself. Thanks!
Graphics card is the key here for sure! I upgraded first to a 3070, and then to a 3080 for this very reason - a lot of my work is large laser scanned data sets. On my 3080, I’ve currently got a laser scan of a BAE-146 I’m working on that’s 18 million polygons. The 3080 spins that thing like a top, super smooth, no stability issues. If you can get a 3080, that would be my recommendation. Even with a 3080 you can still find the limit tho if the data is overly dense garbage - a vendor sent me some really ugly, overly dense data that was about 5 gigs - that choked my system.
Also should add - my new best practice when using laser scanned data is to put it in a Block, and then bring that block into your session as a reference. This way whenever you save the file, you’re not constantly saving a huge chunk of data that’s already been saved.
That’s a really nice practice, thanks for the advice! I have been using blocks for quick modification and replacing of a huge amount of screws, but using it for importing 3d scan data sounds reasonable.
I figured out that the majority of crashes related to 3d scan data happen when I have 2 or 3 mesh models aligned to each other, so that that many of their triangles intersect to each other. If the meshes are put separately, the framerate is much faster, however, putting them in the same place causes a slowdown. Maybe something related to the Z-buffer? I use a few 3d scan data aligned together as there are areas that appear better in one scan while another one has another area scanned better. So, I combine all of those to get the best results.
Why Rhino is the only program that has super huge problems with STL scan data? Any other program that I have used works smoothly with the same files that cause often crashes of Rhino 7 and non-customized, totally default Rhino 8 Evaluation. This is a proof that my PC is more than capable of handling such models, but for some reason those files suddenly get extremely heavy for Rhino. I can open 50 times more complex STL geometry in Blender. My CPU, GPU and RAM are not fully utilized by Rhino while I work with simple STL files, yet the program crashes and even my Windows 10 freezes. Only in Rhino.
Does anybody have suggestion about some settings? I turned off the anti-aliasing, closed any other program, even tried with 1080p screen resolution. Crashes every minute with STL files, even when rotating or moving a simple mesh model. Larger models bigger than 500MB can’t be opened due to filled memory (despite that no more than 7GB are used by Rhino).
By the way, the first selection of a STL mesh model takes about 30-60 seconds of “thinking” until Rhino is finally able to select the model and mark it in yellow. Next selections of the same model are quicker. Rhino crashes even when I select the same model several times and do nothing. Just simple picking with the mouse.
I’m regularly working with scan data with 5 million faces. I have to wait a second or two when I’m dragging a mesh with the gumball but I don’t have crashes from just rotating or dragging a model around…
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 128GB)
.NET 7.0.15
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA RTX A5000 (NVidia) Memory: 22GB, Driver date: 1-18-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.23
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1
Secondary graphics devices.
NVIDIA Quadro K2200 (NVidia) Memory: 4GB, Driver date: 1-18-2024 (M-D-Y).
> Accelerated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 1-18-2024
Driver Version: 31.0.15.5123
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 23028 MB
Rhino plugins that do not ship with Rhino
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\KeyShot9RhinoPlugin (ecfe8d1f-876a-460f-aa5e-3dd816936811)\1.0.0.0\KeyShot9RhinoPlugin\Rhino 5.0\KeyShot9RhinoPlugin.rhp “KeyShot9RhinoPlugin” 1.0.0.0
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
I not sure if it’s [one of] the reasons, but Rhino by default uses a very hight precision setting for mesh.
17 digits past the decimal point, while many of the mesh modelers uses something around 8
You can see this with the file size difference.
So possibly [I’m guessing here but you can test if you want] reducing the precision setting to 8 may make a difference… Or it’s not related at all, and it’s just an OBJ thing , and I’m mixing things up .
The model consists 576 006 faces, so its not complex at all. I have been working with 10 times more complex models a few years ago, when I used Nvidia GTX 960 2GB and 8GB RAM. Same TV at 4K resolution as before. It was perfectly fine for those STL models, so I’m not sure why now Rhino 7 has huge problems with much simpler models, 16GB RAM and more powerful video card…
I already set the file tolerance to 0,1 mm and 1 degree, but Rhino still crashes, so the bottleneck must be somewhere else. I also set my video card to Performance in the windows 10 settings. Nothing helps.
The mesh setting is not AFAIK related to the file tolerance. It has I think something to do with how the app calculate the location of each of the mesh vertices.
It’s a scan data owned by a customer and unfortunately I can’t share it. However, I can send another 3d scanned model to the Rhino support to investigate why it will cause crash to Rhino after I move it (no other editing) 2-5 times. Just simple moving with the Gumball and Rhino crashes.
Another way to crash Rhino is to sub-object select with Ctrl+Shift some of the polygons and trying to delete them.
I will also include the link to this topic in my e-mail.
One of the smallest STL files (64MB only) consists 5181 separate meshes, but I needed only the largest one. The rest meshes are leftovers from the laser scanning that are separate tiny polygons or group of a few polygons. Once I delete them, selecting the main mesh is much more responsive. One mesh with 1 millions of polygons is no issue, but 5000 objects with 1-10 polygons each fill up the RAM quickly and lead to crashing Rhino. Looks like that there is a RAM leakage.
Proposal for a new feature in Rhino!!!
Add the following anti-crash option when importing STL files:
This way, instead of importing useless 5000 objects, the user could import just the one object that’s needed and save the hassle with crashing or waiting an enormous time for a importing an STL file.
Also, Rhino is limited to show control points on objects with less than 1 million polygons. This is not optimal for the modern powerful workstations. I think that this number must be increased.
My third proposal in this topic is to add a new command in Rhino called “Split disjoint meshes”, basically a native tool which does exactly what the option of the same name does while importing STL files. I’m not aware of any tool that does this AFTER the import.
Snapping is also causing some issues, but the memory leakage of Rhino is huge. A couple of days ago Rhino used over 31 GB of total RAM (16 GB system RAM and the rest was paged file from my SSD) while I moved one object with about 1 million polygons by 20 mm along the Y-axis. Once I moved it again by a few millimeters, Rhino crashed due to limited RAM… The STL file itself was just 64 MB!
Not sure if this is related to the Undo stack, but I found that moving an STL model and then saving as 3dm file, then closing Rhino, starting it again and moving the mesh gain once (followed by saving and closing the program again) is the only way I can move and rotate mesh models with more than 1-2 million polygons without crashing.
I opened a .3dm file with 11 meshes, 7996549 vertices, 15720697 polygons.
I initially made visible a group of 4 meshes, 5866791 vertices, 11572933 polygons. Memory used by Rhino is 4318 MB. I moved, rotated and scaled the meshes and memory use by Rhino increased to 7790 MB. I had to wait a few seconds for each operation to complete.
I then made visible all 11 meshes, 7996549 vertices, 15720697 polygons in the file. Rhino memory use was 8520 MB. I moved, rotated and scaled the meshes and memory use by Rhino increased to 12678 MB. Each operation with the 11 meshes took longer to complete than with the 4 meshes, but less than a minute.
Maximum memory use by the system was 19.8 GB.
@Rhino_Bulgaria I am not seeing the problems you mention with these large meshes. Your mesh problems may be directly related to situations where there are a very large number of meshes such as you mentioned above with 5181 separate meshes.
Moving the cursor over 11 meshes, 7996549 vertices, 15720697 polygons with the Vertex Osnap turned on does not cause any problems for me. The mouse behaves the same as when moving over a surface with a lot of control points with the control points visible and the Point Osnap turned on.
