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)
-Pascal
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
1 Like
In here itâs not Boxedit.
Selection is slow even without a single panel open.
Still quite sluggish in
Version 7 SR8
(7.8.21160.5001, 2021-06-09)
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
(7.7.21160.5001, 2021-06-09)
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?)
-Pascal
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.
Document Manifest:
Texture Mapping: 0 active, 1 system.
Material: 2 active, 2 system.
Line Pattern: 0 active, 3 system.
Layer: 129 active, 1 system.
Group: none.
TextStyle: none.
Annotation Style: 2 active, 12 system.
Light: none.
Hatch Pattern: 1 active, 9 system.
Block: none.
Model Geometry: 243018 active.
Total: 243152 model components. 28 system components.
Audit Summary:
Table tally:
129 layers
2 annotation styles
0 fonts
2 rendering materials
Object tally:
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
No errors.
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.
(7.9.21201.5001, 2021-07-20)
Nothing changed, selection is too slow.
Really too slow.
(7.9.21207.13001, 2021-07-26)
Still too slow.
Q:
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âŚ