My Rhino 7 crashed while working on a very simple model, and when I started it again, I figured out that there are numerous weird things happening:
All the display modes are missing;
If I import any display mode, it can’t be saved in Rhino and disappears again;
There is no anti-aliasing, no matter which setting I choose;
I can’t use Save;
The Grid command no longer works;
The window selection is a solid rectangle.
I did the following and still can’t fix my Rhino 7:
I ran Rhino under Safe mode. Still had those bugs;
I used “Repair Rhino”. Didn’t help;
Then I uninstalled Rhino 7, deleted its folder, restarted my PC and installed Rhino 7 again. For some reason it opened with exactly the same custom toolbars that I had before, rather than using a default layout and settings (I didn’t import anything);
I downloaded the latest Nvidia drivers. Still same bugs;
I used 3 system restore points from previous days. No change at all;
I reinstalled Rhino 7 again. All the issues listed above are present…
Is there any known fix for these issues? I can’t use my Rhino 7 for work now.
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 16Gb)
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1660 Ti (NVidia) Memory: 6GB, Driver date: 5-14-2025 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 576.52
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port 0
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: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 5-14-2025
Driver Version: 32.0.15.7652
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB
Rhino plugins that do not ship with Rhino
C:\Users\Bobi\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
Go to your settings directory in file explorer (C:\Users\Bobi\AppData\Roaming\McNeel\Rhinoceros\7.0)
Rename the settings directory to settings_backup
Start Rhino
This should put you back in a state with all default settings. Does this fix the display issues? If so, please zip up and send us this settings_backup directory. I would like to see if the problem is repeatable.
Thank you for the quick response! The issue is fixed after doing exactly what you described above. Looks like some of the files in that folder was corrupted. Do you still want me to send you those files? Via e-mail maybe?
P.S. I noticed that the settings of my 3d mouse (Space Pilot) can’t be remembered by Rhino, despite that I set them properly. Everything else in Rhino works like before.
No matter which key of the SpacePilot I press, it activates the following command in Rhino 7:
The other issue now is that upon starting Rhino 7 or opening the Layers panel a pop-up window of the Gadwin printscreen program appears. Previously that bug happened only to my Rhino 8 Evaluation, which I mentioned multiple times in other topics. Looks like there is some conflict between Rhino and Gadwin printscreen. Example:
Edit: I fixed the issue with my 3d mouse. For some reason when I tried to activate any of my custom display modes via a custom macro, Rhino gave a priority to the “SetDimensionLayer” command above any other command. Once I manually typed “SetDisplayMode” in the Command line and hit Enter, now it always has a priority over “SetDimensionLayer”. Funny thing.
No. Rhino 8 was the only program that had a conflict with Gadwin printscreen. Now my Rhino 7 also brings the same pop-up menu of Gadwin. I’m still trying to figure out what causes the bug that was non-existent until earlier today… If I ever find a fix, I will report it here.
Not sure if there is a connection with a similar bug of Rhino 7 itself. I have the OSnap toolbar as a separated (floating) toolbar which I keep closed. After running some custom macros assigned to my mouse’s programmable buttons, it sometimes evokes the OSnap toolbar. It’s totally random and happens once in a while. These macros are for turning Project on or off, or snapping to circles and arcs only. 90% of the time they work properly, but in 10% of the cases they bring the OSnap toolbar as a floating toolbar.
I realized that there two new issues after the yesterday’s (almost successful) fix of my Rhino 7.
No matter what settings I apply for the Gumball’s radius and other sizes, it always appears way too small. It was fine yesterday. I use Windows scaling to 200% on my Windows 10, but this not the issue, because even if I set a radius of 200 or 300, Rhino 7’s Gumball is still much smaller than what it should be…
Here is a comparison between the same settings in Rhino 7 and Rhino 8 Evaluation:
Grid snap is now at every 1,5 mm instead of 1 mm, despite that “Spacing” is set to 1. Super weird…
Edit: Re-installing Rhino fixed the bug with the wrong spacing of the Grid. However, the Gumball appears twice as small than before, but the good news is that at least now I can set it to radius 160 and it’s as big as before (even though it was that size with a radius of 80 in Rhino 7 before, just like in Rhino 8). No idea why Rhino 7 now requires a radius of 160 pixels to make the Gumball 80 pixels large.
Rhino 7 urgently needs a new Service release to fix that BUG! It has happened multiple times in the past. Every time I fix the bug by going to an earlier Windows restore point before. However, doing so today didn’t fix the bug.
I was working in Rhino 7 minutes ago, then saved a couple of display modes, which made the program blink for a split second and I realized that something wrong has happened with the display. It’s super unresponsive now, showing everything only in Wireframe, there is no anti-aliasing, the isocurves are super thick, everything is rough and probably my graphics card is not used at all. The Gumball also has its element scaled to the wrong size, despite that its settings are unchanged.
The two display modes which I created initially had names “Rendered 4” and “Rendered 5”. Then, I decided to swap their name, i.e. “Rendered 5” became “Rendered 4”, and “Rendered 5” became “Rendered 4”. During the renaming, I had another display mode active to avoid issues. However, even that didn’t help. My speculation is that Rhino 7 messes up the code of the program (or some saved settings) when two display modes have the same name TEMPORARILY (just for a few seconds needed to swap the numbers of both display modes) while the Rhino options panel is opened.
Following the solution marked in this topic didn’t help either…
In my opinion, Rhino 7 must be updated to show a warning message in case that there is a conflict with the names of display modes to prevent loss of user data and settings.
Hi Bobi -
First up, there won’t be any updates to Rhino 7.
I’m trying to reproduce this in Rhino 9 without luck. It just doesn’t allow me to do so. And I’m not experiencing any issues after that failed attempt.
Could you explicitly post all steps that you take when you swap the names of display mode?
-wim
I swapped the names of both display modes the following way:
I switch to a different display mode, such like “Shaded”.
Then, I open the “Rendered 5” mode and rename it to “Rendered 4-” (without closing the Rhino options window after each operation).
Then, I open the “Rendered 4” and rename it to “Rendered 5” (again, the Rhino options is still opened).
Finally, I go back to “Rendered 4-” (formerly “Rendered 5”) and rename it to “Rendered 4” (most likely the fact that the Rhino options window is still opened causes the bug).
Once I closed the Rhino options window and tried to switch to “Rendered 4” and “Rendered 5” (both now have their number swapped), Rhino switched to wireframe, the anti-alising was lost, the framerate got super slow. Plus, the Gumball has wrong scaling of its handles now. Saving is disabled, too. The list of recent files is gone.
Rhino should do this automatically and place the backup in a user-defined folder. One time each week would be nice, complete with a date of creation. That way, the user will be able to restore a damaged Rhino to an earlier, working state.
