OBS can use that as well. Nvidia experience inserts overlay crap, OBS does not.
Rhino 7 works flawlessly since years, so it’s worrying that Rhino 9 fails in the same conditions and is dependent on industry standard programs such like Nvidia Experience.
I also no longer start my screenshot program (Gadwin Printscreen) with Windows 10, in order to minimize the risk of bugs. Both Rhino 8 and Rhino 9 cause an old bug that triggers the opening of the radial pop-up menu of Gadwin Printscreen. Rhino 7 never does that! I warned the Rhino developers about that bug since the Rhino WIP times a few years ago, but there is still no solution about found. Rhino 8 has so many bugs initially that I understand why the developers were too busy at the time to look at this particular bug. However, it’s obvious that something in the code of Rhino 8 has changed to worse compared to Rhino 7, because the same bug was also translated to Rhino 9 WIP and Beta.
Also, note that the custom display modes of Rhino 9 need 1-2 seconds to load their respective environment map, whereas the loading is instant in Rhino 7. Sometimes the environment map of the custom display modes will not load unless I move/pan/rotate the videwport by the mouse or my 3d mouse. Looks like program will not redraw the viewport after switching to a different display mode, so I’m forced to do that manually. I showed that behaviour in multiple videos in other threads with bug reports. Other users also had the same issue, so its not an isolated case.
I started to use the stock Rhino 9 Beta in the last days, made a clean install with manually deleted folders. I even stopped to use my 3d mouse and Gadwin Printsreen, stopped Nvidia Experience and any other program, but the bugs mentioned above still persist.
None of these problems sound like they have anything to do with the display pipeline or display modes… and everything to do with some of the internal changes that have been made elsewhere in the UI and file management.
The “delayed loading” is something that I think @andy needs to address and look at, because texture file loading has been turned into a background process that sounds like it’s failing to update the views when it’s done in some cases…it also will cause a slight delay if/when there are lots of textures or very large files.
The other issue(s) sound more like mouse and keyboard handling rather than graphics hardware or display pipeline.
Sorry if this has already been asked and provided, but can you post a video of this “pop up” issue, and explain what you do to get it to happen?
Thanks,
-Jeff
Sure, I will send you a short video with the Rhino 9 Beta startup in a few minutes. Check your PM soon.
Note that the pop-up radial menu of Gadwin Prinsscreen is also triggered by various actions in Rhino after the startup, such like opening some toolbars, clicking on some icons, during certain commands etc. This applies to both, Rhino 8 and Rhino 9 WIP/Beta.
I also use f.lux to reduce the eyestrain. However, when it’s turned off, all the bugs in Rhino 9 Beta remain there, meaning that they are caused by something wrong with the code of Rhino 8/9. As mentioned before, Rhino 7 is extremely stable and does not exhibit any of the bugs even with a heavy customization, plug-ins and many other programs running simultaneously.
By the way, the latest Rhino 9 Beta needed 58 minutes to install! The version prior that (released several days ago) needed 29 minutes for the installation, if I remember correctly. I already wrote that in some topic these days. Half or one hour is a huge amount of time to just install a program. Last month, the installation process of Rhino 9 WIP was way faster than that.
Here is another example where Rhino 9 Beta evoked the pop-up radial menu of Gadween Printscreen.
I just installed the latest Rhino 9 Beta and there is still a bug with the shadows of the “Concept” display mode that happens in a special case.
When I drag a simple box vertically with the Gumball and then cancel the command via the RMB (while still holding the LMB), a secondary shadow appears on the raised level where the bottom of the box was located for a brief moment before the cancellation of the dragging.
As soon as I drag the box sideways or build a new object in the scene, that weird shadow disappears. However, if I raise the box again and cancel the moving, the shadow appears again.
That’s insane… It takes under 30 seconds here… I have no idea what’s going on with your machine.
Perhaps @brian might have some ideas.
This is the first I’ve heard of this one, so if you reported it earlier, I guess I missed it… I am seeing the issue here though, so I should be able to get this fixed this week.
Thanks,
-J
It looks like this is a bug with the “Automatic” ground plane height adjustment mechanism, and nothing to do with the display modes or shadows.
When you drag the box up (or down), the automatic ground plane adjustment kicks in and adjusts the ground plane’s height accordingly… But then RMBing out of the drag, cancels the drag, but something is getting lost along the way and the automatic adjustment never gets “undone”… which then causes the ground plane to draw in the wrong place… causing shadows to appear where Rhino is being told the ground plane exists.
This doesn’t happen when dragging laterally since none of those operations affect the ground plane’s height.
I’ll see what I can do about this one, but it’s more likely something that @andy needs to look at.
Thanks,
-J
Well, not really for me, but I waited about five minutes longer than usual.
Last night, the latest Rhino 9 Beta took 24 minutes to install. The progress bar for the installation got stuck around the middle most of the time.
One month ago, Rhino 9 WIP took just a few minutes to install.
There are install logs in your %temp% folder. Please find the newest 5 named rhino*.log and send them to me. The timestamps in the logs will help me figure out what is taking so long on your computer, and, with luck, fix it.
The search results of my Windows 10 fail to find rhino*.log in my drive C. Should I look manually for this in a specific directory?
The “Concept” display mode failed to render the geometry in this example soon after I installed the “Tiger fillet plus” plug-in. I made a couple of fillets with the plug-in, then I used Undo to revert the object back to its basic box state. This is when the rendering failed and switched to “Wireframe”.
After I closed Rhino 9 BETA and opened the file again, the “Concept” display mode worked again. Weird… I’m using the latest BETA and latest Nvidia drivers.
The new BETA published a couple of hours ago took 25 minutes to install.