I see some change in the wireframe thickness of the NURBS surfaces after updating to the latest Rhino 9 BETA (9.0.26230.12303, 2026-08-18).
Previously, in Rhino 9 BETA (9.0.26225.6303, 2026-08-13), the wireframe was thinner and equal between Direct3D and Open GL.
However, the latest BETA renders the Direct3D wireframe with nearly double the thickness than before. The wireframe remains properly thin when I switch to OpenGL.
OpenGL (also, note the overburn gradient of the gray mid-tones; they used to be gradual before):
I also noticed a significant difference of the brightness. The OpenGL shadows used to be nice and gradual, now the shading on default white surfaces is overburn and crushes the gradient mid-tones.The Direct3D mode, on the other hand, is much, much darker that what it should be. My custom display modes are extremely dark in Direct3D now.
OpenGL (brighter shading with proper thin wireframe):
The noticeable difference in brightness and wireframe thickness affects my custom display modes, but I also see a huge difference in the default “Concept” mode. Seems like it exhibits a bug which I reported 1-2 months ago related to showing a shiny environment map that should not be there.
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 16GB)
.NET 10.0.2
Computer platform: DESKTOP
Standard graphics configuration using DirectX
Primary display: NVIDIA GeForce GTX 1660 Ti (NVidia) Memory: 6GB, Driver date: 7-2-2026 (M-D-Y). DirectX(11)
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0
I think what @Gijs is saying is that the Picture object in your scene is the cause of the faded look in D3D… That would be easy to test just by deleting the Picture object (all of them in there are more than 1) and see if things look the same as OpenGL.
The Direct3D has improper shading when I use custom display modes that natively use the rendering material, such like “Bobi 1”. The OpenGL shading is proper. Note that the shadows are turned off in my display mode. When I turn on the shadows, both OpenGL and Direct3D look identical, with overly-bright shading. This makes me believe that the Direct3D somehow ignores the fact that my “Bobi 1” display mode does not use shadows.
Another comparison between Direct3D and OpenGL in the latest Rhino 9 BETA when I switch to “Concept” display mode. All images in the file are deleted, and the issue with the shiny environment map is gone:
Shadows are off in your display mode… so we’re not talking about shadows here…it’s purely “shading” and “lighting”.
You should not just be “switching” or “flipping” back and forth between engines without restarting Rhino. This is not a “feature”. Completely shutting down and unloading a graphics engine once it has been loaded into Rhino’s process space is an impossibility…and there will be all kinds or residual side-effects. Please make sure that once you switch engines, you close Rhino and restart it.
Lastly,
Your Bobi display mode is using Scene Lighting… Which is a Render Setting…which means that the Skylight is now taken into account for any modes that use Scene Lighting. The OpenGL engine does not honor that setting, and thus, the results are vastly different.
You can try doing any one or more of these:
Turn off the Skylight in the Render settings.
Change your lighting scheme to something other than “Scene lighting”.
Turn Shadows ON in your display mode. This will then use SSAO shadowing for the Skylight so that you’re not getting 100% light saturation from the environment. And since your mode also uses the Render settings GroundPlane, it also means you’ll get ground plane shadows.
Anyone of those should make D3D and OpenGL almost pixel perfect… But since the OpenGL engine does not (yet) pay attention to the Skylight setting for Scene Lighting, it will never be a pixel perfect comparison for modes that just use Scene Lighting and nothing else.
In my post above I also mentioned that if I turn the shadows on on my display mode “Bobi 1”, then the OpenGL mode looks identical to the Direct3D one.
However, my goal is to get both, Direct3D and OpenGL look the same as in Rhino 7 where “Bobi 1” has the shadows turned off for the best possible performance, as well as a nice dark shading to examine the surface imperfections. With the shadows on I no longer can spot the surface imperfections easily.
While other display modes look more realistic and beautiful with shadows, the idea of the strong shading of “Bobi 1” is to be extra sensitive and to look ugly where the surfaces need to be fixed.
As for the need to restart Rhino after switching from Direct3D to OpenGL or vice versa, perhaps a text notification could be added in the same menu as an advice to the user.
By the way, the shading is nice again after following your advice to change from “Scene lighting” to “Default lighting”. No need to turn off the Skylight.
I opted to leave the shadows off, because they make a huge hit on the performance and also add a dynamic shadow that obscures some areas of the geometry.
Yup, that should definitely yield almost pixel-perfect differences…
And to make sure this is clear… The actual bug is in the OpenGL engine not D3D. If shadows are on, the OpenGL engine honors the skylight setting…turn shadows off, and all of sudden the skylight is somehow no longer a light… even though its very name “Sky Light” implies it. That was never a feature, it was/is a bug.
The scheme “Scene Lighting” means “Use all light sources found within the scene”… and “Skylight” is such a light source. It may not have a physical object presence in your model, but it absolutely is a “scene based” lighting setting, and therefore should not be ignored (or ignored just because shadows are off). You should be able to make modifications to the skylight settings and observe those changes in your viewport regardless of whether or not shadows are ON. That’s exactly how D3D works now… and eventually I will make sure OGL works the same as well.
Thank you for the verification! From what I understood, old Rhino versions had that graphics bug of OpenGL forever. I customized my display modes based on the OpenGL, but now that Direct3D is the preferred environment for Rhino 9, I started to see lots of differences in many of my old display modes.
Aside from all the technical terms, the ultimate goal of my “Bobi 1” display mode is to just work in Rhino 9’s Direct3D as it did in Rhino 7, offering the best possible performance and having dark shading as an easy way to spot imperfections in the geometry.
Fully understood… and we try to do our best to ensure consistent results, but in some cases (i.e. where bugs are fixed (finally)), that might not be doable.
That being said, it’s great that you’re pointing/finding these things out now (and as often as you’d like). We will try to take/make every step possible to get things looking as consistent as we can, so please continue to report anything you find… if it’s a bug we’ll/I’ll fix it… if it’s not a bug, we’ll do our best to explain why and what the possible solutions/workarounds are.
