Add an exploded view to sketches#1003
Conversation
|
Interesting. Please be aware that you are attacking a problem (the selection of overlapping entities) that has been discussed many times in the past. Some I found easily: |
|
Thanks, I hadn't really dug through the issues and have been using this to familiarise myself with the codebase as much as anything. I like the sound of select-by-order as an option too, providing you do already know what you're trying to select, that'd probably be a quicker option. I haven't really decided myself if the exploded view is that useful so I thought I'd code it up and try it out for a bit. I think so far the most useful functionality it adds is the ability to better visualise a complex overlapping imported sketch. Selecting the right thing is probably a secondary issue to working out what the heck's going on in the first place, especially when there are conflicting constraints and/or open contours (which aren't immediately obvious) in the imported data. Also, I didn't realise it'd kick off a test run by opening the PR as a draft, apologies for burning through CPU cycles on what won't be the final code. Should I close this and continue developing on a branch until it's ready for proper review? |
In my opinion it's fine - don't worry about it. At this point GitHub does not seem to complain about us using too much CPU for CI. If you want to "save cycles" you can of course push to your branch more rarely or even close the pull request. You can reopen it later. As you wish. |
7a17f89 to
741b7d1
Compare
|
@tomsci not sure if you're still interested in this, or if I like it ;-) It just occurred to me that you might want to keep non-overlapping entities that are the same style on single layers in the exploded view. That's even more code to sort them for a feature that seems to be uncertain anyway, but I wanted to share the thought. |
|
I've been using it regularly for the last couple of weeks and have found it to genuinely pretty useful. There isn't any other good way that I've found to disambiguate the selection of, for example, one specific point belonging to line X when there are 4 or 5 other entities which also have a point at that location. I did read through all the issues referenced and none of them seemed to offer a visual way of doing that - having to either scroll through the text window, or repeatedly step through clicking keys/buttons whilst watching the text window would both quickly become unwieldy or impractical on large complex models, which is of course when you might need the feature the most! My approach tends to be to start in the orientation of the workplane (ie by pressing 'W'), from that orientation the exploded view is of course indistinguishable from the normal view, and then rotate my view slightly to "peek" under the point/line I'm interested in to find the actual element I want to select. And then reorient myself - doing normal work in the exploded view at any other angle is pretty much impossible as you'd expect. But by repeatedly going back to the workplane aligned view I don't have to keep toggling exploded view on and off, so it works pretty well for me. I decided against attempting any sort of overlap detection or grouping when calculating the z-offset, I wanted to keep the code as simple as possible, and once I added the The code changes are still more invasive than I'd like - suggestions welcome on any ways to improve on that! - but I've quickly come to rely on this feature myself and am keen to progress this PR if at all possible. |
|
Updated branch to fix minor conflicts with latest master. @ruevs Any more thoughts on this PR? I've been using this feature semi-regularly for the last few months on some models complex enough SolveSpace can't even calculate a valid mesh for (but that's a separate issue...) and haven't found any problems. At this point I'm relying on having this feature so I'm maintaining it on a branch for myself anyway (just the other day I had to build win32 binaries with it in so I could work on a beefier PC running windows), but it'd be nice to have it in master instead :) |
It certainly could be a tickable menu item in the View menu which applied to whatever sketch was active, like "Use perspective projection". And I must admit I like having keyboard shortcuts for everything. In that case the explodeDistance could move to the configuration view. It would probably also simplify the code a little since each groups wouldn't have to track anything additional. I think I'm talking myself into some extra work, dammit :-) |
|
I've made the discussed change to move the toggle option out of the per-group settings and in to the View menu ("Show Exploded View") and the explodeDistance to be global, in the configuration page. I picked the shortcut key |
|
@tomsci Can you squash some of these together and push it? BTW nice choice of "" for the key I think. |
Where each entity in the active workplane sketch is projected a different amount normal to the workplane, to allow inspection and easier selection of entities that entirely overlap each other and are thus otherwise difficult to see or select. The distance between the exploded "layers" can be controlled in the configuration page. Negative distances mean the layers are projected in the opposite direction, relative to the workplane normal.
|
@phkahler have rebased and squashed. |
|
@ruevs Anything to say about this one before merging? If not, push the button ;-) |
|
OK I reviewed it and played with it. It is nice. It can be quite helpful when many entities are on top of each other. It is especially convenient combined with II like that the explode distance can be negative and it explodes "back" from the work plane. The code changes in src/drawconstraint.cpp and src/drawentity.cpp are "all over the place", but the way the drawing of constraints and entities is structured I don't see how it can be better with the current code. I have not tested them all. |
@ruevs That was my thought as well. Most of the "all over the place" is just replacing one function call with another that returns position with the exploded modification, so it's actually kind of clean. Just wanted to see if you'd have an alternative idea on how to do that. ;-) |
This PR adds an option to workplane sketches to draw all the entities in the sketch "exploded" normal to the workplane. The reason for doing this is that it makes it much easier to select lines and points which entirely overlap with other lines/points. I've found that when drawing a sketch from scratch in SolveSpace, I can usually use the "requests in group" list to find what I just added, but when importing complex DXFs created by other tools, that have all kinds of weird unexpected lines and constraints, it can be very difficult to figure out what constraints violations the import has created.
For example, here's a really basic sketch with a construction line hidden under the top line of the rect:
Here's the same sketch rotated (obviously, this doesn't help identify the construction line):
But now if we enable the new "explode" option:
It's now really obvious where that line is:
Enabling the "explode" option does not affect the underlying data, the plane adjustment is only made when rendering, and only when the sketch is active, so it wouldn't show up in any exported view.
Hmm now I try it thought, I may need to tweak that because constraints do show up in their exploded positions...Edit: now fixed, exploded coords are now never exported.I've tried to update all the constraints drawing code to put the constraints in the same plane as the entity they're constraining, although I gave up on some of the more complex constraints that aren't solely in the workplane to start with. I figured it might be more misleading to mess with projected points and lines and such, and also my geometry skills were starting to struggle to figure out how to actually code it. If anyone else wanted to fix that, be my guest.
The "explode sketch when active" checkbox and the
explodeDistanceis per-Group, but I haven't updated the file format to persist the choice. I wasn't sure whether to, or not. It'd be convenient to remember it, but updating the file format looks like it introduces a warning dialog if anyone opens a newer file with an older version of SolveSpace, so I wasn't sure if it'd be a good idea to introduce that for such a minor feature. Feedback welcome on how best to do that! Or whether to just not bother, of course.