Do you have any tips in enhancing display performance for commands like waiting too long for “show selected” or nearly freezing when extruding multiple curves. I know this is quite a bunch but I have a Quadro 4000 and it’s displayed wireframed. Thanks for your inside!
Unfortunately, a graphics card that supports far more than Rhino V5’s minimal OpenGL requirements (OpenGL 2.0, Shader 1.2), does not directly translate into faster overall Rhino performance. The graphics aren’t the bottleneck.
It’s like buying a Ferrari as your daily driver and expecting it will reduce your commute time into work. The car isn’t the problem, it’s the traffic.
Sorry.
Thanks for the fast insight John, fully illustrating this. Actually I’ve switched to Quadro4000 because I thought this would increase performance esp in Rhino since Modo is working even better with far cheaper gaming cards.
Only thing maybe to consider is implementing dynamic display as bounding boxes in settings at least even when Extrude Curve or speed things up in showing as shaded and not wireframe.
Any hope this will change in V6? Maybe better performance when switching off anti aliasing? Thx for your help on this.
I think the problem with your extrude example is processor calculation because you’re working with so many objects at once. I know the developers are always looking for ways to make Rhino more efficient and faster, but this example has very little to do with graphics.
Thanks John, will consider to extrude a test portion for evaluation and going for all in the end. Strange, have a 6core and I think there might be more efficient ways to display this feedback (showing predefined steps, and not all possible minor steps which would consume most of the cpu power, calculating real geometry only after confirming and display only a reference via video card etc). Rhino has to get a bit smarter in these terms.
Actually, even only rotating/tumbling this flag geometry in 3D space causes a jagged behaviour on my quadro 4000. I find this kind of poor and slightly not up to 2014…
and just wanting to SHOW SELECTED those hidden objects would freeze my system for ~10sec and another 10 sec for getting back to normal view again. Quite frustrating…there should be even here some smarter approaches in making the workflow more fluent and less accurate (geometrywise)
Hi Hannes,
Do you have other software to test this against? There are a lot of individual objects that need to be transformed, it will take more time than a single object. I’m curious how other software handles type of geometry, have you compared it in other software?
-Willem
Willem, I will check on Modo, which I use additionally.
But for now some new issue: Exploded meshes will dramatically increase display speed slow.
So strange. Couldn’t it be far more fun. I mean, does any tech guy know that a slow system performance is the main cause for getting frustrated and canceling ambitious projects? Should be core issue to streamline an application IMHO
Hi Hannes,
Any results from Modo yet?
That is correct, it has all to do with the way thing are managed in the background.
Exploding a mesh means you create 100’s or 1000’s of extra objects (mesh parts) instead of just one single object.
Drawing an object onto the screen involves a certain number of steps (for instance: transforming it to the view projection, checking for intersections with other geometry, checking for visual overlap with other objects etc…).
Having to do that for more objects simply adds time. Sure there are ways to optimize that, and I know at McNeel they are constantly looking for ways to optimize performance. However it is always a balance in distributing resources.
McNeel like any other company has limited time to spend they have to decide where to spend it on.
I disagree; I think it should be core issue to balance an application so that it’s essential functions are free from (serious) bugs, it’s user-interface is good, it’s performance is good etc…
I’d rather have a Rhino performing a little slower than a Rhino with bugs in core functionality.
my2c
-Willem
