Yeah, I know, it was me who started that testing and provided him with the bike 
Oops!
nah, he took it to new heights and deserves the credit
Right, the original model was from Holo from somewhere of the internet.I deleted the bad surfaces only, because in the old discussion the argument was, the bad objects cause the slow down.
I afraid I was more a pain in the neck with the bike model posts, so people think it’s my bike.
Steve, great, I hope you find the reason for the speed difference between NURBS and mesh only display mode.
Here is the old link:
www.simulacrum.de/download/Testmaxspeed001.rar
It seems V6 is limiting it’s max redraw to the monitor fps setting, is that right?
In V5 I can get 1063 fps on a simple object test in wireframe, while in V6 I can only get 61 fps. But I also get 61 fps if I make 400 copies of that simple object.
Seems like a smart move if that’s the case.
Hi Steve,
Just a quick question I added here, but since I noticed this post about the display, it could be better to ask here:
- In V5 with a CustomMeshObject/CustomBrepObject the OnDraw inherited method wasn’t called on Rendered mode if the object wasn’t selected. This seems to be fixed in V6 but I noticed if you remove the call to base.OnDraw, the Render Mesh is still drawing on the viewport. I attached a project in the url above with an example project.
Thanks!
Just dropping a quick note to say that the new viewport feels like butter. Very nice- going to try to load heavy files to see if there is a difference between 5 and 6.
A little good news and big bad news.
Better, but not really good - v6 shows my complex NURBS models a little bit faster than at v5 (approx. 20% faster).
Bad news - extracted the render mesh and hide the NURBS (bike model test) - at v5 it needs 5s for testmaxspeed and at v6 12s. Since my complex models are quite slow (around 1fps) I try to use mesh versions of the objects at the scene (for rendering) often. V6 shouldn’t be slower than v5 in this case too. I hope the old mesh speed or better will come back.
Good luck,
Micha
Are you sure WIP is using the nVidia card and not the built in Intel card?
You can force what card to use in the Quadro drivers.
Here are my scores on my workstation with a Geforce 1070, both with 100 and 1000 speres:
V5, 100 spheres: 2.88 sec
V6, 100 spheres: 1.98 sec
V5, 1000 spheres: 27.33 sec
V6, 1000 spheres: 21.88 sec
Hi Holo,
I thought I am sure, when I saw my nVidia card as the main hardware for OpenGL in “Video Hardware and Driver Information”.
I also have set Nvidia as default graphic procesor for Rhino 6 WIP. So…I don’t know if its correct to force it via Quadro drivers…?
@jeff, @DavidEranen, and I have been rewriting the OpenGL display over the last few months to allow Rhino to perform all of it’s drawing at different specific ‘versions’ of OpenGL. I’ll write up a post about this once we have this code in your hands that you can use (hopefully in a few weeks). Sorry for being so quiet about this lately; there hasn’t been much to discuss while this code is still not running on your Rhino.
1 Like
Detail from a draft analysis (latest build):
Rhino 6 SR0 2016-10-11 (Public Build, 6.0.16285.11581, Git hash:6.0.16285.11581 in branch n/a)
Windows 10.0 SR0.0 or greater (Physical RAM: 7.9Gb)
GeForce GT 650M/PCIe/SSE2 (OpenGL ver:4.5.0 NVIDIA 373.06)
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Anti-alias mode: 8x
Mip Map Filtering: None
Anisotropic Filtering Mode: None
Vendor Name: NVIDIA Corporation
Render version: 4.5
Shading Language: 4.50 NVIDIA
Driver Date: 10-1-2016
Driver Version: 21.21.13.7306
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\SolidTools.rhp “SolidTools” n/a
C:\Program Files\Rhino WIP\Plug-ins\Commands.rhp “Commands” n/a
C:\Program Files\Rhino WIP\Plug-ins\WebBrowser.rhp “WebBrowser” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk.rhp “Renderer Development Kit” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoScript.rhp “RhinoScript” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoBonusTools.rhp “Rhino Bonus Tools” n/a
C:\Program Files\Rhino WIP\Plug-ins\IdleProcessor.rhp “IdleProcessor” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoRender.rhp “Rhino Render” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 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\Alerter.rhp “Alerter” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” 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
It does look pretty groovy though 
I just fixed that today. We should be releasing a build with this fix tomorrow.
Hi Steve, is it possible to bring back the speed of displayed meshes?
The plan has always been to improve the display speed for all objects. Sorry if I wasn’t clear enough about that.
Fine, the current release let me doubt it could be not so. I don’t expected a step back.
Good luck.
Micha
The display code is basically like rebuilding a house while you still live inside of it. In the long run it is going to be much better, but you might have to sleep in the garage for a little while. Steps back in display performance are to be expected during this phase which is why I haven’t asked people to do much performance testing lately.
2 Likes
