For years I've been annoyed that on occasion snaps didn't work but I could not figure out what the cause was. If a filled shape exists in 3D space above a element in CE and you attempt to snap to the element snaps will not work even in wire-frame. Under users>preferences>input> Locate interiors is set to never. Is this intentional or an oversite?? Attached file for others to try maybe it's just me?
This has also been an issue for me - I've tried to get to the bottom of it with this thread; communities.bentley.com/.../594681
... but without a solution I'm still using v8i to remain productive.
As a summary of the problem (using your file), see below. I really hope someone could provide a solution to this.
^ Is this the case for everyone in this thread, i.e. trying to snap through a transparent filled shape in wireframe?
Does everyone agree that if the shape was not transparent you shouldn't locate/snap to elements behind it as you're not able to see them? This enhancement was made to locate for CE as there were numerous reports of undesirable behavior related to locating/snapping to geometry that is not visible.
I can definitely understand a request to special case transparency...
I agree with Max.
I also agree with Max and would make the argument why have a locate interiors option in the preferences and then ignore it. If you want to tether filled shapes to the locate interiors options I have no issue with that, it would be more predictable then the present behavior. What we have now just feels like the developer got half way there and took a coffee break decided never to get back to it. If locate interiors is set to never then any filled shape rendered or other wise should never interfere with a snap.
Grant Wood said:What we have now just feels like the developer got half way there and took a coffee break decided never to get back to it.
While I do enjoy my coffee way too much, this is certainly not the case.
Grant Wood said:I also agree with Max and would make the argument why have a locate interiors option in the preferences and then ignore it.
It's not being ignored. Setting locate interiors to never doesn't mean pretend this surface doesn't exist and start picking things you can't see through it, it means only locate this element by it's edges, but still truncate the list of hits at this surface so that reset and tentative snap also can't cycle through elements that aren't visible.
In the simple case of a single solid and line it might seem appealing to let you pick an element you "know" exists that is behind the solid, but Imagine an entire building in a shaded view, there can be thousands of elements under that roof.
This wasn't changed in a vacuum one day for "fun", it's cases like that building and snapping to beams and elements on other floors that aren't visible and the feedback we received that prompted the enhancement to locate.
You should need to see what you are picking, which could mean changing render mode to wireframe. As previously stated, it definitely would be nice to make a special case for transparency as that fits in with letting you pick what you can see.
Display depth and clip volumes are both valid tools for controlling how much a user has to click through in active modeling. In my humble opinion the community in general hates CE for cases like this. Going from v8i to CE things should have stayed the same with options to change functionality, not the other way around. I understand why it was changed and even the consideration behind it, however that doesn't change the perception. I've been using off on and starting at U0 in 2016, and full time for 2 years now, there are still many behaviors that feel off but I haven't had the time or energy to chase them down this is just one example.
Brien Bastings said:This enhancement was made to locate for CE as there were numerous reports of undesirable behavior
I would argue that enhancements made because of "numerous reports" shouldn't necessarily cause existing "expected" behavior to be eliminated. Adding an option to satisfy those reports while maintaining current behavior would avoid upsetting users who had no complaint about behavior as it existed for many years. User expectation is that, if it worked a certain way yesterday it will work the same way today, or if not, they should be given notice of the change and if at all possible be provided a way to revert to the desired behavior.
Apparently the squeaky wheel gets the grease, but at the expense of irritating users who had no complaint and like the way it has always worked in the past.
Ron Jones said:I would argue that enhancements made because of "numerous reports" shouldn't necessarily cause existing "expected" behavior to be eliminated.
This is correct, but locating elements you can't see is not "expected" behavior, it's learned behavior. You also can't add options for everything, that's unwieldy for the UI, documentation, and testing.
Ron Jones said:Apparently the squeaky wheel gets the grease, but at the expense of irritating users who had no complaint and like the way it has always worked in the past.
That's not how it works as I am sure you are well aware. While it is true that we rarely hear about what people like, change requests are evaluated on their merits. For example, I will push back on locating elements that aren't visible, but agree the current behavior with transparency is not ideal.
The entire purpose of new versions is to try to improve the product, not keep it it same; you are talking about a change that was made 8 years ago...
Have a good one folks.