V6 Goal: Display Performance


You may want to wait until the next build is released since there is a bug in the current build that @Holo found related to large numbers of dots on the screen. The next build will probably be available on Aug. 20

Hi @stevebaer I just tried the script on my i7 Quadro 4000 workstation and got these results:
V5: 15.79 sec
V6: 1.40 sec

I look forward to test the “bug free” version next week, as I crashed the WIP on this system too.

Steve, i can’t see a link to Rh6 WIP on that website. Am I blind? ( I opened it only on my iphone)


August 13
Goswin said:
Where can I get Rh6 ?


You may want to wait until the next build is released since there is a bug in the current build that @Holo found related to large numbers of dots on the screen. The next build will probably be available on Aug. 20

To respond, reply to this email or visit V6 Goal: Display Performance in your browser.

It’s there, try on your PC.
It probably uses Flash or some other thing Apple finds offensive :wink:

The next build will draw at the same speed for dots, it just hopefully won’t crash :smile: I wasn’t properly disposing of Window’s resources when generating the text for the dots.

I think that is about all I’m going to put into Text Dots for now. I’m going to try and get some point cloud improvements in for next week’s build and will write some notes up about that soon.

1 Like

Progress Report (Aug 15, 2014)

This week I spent my time cleaning up the new caching code that I’ve been working on and making it generic enough to handle different object types. One of the goals for my new caching system is to make this work for objects that are also NOT part of the Rhino document. In other words, display conduits can use these caches to draw. I think I can get to work automatically in RhinoCommon which will mean that the preview in Grasshopper will get a speed bonus without @DavidRutten having to change a single line of code. This hasn’t been implemented yet for RhinoCommon, but I plan on testing this when I start working on caches for geometry that Grasshopper draws (curves, breps, meshes…) C++ developers will have to adjust their code only slightly in that they will need to pass cache classes to their “draw” functions. I’m just jotting down thought on where I want to progress with the caching system, so no promises yet :smiling_imp:

After text dots, I focused on point clouds this week. Point clouds are dramatically different from text dots which let me make sure my caching architecture can handle all sorts of geometry.

In the next build (probably Aug 19, 2014), point cloud display performance has been improved in two ways:

  • Point cloud vertices, colors, and normals are loaded on to the graphics card memory as vertex buffer objects (VBOs). These VBOs are drawn instead of streaming this information to the card each frame. I’m guessing that the better GPU you have, the better performance you are going to get out of point cloud display.
  • For large point clouds (currently >400,000 vertices), we draw only %25 of the vertices during dynamic panning and rotating. All points are drawn when the display is still. We can get fancier at degrading if we need to in the future, but this is a simple enough start to see if it will work for users.

You can test the difference between V5/Serengeti drawing techniques with the “TestNewPointCloudDisplay” in the next build. I have the new Serengeti style drawing on by default. I’ll most likely rip this command out of Rhino after a week (and all of the legacy code that this command runs.) It is just there for now in case I broke something bad.


This sounds great Steve!

And I hope the ultimate goal is to speed up files like this nested block file from this post: Graphics performance with very large 3dm files

Hi Steve,

some problems with the new annotation dot display encountered:

  1. AA is disabled
  2. Draw some Annotation dots (they display fine)
  3. Enable AA, display is not correct:

happens with a AMD Radeon HD7970, most recent driver.

Btw. Is it possible to make the depth and order testing to act permanently, i mean that it happens before mouseup ?


Hi Steve,

one small wish regarding display performance: Please make the dynamic display an option which can be applied per object in the object properties.


Yep, @BrianJ already found this one at http://mcneel.myjetbrains.com/youtrack/issue/RH-5416. I need to rebuild all of the “on card” cache information when the low level OpenGL rendering context changes. This typically only happens in Rhino when you tweak the AA settings.

Not exactly sure what you are requesting here. You’ll need to clue me in a bit more.

I would really like to try and make dynamic display smarter and not add yet another checkbox to Rhino. What is it that you are hoping this option would do for you?

Hi Steve, a simple workaround for the Change AA level issue would be to require a restart (of Rhino). Not sophisticated, but at least it would be stable.

Well, sure that’s a workaround for now… This is just a bug that I need to fix. I just haven’t completed it yet because I’m in the middle of a massive rework of some other non-related code and I don’t want to switch gears quite yet.

i´ve been trying to explain that if i have two dots in different depth and rotate the view, sometimes the wrong one is displayed in front while rotating the view using RMB. Once i release the RMB, the correct dot is displayed in front.

enabling the box like preview permanently for a single object not the whole scene. It might have the same options as the global setting, boxed permanently or only during view changes.


Well this would be less useful for those users who just enable AA to make screengrabs. I would appreciaty if, for radeon cards, the aliasing could be improved further, it supports 12x and 24x Supersampling but Rhino only allows to set 2x,4x and 8x. None of these settings look really clean. If i set in Catalyst Control Center to override the application settings, Supersampling makes no difference.

There have been long discussion on the AA Quality in comparison with Quadro cards i know, but has there ever been a fix from the AMD side ?


So we’re specifically referring to bounding box style display. Is that correct? There are many other things we do during pan and rotate for objects (lower tesselation levels for curves, degraded point clouds for massive clouds…) We aren’t referring to these types of things, correct?

Yes and No. I have situations where i need to keep a large amount of objects (eg. 20000 placed Block instances) loaded so they can be accessed via scripting. It would be helpful to only pick a bunch of objects and set them to box like preview so other things (geometry which is built with scripts on top of the blocks) is not affected.


This will not be necessary in the newer engine. There will be one and only one context, regardless of AA settings. Everything will be Frame Buffer Object based and there will be no need for special casing context or pixel formats… But for now, Steve is using the older engine, and therefore when things like AA change, the underlying pixel formats need to change, and therefore so does the context… but as I said, this all goes away in the new scheme of things.


A bit off topic regarding the new engine:

Will it be based on OpenGl 4?
And if so does that mean that older cards won’t run Rhino 6 in hardware mode, or are only some features disabled?
I see that the Fermi based GeForce cards (400 series) were the first to support OpenGL 4.
While older cards like the 200 series only supports OpenGL 3.3.

I also found that these are the oldest Quadro’s to support OpenGL 4:
Quadro Plex 7000, Quadro 6000, Quadro 5000, Quadro 4000, Quadro 2000, Quadro 600

Yes the new engine will be based on OpenGL 4. That being said, we will need to keep the old engine around at least for “non hardware accelerated” display.

I am currently doing performance work in the older engine and will port these to the new engine that Jeff is working on once that becomes available. This means that there will be performance work being done on both engines.

If the card doesn’t support OpenGL 4, then we will have to choose to use the older engine when Rhino starts.

1 Like

That is fabulous news!
And I hope the time has come when OpenGL is not limited by what the Rhino Render (or any other render) can do.

Jeff made some great work on refraction, environment wraps and water plane + a car paint shader that really should have made it into V5 but didn’t. So please do your best to let the OpenGL be treated as a separate unlimited render pipeline.