V6 Goal: Display Performance


(Willem Derks) #182

Are there maybe blocks involved in the slowdown?
Just saying because I remember there being issues in the past that turned out to be block related. ?


(Steve Baer) #183

I made a bunch of changes relating to blocks and have tested with the same bicycle model that Micha is posting pictures of. I’ll have to rerun tests to see results, but I don’t ever recall them being worse in the WIP than V5 on my test computers.

(Kelvin Cheng) #184


  • GTX 770, 970 and Quadro K620 have the exact same display quality in Rhino WIP.
  • GTX 770, 970 and Quadro K620 have the exact same display quality in Rhino 5 too.
  • GTX 770, 970 and Quadro K620’s curve display in Rhino 5 is thinner than in Rhino WIP.
  • HD 530 in Rhino WIP and Rhino 5 have almost the same display as the nvidia cards in Rhino WIP. The difference is small enough and can be ignored.

The screenshots.
DisplayQuality.zip (3.0 MB)

Note, all my tests have been done at DPI scaling level 100%. Curve thickness in Rhino WIP will respect DPI scaling levels. For example, a curve with one pixel width will display with 2 pixels when DPI scaling level is set to 200%. This is because viewport display in Rhino WIP is designed to be DPI aware. This is a different topic. Please open a new topic if anyone wants to discuss this. I had a report on Youtrack about this.

RH-32454 Curve thickness in high DPI


One thing I don’t understand - the bike model as NURBS is slow (iso curves disabled, R5), but if I convert it to meshes and hide the NURBS, than I get approx. 95% of the look like before, but the speed is several times faster. Here I see a great potential, a lot of speed without to lost the look I need to manipulate the scene. I wished we could focus the discussion on this great potential. Several hundred percent of speed increase are possible at Rhino5 only by using meshes instead NURBS for display use. If internal automatic the NURBS-MESH-switch could be done during a scene manipulation, than anything would be good here.

(Brian Gillespie) #186

The speed benefit you see there is because all mesh edges are lines. Lines are straight and require no refinement or computation to display. NURBS curves on the other hand are smooth. Like I said in a previous post, speeding up the drawing of lines is something we have an understanding how to do, and plan to do, but it may be too difficult to get into V6.


Please see if you can add a speed mode with predefined “meshing” of lines based on degrees and deviation ala the mesh settings. That´s what SolidWorks does and it works fine for them. I could live with having true curves on selected objects only, or on objects close to the camera only, a fixed lod for curves.
I think this would need to be a toggle in the display pipeline and then it can evolve from there, as what we need now is speed, speed and more speed in some situations. Accuracy is golden, but only if your’e not desperately in need of speed.

(Brian Gillespie) #188

Message received. Please know that this part of Rhino just plain isn’t simple or easy to modify. It’s on the list to improve; it may not make it into Rhino 6.


We know, I just feel it’s important to stress our need for it, and it’s a big deal that it isn’t making it into V6. If that’s the case then I would strongly recommend you to put that into an SR release. Massive files are not going away, on the contrary, they are becoming more and more complex and detailed, at least when working with nested massive block files from architects, and with engineering files.

Rhino already “downsamples” the curves when manipulating the views, so maybe adding a setting for this might help.
And to me it seems like it updates the “downsamples” for every frame, I think it could be done on mouse release instead. I could live with an octagone for a circle when zooming in really close until I release the mouse button. (when dropping below a certain fps, no need to downsample if the fps is >120.


+1, especially with those architectural files…


Brian, not for v6? I’m very disappointed. Since years we users are crying about slow speed, bad graphic card power usage and now it looks like you heard the first time, that we need speed? What did we wrong that you don’t heard the calls over the last years?

More display speed would be my main reason to upgrade Rhino.


Well, I have to say that I am also very disappointed to hear this… as Holo said there is clearly a trend towards more detailed models and 3rd party 3d objects.
Every day I fight to find ways to organize complex scenes so that they become useable in rhino, especially at the end of a project…

In another thread I tried to approach a part of the display performance problem from another direction with a few interesting outcomes:


Off course there are hundreds of tricks and workarounds (proxies, display modes tuning, meshing, layer management and so on…) but each of them makes our work a bit more complicated… you have to hide this layer before you can do this, start this macro before that…
At the end of the day display performance is very critical for a big number of projects.

At this point I would like to note that since Holo was so generous to develop the holomark tool we have at least a reference for display performance.
The bad thing however is, that holomark shows us that rhino is not very good at using the computing power of professional open gl cards at the mode the majority of users seem to use (shaded or rendered combined with lines)

I would love to hear that there is at least a strategy to address this issue in any way in a foreseeable timeframe.

by the way: I love Rhino and don’t want to work in another CAD program, 5 minutes ACAD and I am feeling sick :wink: , but I think it is important to discuss these issues openly.

my 2 cents



Actually it sounds like you do want to work in another CAD program: Rhino with all the painmakers removed.

I don’t think you’re the only one.


I’m at the point if a developer would write an alternative display pipeline I would pay for. Doe’s somebody know one?


Should we crowd fund it?

Someone from Mcneel set up the target on thier favourite crowd funding website?


LOL - great idea, count me in with the first 200 € - early bird special!

(Steve Baer) #197

Wow, this really makes me feel good about my job…

Large performance improvements (up to 10x depending on the model) can already be seen for:

  • shaded meshes
  • point clouds
  • text dots

I do have ideas on how to improve the curve drawing performance; there are just other issues that currently have a higher priority and absolutely need to be done first.


we are just joking :wink:

Large performance improvements (up to 10x depending on the model) can already be seen for:

shaded meshes
point clouds
text dots
I do have ideas on how to improve the curve drawing performance; there are just other issues that currently have a higher priority and absolutely need to be done first.

It is great that we have performance gains, but meshes / point clouds or text dots are not the culprits for display slowdowns. in contrast shaded mesh display is one of the few things that directly seems to profit from higher rated graphic cards…

The critical display mode is for probably 95% of the users the shaded /rendered mode with lines.
So speeding up polysurface line display in shaded views together with a better way of handling a lot of objects and blocks in large scenes should be one of the high priorities IMHO (and I am pretty sure I am not the only one…).



(Wim Dekeyser) #199

But then I guess you need to provide a number for that speed improvement also.
My working display mode has surface edges and as my results show, there already is a significant improvement in the WIP for the situation that you mention.


well I am not sure if we need another test model, as that would just complicate our discussion even more IMHO…
I think Michas bike model pretty good reflects what is needed.



Sorry Steve, I honestly didn’t mean to offend: just a tech nerd & forum lurker.