V6 Goal: Display Performance


(Steve Baer) #81

It actually turns out not to be a whole lot of work to support different versions once the architecture is in place.

OpenGL 1.2 is the Microsoft software mode OpenGL (non-hardware accelerated). We’ve already written support for that years ago and it doesn’t make sense to drop this since it is very helpful when diagnosing misbehaved drivers.

OpenGL 2.1 is the driver level that VMWare operates at and which many users run (even though we don’t recommend it).

We aren’t sure what the top level OpenGL level we’ll need in V6, but we will need to support at least OpenGL 3.0 since that is when frame buffer objects became part of the core. We are pretty much targeting OpenGL 4.5 since that is the most recent version, but it is hard to say if we will need any specific features of 4.5.

I’m hoping this architecture will make it relatively easy to drop in support for a new version of OpenGL when we find a need for it without too much code rewrite. So far, things look good.



The main reason I asked is because I was imagining Rhino using some really powerful new OGL 4.5 features, and you folks having to write lots of work-around code for earlier OGL versions.

Of course I suppose you could just use some boilerplate code that puts up a message box that says something like “Nyah, Nyah you can’t use this feature because you’re too cheap to get a computer that supports OGL 4.5. HaHaHaHa!”

(Steve Baer) #83

There will definitely be things that just don’t work when running on lower version number drivers. This already happens on Rhino where you get antialiasing through multisampling when the driver supports is. Other features like shadows drop out when running on non-hardware accelerated OpenGL.


I see. Of course.

Does John Brock get many questions like “How come my coworker (friend, client, etc.) has neat shadows and swell looking curves?”


OK, good luck for coding. So I hope the freezed parts of the display will be gone in the future.

Best post a note if you are working on the display speed for models like the bike and you need more tests. Using more GPU power is very missed here.


Hi @steve, @jeff,

Not sure if this is the right place to put my post but…

Have noticed two small issues in the latest WIP (it can be that it has been touched before)

  1. Seems that points (exc. when drawing a curve) are not displayed correctly ->rectangle is not present around the point. When zooming in/out - works as normal. See enclosed.
  2. Height of the help textbox (whatever is the right name) is higher than needed -> mouse can be seen twice. Also enclosed.


(Marc Gibeault) #87

In fact, the tooltip boxes are too small, they don’t show the right-mouse click option.


Display is stuttering on PAN, ZOOM, ROTATE, even with empty model.
By contrast, Rhino V5 is, well… as usual.

Rhino 6 SR0 2015-9-29 (Release, 6.0.15272.11241, SVN:136803 in branch trunk)

Windows 10.0 SR0.0 or greater (Physical RAM: 16Gb)
Microsoft Windows [version 10.0.10240]

GeForce GT 650M/PCIe/SSE2 (OpenGL ver:4.5.0 NVIDIA 355.60)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Use single rendering context: On

Anti-alias mode: 4x
Mip Map Filtering: None
Anisotropic Filtering Mode: None

Vendor Name: NVIDIA Corporation
Render version: 4.5
Shading Language: 4.50 NVIDIA
Driver Date: 8-6-2015
Driver Version:
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 1 GB

C:\Program Files\Rhino WIP\Plug-ins\rdk.rhp “Renderer Development Kit” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoRender.rhp “Rhino Render” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI” n/a
C:\Program Files\Rhino WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” n/a
C:\Program Files\Rhino WIP\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino WIP\Plug-ins\Displacement.rhp “Displacement” n/a

(Steve Baer) #89

Thanks for letting me know. We just made a pretty large architectural change to our OpenGL code. Now we need to figure out what is going wrong and fix issues like this.


Hi Steve,

Thanks for your answer.
I got a moment of doubt when I switched to a maximized view : things began to be fluid again, but a few seconds later, the stuttering came back.

Hope it helps.


Hi @stevebaer,

I have noticed that in the latest WIP edge thickness is not stored.
It can be changed via Rhino Options -> View - > Edge Thickness(pixels) but after a while (first redraw) value comes back.

Can you check it please?

Updated: actually same behavior can be noticed for all settings - size of the control point and etc.


(Brian James) #92

Thanks, there’s an open issue right now about display settings not sticking… filed as http://mcneel.myjetbrains.com/youtrack/issue/RH-31394 for future reference.


Question: Are the views being refreshed more than once, when objects are grouped?


For V6, couldn’t each viewport be given its own thread for updating?
(I noticed that in V5, they update sequentially.)

(Steve Baer) #95

Nope; sorry things just don’t work that way in our core architecture. That would require a massive rewrite in many areas of Rhino.


Oh well.

How about meshing, could objects to be meshed as a result of an operation be put in list for muti-threading?
(I was trying to watch Rhino for things that affect the apparent speed.)

[ I heard it in good word that ID family games often had inline assembly in the C rendering code : )

They would even send out polygons to be filled grouped by their texture, but I should think that that would largely help when there are more textures(materials) involved than we see in CAD. ]

Wishes for Rhino WIP
(Steve Baer) #97

Objects only need to be meshed once and that meshing does occur on a separate thread so you can cancel the operation. This does not affect display performance.

(Steve Baer) #98

The latest WIP (March 1, 2016) contains optimizations for shaded object display.

Shaded and rendered display modes can see significant speed improvements. Improvements will vary based on the model that you are using, but some users should see dramatically improved performance.

The optimizations are turned on by default, but you can test timing differences for now by turning the feature off through the use of the “TestVboCache” test command. Running this command and changing the option of Caching to Disabled will set the display pipeline to run in a manner as it was running in previous WIPs. This command should eventually go away, but I’m using it for now to find any place where I may have broken the display and things don’t “look” correct.

Currently there are cases where this optimization is not enabled. Blocks, transparent/ghosted objects, objects with per-face materials, and custom render meshes like curve piping are cases that I know the optimization has not been applied to yet. I am working on handling these cases over the next few weeks and will let people know when they have been implemented.

Give it a ‘spin’:slight_smile: Hopefully you’ll see a marked improvement in performance. If you see any bugs or slower display than in the past, please let me know so I can get these fixed as soon as possible.


Great news and first tests looks very promising on my Quadro 4000.

(Steve Baer) #100

Was hoping you would pick up on this comment :slight_smile: It all depends on the model of course (and now your graphics card more than even), but I’ve seen speed improvements any where from a few percent better up to 500%