The following applies to Rhino WIP using Direct3D.
It’s more or less the same with OpenGL, and it’s the same in Rhino 8.
There is a file with ~300000 flat curves.
The display performance is excellent when zooming etc..
But not when the curves are selected.
Or when we select one curve by a single mouse click.
The video shows the effect using TestMaxSpeed:
Unselected: 2sec.
Selected: 43sec.
I wonder why yellow elements take so much longer to display?
We can feel the lack of speed when we select an element by mouse click.
There is a notable delay until the element is yellow on the screen.
1sec.
And it takes the same time when we unselect by click into nirvana or ESC.
Makes me think the identification of the element is super quick, but not the display.
When I try the same geometry in Rhino 1.1, select/unselect has no delay at all for a single element.
It shows in yellow immediately.
(The general display performance of V1.1 is of course not on the same level as in V8/WIP - no wonder.)
@jessesn says it’s because the sheer count of objects.
300k curves isn’t that much!
Rhino 1.1 show the reaction w/o delay.
Rhino 8+WIP feels and is slow in this regard.
Not that I’m qualified to add any thoughts here at all, but one major difference between Rhino1 and Rhino8 that crossed my mind when reading this thread is history. When was history introduced in Rhino (according to Gemini, it was introduced Rhino4)? And I wonder how this file reacts in Rhino7 compared to both Rhino1 and Rhino8.
[edit]
And does performance of this issue improve any if history is turned off?
Also, I can’t even make 300,000 curves on my computer, which, it’s not a very good computer, so that’s not surprising. I can make 30,000 rectangles and my computer struggles a bit, but once they are there, selection is not noticeably slower. But attempting to make 300,000 rectangles (with the array tool) just seemed to make my computer endlessly do nothing, so I had to ctrl-alt-delete and end the Rhino process. I mean maybe if I waited 5 or 10 minutes it would have made them, but I didn’t want to wait.
Unfortunately, there isn’t really a solution to this problem. As soon as you notice a performance slowdown in the 3D view, you can be certain it’s due to data transfer between system memory and GPU memory via PCIe. For some unknown reason, Rhino constantly updates data on the GPU (especially during selection), even when you’re simply moving the 3D view.
The only relatively effective solution is to limit the number of objects—whether curves, surfaces, or meshes.
For example, many real-time rendering programs like Unreal or Twinmotion offer features that allow you to combine all objects with the same material into a single large object. This is simply a trick for batch data transfer; it’s better to have one large mesh than 1,000 small ones. (You must also take into account the data regeneration time. This time cannot be faster than the speed of your processor)
Bref, in your file, each straight line is a separate line. The most effective solution is therefore to merge your lines.
with Rhino 7:
Your file also contains identical and redundant lines. If there are many of these lines, removing the duplicates will further improve performance.
Oh yes, and video capture uses a bit of PCIe bandwidth. But I’ve split the video, so at the beginning you can see the bus usage with recording enabled.
I think there is a solution, perhaps not yet in Rhino.
Other (well-known) apps can handle such cases with ease.
I can’t see that in here, Bus Interface Load is near 0.
Recording using Camtasia doesn’t show the truth, it cranks up the GPU clock and uses ~12% bandwidth.
Without recording it is ~0-2%:
That makes it easier to handle large data sets.
Large meshes in Rhino work good in Rhino.
I don’t want to work with this file, I want to demonstrate a problem.
Rhino is excellent for dimensioning and layouts.
What’s really missing is the same level of performance as in the other well-known app, which is widely used for plans.
If Rhino can compete, it’s more likely to be used as an alternative.
Okay, it’s still strange that the bus isn’t being used at all…
And yes, the first version of Rhino really did work very quickly with large imported AutoCAD files.
I wish I had it, too.