V6 Goal: Display Performance



Just my kind of topic! :smiley:
On a typical ID project I see 2x speed up, on large architectural projects with many curves I also see great improvements and I look forward to test it out on nested blocks when the optimization is ready!
Anything in particular you want me to test out?

Edit: And 244.000 lines is easily handled now.

(Steve Baer) #102

I don’t have anything in particular for you to test. I just need to know if things don’t “look” correct or if display actually appears slower than V5.

We did discover a few items so far that I broke in this WIP with respect to display that will be fixed in the next WIP:

  • Shaded SubDs
  • Flat Shaded
  • Changing the document mesh settings

The above items will display correctly if you run TestVboCache and disable caching.

I working on wiring this optimization into ghosted mode today and should have this done in time for the next WIP.


Excellent work so far!
Changing AA settings also renders objects as wireframe.

I also have an issue when I import V5 files into an empty V6 document, where all materials are not shown in the material library, and then if I drag a material onto an object that has one of these unlisted materials I sometimes crash Rhino.

(Steve Baer) #104

Thanks, this is exactly what I’m trying to find. I’ll work on this issue this week

This sounds unrelated, but I could be confused. @andy have you heard of this crash with respect to dragging materials?


I too think it is unrelated to the graphicpipeline.

Hm… on two occations now V6 has crashed in the background when I switched to V5. That has never happened before.
EDIT: Scratch that, it was in the background, it just didn’t show up on the Rhino Icon on the Windows 10 toolbar… I’ll restart and see if that helps.


@stevebaer, thanks for that. I see quite some speedups compared to the previous WIP :slight_smile:

One thing i´ve noted is that when i enable AA, any shaded viewport switches to wireframe and cannot be set to Shaded or Rendered again, even when AA has been turned OFF. After reopening Rhino WIP, all is well. (Radeon HD7979 3GB)

I´ll test more. Btw. do VBOs also speed up the wireframe display ?


(Steve Baer) #107

Yes, Jorgen found that one first (see a couple posts up).
I’ll get that fixed before next week’s WIP. It is not a GPU specific bug and will probably happen on all graphics cards.

There’s a lot more than just the use of VBOs that are built into this optimization. This just happened to be the name of the test command that I made when I started working on the optimization. Things have gotten well beyond just the use of VBOs (which we actually already did in V5 and in previous WIPs). The optimization has more to do with smarter management of VBOs and batch drawing them when possible.

Wireframe display is probably not going to see a big boost in performance. I’m seeing if there are little things here or there that we can to do improve wireframe performance, but I don’t see anything obvious at the moment that would make dramatic changes.

I did have one optimization in place in the past where we took the last frame and slapping it onto the current frame with a slight offset during panning. This made a huge difference in panning speed, but there were a lot of corner cases where things broke. I will look back into this optimization after I’ve finished the current shaded mesh optimization.

(Steve Baer) #108

I just committed a fix for the AA bug so this should just work in the next WIP. Thanks guys for reporting


I have another one, if I make a SubD then it shades it ok, until I rotate the view, then the SubD becomes wireframe, until I click on the object or do something else. If I extract the rendermesh then that shows fine, but there are some edge errors, I have a naked edge color, and it shows both naked and joined edges at the same time.

Here are the different states:
Original mesh, SubD, Extracted Render mesh, exploded rendermesh:

And same view if I do a small manipulation:

Also note that the SubD “edge curves” are thinner than the rest, I don’t consider it a bug, I actually like it, maybe the meshes could benefit from that feature too. Unless it is something that slows the display down of course!


And here in rendered:

and after viewport manipulation:

(Wim Dekeyser) #111

Problems with Sub-D’s were on Steve’s list :wink: :


WOW! Just WOW!
I have made a test comparing the same, huge and complex model on my two machines.
NVIDIA GeForce GT 240M on RH WiP vs NVIDIA Quadro FX3700M on RH5.
Quadro is struggling while GeForce handles it easily. It used to be opposite.
The visual performance is so promising that it could be the only reason for me for switching to RH6.
Great work guys.

Rhino 6 WIP Fuzzy Geometry Display
(Steve Baer) #113

Correct, and they have already been fixed in the internal build. You guys will see this fix in next week’s WIP. For now the fix is to TestVboCache (enabled=false) when working with SubD objects.

I’ve been liking the thinner wires a bit more myself lately. On high DPI monitors (which I’m assuming is what you are using) we are scaling the thickness of wires up. It does look like we are slightly over doing the scaling though. I’ll tweak this for the next WIP.

Rhino 6 WIP Fuzzy Geometry Display

Sounds great, the monitor I use is a 27" 2560x1440, I tried a 4K monitor but the software I used didn’ support it well enough, so I downgraded :wink:

(Steve Baer) #115

What “Text Scale” are you running Windows at? This is what Windows uses to report DPI settings


Just tested some larger assemblies on WIP. Big improvement. I was already pretty happy with V5 but I’m a little blown away at how well the WIP handles them. Good job guys.


I’m running it at 100%


Here’s another one:
When I turn on controlpoints for a Nurbs Surface and manipulates it the render mesh isn’t updated in realtime like it does in V5.

It would be really nice if it would remesh in the background too, to refine the rendermesh while manipulating the nurbs surface. Not important, but it would be a nice feature.


And another:
Sometimes when I select something the parts of the display that is in shadow becomes the color of the viewport background. To illustrate it better it is here in orange:

Turning off VBO eliminates this.

(Steve Baer) #120

Thanks, I can repeat this and will try to get it fixed right away

@jeff I might need your help with this “becoming the viewport color” bug. I’m not sure what could be causing this. @Holo do you have a basic model that reproduces this?