Yes, I use a GTX780 here. The bike model is from 12s down to 2s, so it’s approx. 6 times faster now. And working with heavy models is like working with light models. It’s so great, since my model complexity is extremely grown over the last years. I’m happy.
For further improvements - I tested my worst model and it works better too. I see a working dynamic switch to wireframe mode. That’s fine, I missed it at Rhino 5. Only the time for switching between both modes is approx. 1.5s and could be faster. Maybe it can be optimized. Interesting is that my GTX780 is used at max 37%. (It’s a very heavy model. It’s not the typical complexity of my daily use.)
Yep, when this works it blows away the old display speed. I’m still seeing problems with AMD and am setting up a test computer with an AMD card to see if there is anything we can figure out that we are doing wrong on that hardware.
Is your “worst” model composed of more than just polysurfaces and extrusions? I haven’t implemented tessellation on curves yet and blocks still need some love.
There is something that I have been noticing for a while in V6 WIP display: after each view change (zoom, RMB-rotate), Rhino pauses for 0.5-1s (longer in shaded modes), before it gets responsive again. This is in more complex models, a simple models work fine. This is not dependent on AA, Shadows, GPU Tesselation (tried a lot of combinations) - this is not a new problem, before it was not bothering so much since I didn’t try to do real work in V6. Now is makes is really difficult, this micro-pause after each view change. The speeds within the move sequence before releasing RMB are much faster and nice now, but the lag between the moves is killing all the joy. V5 works fine here with zero-delays. Wondering if anyone else is seeing similar thing. Updated the drivers today, still the same:
NVIDIA Corporation
GeForce GTX 980 Ti/PCIe/SSE2
OpenGL version: 4.5.0 NVIDIA 382.05
Render version: 4.5
Shading Language: 4.50 NVIDIA
Driver Date: 5-1-2017
Driver Version: 22.21.13.8205
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 6 GB
i see this too using (6.0.17135.12071, 15.05.2017) when i have a large mesh in the file and try to do anything like drawing a line or when asked to pick a point in any prompts.
It seems to be related to snapping in my case, if i disable OSNAPS it goes away. The delays are slightly longer here, approx. 1-2s but this might be my old systems fault. It does not happen in V5, though. ATM, i cannot use the WIP at all because of this.
ATI Technologies Inc.
AMD Radeon R9 200 / HD 7900 Series
OpenGL version: 4.5.13469 Compatibility Profile Context 21.19.519.2
Render version: 4.5
Shading Language: 4.50
Driver Date: 2-10-2017
Driver Version: 21.19.519.2
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 3 GB
the model I am testing it with has no meshes, just surf/polysurf, and enable/disable OSnaps does not make any difference, so probably a different issue. Thanks!
@stevebaer, 100% repeatable over here using (6.0.17139.2571, 19.05.2017).
Test Data, download this rhino scene, then import this obj file using the import option “Max obj Y to Rhino Z”.
Once the obj import is done, enable the OSNAPS: End, Near, Point, Mid, Cen, Int and try to draw a line or a point. I’ve found that any prompt asking for a point causes a halt of at least one second, sometimes 2-3 seconds while an hourglass is displayed. Navigation using RMB or Zoom using the mouse wheel during the prompts get noticably interrupted over here. If i diable OSNAPS, everything is running fine.
Display Mode is Shaded, using default settings. I can make a video, but the hourglass is not recorded.
I think I’m repeating this in shaded mode. You don’t see this in wireframe correct?
@jeff or @mikko, do you have an idea of where this bottleneck may be? It seems like the osnap feedback is getting really slow in shaded mode for he above model, but not in wireframe.
Hi @stevebaer, it super fast in Wireframe. I guess i’ve found why its slowing down. If you enable “Snap to occluded objects” in Modeling aids, its gone. So there must be some kind of occlusion test causing these freezes.
Hi @steve I just updated Holomark to run under V6 and your improvements are massive in wireframe and shaded.
I made a “renderSpeed” mode with no isocurves or edges shown or any fancy stuff, but it is still “slow” compared to shaded and I noticed that using “render material” is slowing it down a lot. 8 units vs 128 (gpu lighting and advanced textures are off) Note that if I use a custom material with rendered color (this eliminates transparency and bump maps) then speed is as fast as with shaded mode.
You are both right and wrong at the same time:
I thought this was a new intelligent feature of Rhino to only calculate what was needed, to save the planet (and laptop power) So I just checked on the other computer (the one with an 1070 gtx) and it too had it at default: “Let the software decide” and just checked both Rhino listed and they had it at “OFF”, so it should not be active. So I did a quick test in v6 with a cube in wireframe and testmaxspeed took 1.66 seconds (60fps) Then I sat the default setting to “OFF” as well and then it spins like in v5 (0.11 sec)
I’ll run comparable tests in V5 and V6 on that machine now.
