WISH : Extend surface by length

Hi David -
We do have some stuff in the works for converting some trimmed edges to untrimmed ones when conditions are right - by which I mean good enough, but imperfect in that simply shrinking will not do it.

-Pascal

Yes, as I’d expect, though it looks like the right example should be labeled “Untrimmed output”, not “Trimmed output”.

This is no more confusing than using the current V6 version of ExendSrf. Sometimes it extends a surface by by a consistent distance, and other times not. The current Help section for ExtendSrf only talks about “distance” and doesn’t mention the different responses. I didn’t know the reason for the difference until I read this thread. It never occurred to me that the reason was trimmed vs untrimmed edge, and I’m a relatively experience user who is familiar with computational geometry. (One of those software “features” which is completely obvious once you know about it, but not obvious to those not in the “know”.) Adding the options as I suggest above, breaking the dependence on trimmed vs untrimmed edge, and documenting what the difference between the options will be less confusing.

1 Like

Hi David - no, the output is trimmed and input is untrimmed - that is the point I’m making - currently, there is no ExtendSrf scenario that makes this fundamental change and I’m “just sayin’” . We can argue about whether that is important enough to fret about on behalf of less experienced users, but I am fretting, just a bit- there is a noticeable difference in behavior, is all I’m pointing out , between the two - DupEdge will give a completely different result, MatchSrf on any of the adjacent or extended edges will fail where it may have been perfectly happy previous to the extend, etc etc. I’m not suggesting that it should not be done, only that it’s a bit tricky.

-Pascal

Pascal, the current implementation of ExtendSrf can cause the type of confusion you are fretting about. Here is a simple example. Two surfaces, A and B, which appear to be identical. Use ExtendSrf with distance equal to 4 on both, The results are different. Nothing while executing the command nor in Help gives a hint about the reason.
ExtendSrfConfuse1.3dm (79.8 KB)

My suggestion is to end the hidden dependence on untrimmed vs trimmed edge, and provide the user with the ability to select the desired/needed behavior.

Hi David - yeah, but that actually illustrates my frettage - the trimmed surface is trimmed after the extension is done and the untrimmed one is untrimmed when it’s all done - so there’s nothing that you can’t do with the output that you could with the input, if you see what I mean. The confusion I foresee in my grim view of the future is starting off with B and finishing with A

-Pascal

Pascal - I’ve actually been confused with the V6 version of ExtendSrf while doing “real work” by not knowing if an extended surface will have a trimmed edge or an untrimmed edge. Sometimes the surface I’m extending has an edge which with a small trim which isn’t obvious looking at it. Other times I’ve been confused or even had to redo work because the surface (with an untrimmed edge) was extended an inconsistent distance while a previous surface (with a trimmed edge) did in fact extend a consistent distance.

In my example above without a careful comparison of the extended surface to the original surface either A or B are plausible as the extension with the consistent distance.

I understand what you are fretting about but in my experience ExtendSrf in V6 is already providing that level of confusion. I would prefer an explicit choice to guarantee an untrimmed edge with a likely inconsistent extension distance, or a trimmed edge with a consistent extension distance.

Yeah, that is kind of what I’m thinking as well - I believe it used to be that way, once, if memory serves, as separate commands in fact, but consolidation set in - anyway, the main thing is to think about this rather than just toss it in…

thanks,

-Pascal

I was going to make a new thread asking about this, but I perhaps it belongs here:

1

Whatever the underlying technical reason, the currernt UI doesn’t make much sense from a user perspective.