Hi Armin, thanks for posting your example file! This is a bug, which involves the curve length just like you guessed. Curves were only being extended to a maximum of 20 times their length before looking for intersections with the boundary, which for smaller curves was not enough.
I've fixed this up for the next v2 beta so that it will look at the bounding box around the curve and all the boundary objects so that it will make sure to extend it far enough to intersect with the boundary. That fixes it so that all your examples will work in the next v2 beta.
Thanks for reporting the bug along with the file so I could reproduce the problem, that helps a lot for being able to fix it.
> Now, the TRIM command, knowing now what I have done
> wrong, I thought there are a whole bunch of clicks (7x) to
> achieve the desired result.
Actually, I only count 6 clicks:
1 - select line that is to be altered by trimming
2 - click on the Trim button to launch the trim command.
3 - click on the cutting object to select it.
4 - right-click to signal that you are done with selecting cutting objects (same as Done button)
5 - click on piece to discard
6 - right-click to signal that you are done selecting pieces to remove (same as Done button).
> if I could just invoke the TRIM command and then click
> on the segment I want to remove and it would be
> gone (2 clicks).
That would be pretty cool for this "only 2 lines" type situation, but doing that would also bring about quite a lot of negative side effects though.
To start with, if the command ended so quickly it would not be possible to make just one command that handled both a "Trim" and a "Split", Split meaning where you keep all the cut up results without discarding any, which can be useful in different situations.
It also tends to be easier to "undo" a mistaken click with MoI's current system because if you clicked on the wrong thing you still have a chance to correct the selection before it actually throws stuff away.
It also can let you work more selectively on groups of objects, since you have more control over specifying which things are going to be altered. (2 of those clicks in the workflow are basically for you to tell MoI when you are done selecting things so that this will work on groups of objects rather than only on single objects).
Also using window selection (either with crossing or "only inside" type selections) tends to work well with this "select fragments" method.
Also there are situations when trimming a surface object, where it isn't so obvious where to click on the whole surface until you see the fragments (which you otherwise would not see in the "quick" method that you are talking about), like for example here I want to trim this cylindrical surface by the curve off to the side, with the "pick piece to discard" type workflow of MoI's current trim command you get to more clearly see the pieces for where intersections are happening (especially while staying within the 3D view):
Then another thing is that MoI's current method allows for switching to a "Keep" mode, where the fragments that you pick will be the ones that are kept with all others discarded. This mode can be especially helpful for surface trimming where the pieces you want to discard are internal to the model and not easy to pick.
The Mode=Keep method would not be able to work properly in all situations if it discarded all the other pieces on a single click. For instance here I have a plane and I am trimming it with 4 crossing curves:
I can set Mode = Keep and then click on these fragments to keep:
Which will results in this trimmed surface:
If all the other fragments disappeared on just the first click with mode=keep then that kind of sequence would not be able to work. Mode=Keep is not a big improvement for this particular situation, this is just to try to illustrate the workflow issue. This same aspect of Mode=keep does come in really handy when the easiest piece to select from a surface trim are a few big parts that you are intending on keeping and have the excess removed.
So overall there are a lot of benefits to this current Trim system...
This is one of those cases where having some more steps has greatly increased the overall power of the command. When there are enough benefits like this they can add up to outweighing saving a few clicks. Particularly things that are set up to be flexible enough to work on a set of objects rather than only one-at-a-time will usually need some extra confirmation clicks within the command. But when the time comes that you want to do a kind of batch operation it can be really valuable.
The other thing that can be a problem is if saving clicks for a particular command could cause it to behave in a different manner than all the rest of the way that other commands work. That's another pretty big consideration for this case because the way that you are talking about would involve selecting the object to be modified _after_ you start the command while all the other commands generally work by selecting objects to be modified before running the command. When one thing sticks out and doesn't follow the regular sequence it can be bad even if it is saving clicks...
Anyway, those are some of the details about why it is the way it is! :)
- Michael
