Well I feel dumb for not trying this before, but the workaround that Pascal posted on March 3 (set grid to transparent in Options>View>Display Mode) seems to work for Wireframe and Shaded view modes
Yes, that helps in cases where there is a really dense set of objects as selection candidates. (I do not think this is the case in the examples you send but worth a try I guess)
thanks… No it did not help.
Not any better in (7.6.21124.9001, 2021-05-04)
I still wonder why this is not considered as bug or regression.
Also not mentioned in the list of changes in SRs.
In simple scenes you can’t feel the slow reaction.
In real-world models you will.
I discovered this morning that the slowness and lag appears when the BoxEdit panel is open and visible.
My 11 years old laptop was faster in selecting objects in the same scene file compared to my main desktop with 16 cores threadripper, 32GB of RAM and RTX 3090. Same experience with the Razer Blade 15 and that was because it was a fresh install and the BoxEdit panel was not open.
I hope this will could solve most of my (and yours) problems. After a couple of hours everything is still fine.
yes this is a known issue with Boxedit… mentioned in previous issues with v7 speed
In here it’s not Boxedit.
Selection is slow even without a single panel open.
Still quite sluggish in
Version 7 SR8
I just upgraded to V7 this week trying to shortcut a plugin problem.
+1 to sluggish selection making V7 basically unusable for models with any practical amount of complexity.
Version 7 SR7
Edit to hopefully make post slightly more useful:
To me the selection lag seems to be proportional to total number of things on the display… as if we are iterating through a list of all the visible stuff.
For example the worst-case scenario seems to be particularly gnarly PDF files someone made from a faxed photocopy of a soggy napkin. Running ‘join’ on it as a whole and just let it connect up as many random segments as it can, does seem to help substantially with the selection lag.
Doesn’t it make more sense to write out a buffer with object id of what’s under each pixel when rendering the viewport? Let the GPU do the work.
Then your selection lag is pretty much nonexistent because we already know what object is under each pixel.
Then the selection menu thing can go away because we’re absolutely confident what is where we clicked.
Could have an alternate click that gives you a list of objects in a 3px or 5px circle or something if we want to make complex selections?
Hello - what kind of numbers are we talking about?
Does the display mode make any differnce? (Wireframe, Ghosted, Shaded, for example, all the same?)
No difference. And I see now also that I shouldn’t have said number of things on the display, but rather number of things in the model with visibility. I.e. makes no difference if you are zoomed in on a single curve or have 200,000 of them in view.
Is this useful? Audit from a slow file.
Texture Mapping: 0 active, 1 system.
Material: 2 active, 2 system.
Line Pattern: 0 active, 3 system.
Layer: 129 active, 1 system.
Annotation Style: 2 active, 12 system.
Hatch Pattern: 1 active, 9 system.
Model Geometry: 243018 active.
Total: 243152 model components. 28 system components.
2 annotation styles
2 rendering materials
243018 normal objects
0 locked objects
0 hidden objects
0 deleted objects (in undo buffer)
0 block definition objects
0 reference normal objects
0 reference locked objects
0 reference hidden objects
0 reference block definition objects
The thing that seems strange to me is V7 seems to get faster the more you select stuff sequentially while testing it. Almost its like some kind of caching thing. I have no idea what’s happening but if you’re like searching down some data tree on selection is it possible that memory would sit in cache and give progressively faster search results until you go do something else with the cpu for a while?
If you keep selecting stuff V7 gets down to the speed V6 just starts out selecting at but if you haven’t selected anything for a while in V7 takes forever for the first few.
Last clue it seems to revolve around situations where there are a multitude of potential candidates. If you isolate something and direct compare V6 and V7 with the same file selecting the same item they feel the same.
In my test file, from above, If I zoom way out so my click could be selecting pretty much any object in the scene, this is where V7 is substantially slower. V7 was 65 seconds to produce the object list, vs 28 seconds for V6.
Completely talking out my ass here but this feels like we are digging through some depth buffer of objects that is based on logic addressing a 2d situation where you have like 300 curves stacked directly on top of each other and it’s impossible to tell what curve the user wants to pick from the ‘top view’ so you have to list all them.
What if we had a new TestHackySelectionMode where it just instantly gives you the first object that is not the current selection. If you want to get fancier than that you can mod-click and wait for a list of objects to scroll through. I feel like I’m pretty careful about setting up my views and layers for clean selection and the menu just drives me bananas 99% of the time.
Nothing changed, selection is too slow.
Really too slow.
Still too slow.
Are there any plans to have a look at the issue?
We did recently discover that the TwinMotion plugin can cause large delays with selection. If this plugin is installed, disable it and restart Rhino…