Rhino 9 WIP destroys some of my custom display modes

I installed the latest Rhino 9 WIP, but I quickly noticed that it destroys some of my custom display modes. Many of them look quite different than how they appear in Rhino 7. Even the most basic display mode that I use, Bobi 1, which is supposed to use scene lightning and rendering material, is completely different and impossible bright in Rhino 9 WIP, whereas it has a strong shading in Rhino 7. All settings are identical between the programs, the display modes are a direct import from ini files originally exported from Rhino 7.

There are no lights in the default startup scene in either program, “Sun” is off, “Ground plane” is off, too.



Here is the interesting part. My display mode in Rhino 7 uses “Scene lighting”, whereas the same setting in Rhino 9 WIP causes the bug showed in the pictures above. However, if I go to the settings of my display model in Rhino 9 WIP and change the lighting to “Default lighting”, the shading looks almost identical with the one in Rhino 7 which uses “Scene lighting”. Both, “Scene lighting” and “Default lighting” in Rhino 7 seem identical, but they differ a lot in Rhino 9 WIP.

Also, the vertical slider in Rhino 9 WIP’s options is way too thin, thus the navigation is way less convenient compared to Rhino 7 that features a nice thick slider.


Other display modes are less affected (in a negative way), but they still exhibit some differences in the shading, highlights and transparency.

Much brighter highlights and lesser transparency in Rhino 7:


Toned down highlights and contrast, and greater transparency in Rhino 9 WIP:


More pronounced highlights in Rhino 7:


Toned down highlights and contrast in Rhino 9 WIP:


Gentle shadows in Rhino 7:


Noticeably stronger shadows and raised contrast in Rhino 9 WIP:


EDIT: I figured out that changing “GPU Technology” in Rhino 9 WIP from “DirectX” to “OpenGL” fixes most of the issues with the custom display modes. However, there are still very minor differences, but the problem is that display modes like “Bobi 1” and others that rely on “Scene lighting” look completely different in Rhino 9 WIP when I switch to “DirectX”. They literally glow and no longer can take advantage of the strong shading that the “OpenGL” setting provides.


Is there a way to reset all settings from Rhino 9 WIP and re-install a fresh new copy without any residue settings and customization that I imported from Rhino 7? I wan to try to set there manually directly in Rhino 9 WIP, because many of the imported settings are not working properly anyway.

I already modified and repaired Rhino 9 WIP, but it still uses my imported settings from Rhino 7, so it looks like it reads them from some system folder.

Also, Rhino 9 WIP crashes every time when I open the pop-up menu and hover over the icons with the mouse pointers. A few seconds later the pgoram crashes. Every single time.

Personally I would be quite surprised if all custom display modes originating in Rhino 7 transfer perfectly to V9, as so many things have changed since then display-wise…

Maybe someone can write a translator…

I edited my post above and added that switching to “OpenGL” fixes most of the issues with the display modes. “DirectX” has a huge disadvantage over “OpenGL” when it comes to the “Scene lighting” setting.

Yep, but DirectX is the future, as far as I can tell OpenGL is dead in the water.

We are still in the process of implementing all of the features in our Direct3D engine to come to parity with OpenGL. @jeff do you know about this case that Bobi is writing about?

Lighting, shadows and intensities are currently being typed on atm… Shadows don’t work at all yet in D3D… and high contrasts between engines is just something we’ll need to tweak…

That being said, we’ll never get 100% pixel-perfect results when comparing across different engines…we can get close, but it’ll never be exact.

-J

Yesterday I sent a few crash reports. It does not matter which pop-up menu is used. Rhino 9 WIP always crashes after mouse hovering on it. This is why I asked if there is s way to reset the program to a clean install rather than using my old settings from Rhino 7. There is a chance that the latter may interfere with Rhino 9 WIP and cause the crashes.

Fair enough, I can tweak the display modes to emulate the desired look. As long as the shadows are fixed, the other settings such like contrast and highlight intensify are easy to adjust.

I run into a bunch of bugs while testing various tools and the new UI:

  1. Mouse tooltips do not show at all or blink repeatedly upon hovering with the mouse pointer on toolbars docked at the bottom of the screen;

  2. The right-side auto-hide Properties panel does not work at all. Not sure how to enable the clickable icons that must be there;

  3. The lest side auto-hide “Main 1 and Main 2” panel stuck and refuses to hide, thus leaving a permanent blank vertical column;

  4. Opening the Rhino options takes ages. Every menu inside triggers a huge lag of several seconds. Sometimes Rhino 9 WIP crashes while trying to open the list with display modes.

I still can’t find a way to reset Rhino 9 WIP to get rid of my old Rhino 7 settings that remain there even after multiple clean installs of the WIP. I would like to test the stock program to see if some of the bugs will be resolved that way.

Here is a short video that shows all 4 bugs listed above:

Reinstalling does nothing to clear your settings - it’s designed that way. That way if you need to reinstall for some other reason, your previous settings are still there.

Run Reset and follow the instructions.

Thanks! It worked to some extent. Except that my custom display mode were still inside after restarting my Windows 10. It’s even more weird now that I can’t switch to any of my custom display modes set to macros on my 3d mouse’s buttons, even though they exist in Rhino 9 WIP… I also tried to import them again in the reset Rhino 9 WIP and they still can’t be activated. Check the Command line here:

I guess that some options from Rhino 7 are still inside the WIP and can’t be fully removed. Maybe they are stored in some system folder that’s read by Rhino 9 WIP upon starting?

EDIT: After manually typing “SetDisplayMode” and writing “Bobix9” inside the “String” field, the macros of my 3d mouse now successfully switch the display modes. However, when I start Rhino 9 WIP again, I face the same problem with inability to activate display modes via my 3d mouse. The only way to make it happen is to run the “SetDisplayMode” and type any of the display modes. Only then the buttons of my 3d mouse are able to switch the display modes as expected.

EDIT 2: After starting Rhino 9 WIP for several more times it’s finally able to switch the display modes through the buttons of my 3d mouse.


I also suggest two more things regarding the display modes:

  1. Enable a global setting for the “Scale” of the object wire thickness. By default, it’s set to 2, but since I use 200% scaling in Windows 20, those look very thick in Rhino 9 WIP and I’m forced to manually change the “Scale” from the settings of each display mode individually, which is very time consuming process.

  2. Fix the bug that will not let a natural number order in the list of display modes. For example, my “Bobi 15” and “Bobi 16” display modes are positioned BEFORE “Bobi 2”, which is counterintuitive.


EDIT 3:

I also have another suggestion:

  1. Make it possible to change the display modes from the customizable buttons of the 3d mouse while the ! _Shade command is active. Currently, this is only possible from the customizable buttons of the regular mouse.

My guilt is that I reported two bugs found in the latest BETA in the same thread. I already explained that I could not find my original topic (quoted by @David53 above), most likely due to the difference between “DirectX” and “Direct3D”. I agree with you that it would be better to use two separate topics. And I thank @CallumSykes for being kind enough to split the topics on time.

I find that particular graphics bug more than just “random bug” or “rant”. It’s an essential part of the user experience, literally stopping me (and others) from using either Direct3D or all the affected display modes due to the missing shadows (or bumped self-glowing).

I apologize for taking my very limited time recently to write bug reports. Being in my most difficult moment in my life now does not excuse me. I will try to be more focused in the future.


This bug was also reported yesterday in the other topic that was just closed now while I was typing my reply, this is why I answer here.

don’t get me wrong, I love your work and dedication, the help you provide on this forum, and the numerous bug reports. We want to give the best possible support on this forum, and to do that, we need to keep things tidy. Our time is just as well limited. I prefer spending that on actual help than on forum moderation. Thanks for your understanding

To keep things clear, please check your PM in a few minutes.

Someone regreting that you have wip access now? :joy:

Well mcneel you gave us bugs we gave you a Bobi! There is war in this savanna! LOL

After I used “Zebra” on the latest BETA (9.0.26225.6303, 2026-08-13), some of my display modes no longer have visible isocurves, despite that they are set to display the isocurves. For example, “Bobi X9” and “Shaded 5 Ultra”.

Both display modes were set to render the isocurves with a “Scale” of 1 (the default was 2, but I changed it a few days ago). However, since the isocurved disappeared, the thickness of the isocurves for the “Zebra” analysis became 2 pixels wide again, despite that the scale is set to “1”.


Other display modes, such like “Bobi 1”, completely lack shadows and are rendered with an unwanted bright white glow under Direct3D (work properly under OpenGL). I noticed that the shadows are turned off under Direct3D, but when I enable them from the “Display” tab, then the isocurves disappear automatically. Weird…

Switching from OpenGL to Direct3D disables the shadows:

Under Direct3D, turning the shadows on manually disables the isocurves:


Other display modes, such like “Crackdown 17X”, seem to have both, the shadows and the isocurves working properly, but then the rendering of the “Zebra” gets disabled and is replaced by a white glowing material.


Another bug that I found is that when I enable “Flat shading” the planes consisting textures disappear from the viewport entirely AND the zebra stripes become super coarse, as if they are rendered at lower resolution and wothout anti-aliasing. Also, the framerate becomes very sluggish when I have “Flat shading” on. Looks like this option somehow disables the graphics acceleration, at least on my PC with Windows 10 Pro and Nvidia GTX 1660 Ti. With “Flat shading” off the performance feels multiple times faster. Super weird.

“Flat shading” off. The performance is great. The anti-aliasing is great. The planes with textures are visible:

“Flat shading” on. The performance is like 5 times worse. The anti-aliasing of the zebra stripes is bad, the resolution is much worse. The planes with textures disappear entirely (even their wireframe is not visible anymore):


I’m no longer able to turn on the surface isocurves even after restarting the latest BETA and importing my backup display modes… They are gone after using the “Zebra” analysis. The only way ti enable the isocurves is to turn off the shadows, but then the objects become completely white and flat. The shading was fine for hours before using the “Zebra”.