Now, using the second one is a no-go, as I cannot tell in advance which side should be removed.
With the second one I reach an impasse.
In order to get the domain which should be kept. I need the points of intersection and use it to find the parameter on the curve. I need to intersect the curves, but there’s no such method, or at least I couldn’t find any. I didn’t find also under Point3d class a method to create a point from intersection.
For multiple curves i always use intersections and split the curves by them, discarding the parts i don’t need in the process. Trim in my understanding is only for simple cases.
Intersections in Rhinocommon have their own Namespace.
You will probably want to use CurveCurve , retrieve the intersection parameters from it, split your curves by the intersection parameters and figure out what curves to keep.
Well, intersections are complicated. Two curves can have multiple intersections and some parts could overlap. So you need to have an output for each “intersection event”. Yes, given that there are also “events” and an “event watcher” which are not at all the same thing, the terminology is perhaps poorly chosen. One could call the intersection instances, but that might get confused with other uses of “instance”.
So let’s say curve A intersects curve B three times, two of them at a point and one of them as an overlap. That will generate 3 “intersection events” - how do you want to name them?
You can think of a curve as a piece of a timeline going from t0 to t1. Evaluating t on curve going from t0 to t1 then will give you events of intersection.
Indeed, the search for proper terminology to describe this set of circumstances is an adventure. Perhaps I should say “was” since I’m pretty sure you aren’t the first to confront it. In fact, I suspect the CAD pioneers and/or the Rhino developers faced it early on and “events” is what they came up with. Despite the thoughts you may have at those times when the way they chose to do things doesn’t seem optimal, they are probably all at least as smart as you and I. I, at least, am delighted they came up with a way to talk about the multiple intersection situation and am perfectly delighted to accept their terminology. Saves me from having to invent it. Unfortunately, it does fall into the category of things in Rhino that I must adjust my thinking to rather than things that surprise and delight me because they are just as I would intuitively expect them to be.
lol @AlW, it’s been a while since I joined the forum I am well aware that McNeel developers are not incompetent. Besides who am I to say anything about developing stuff, I’m a total noob. I merely said it’s totally confusing.
I am also well aware they are not going to change it. It makes no sense giving the fact that all previously created script and plugins will stop working.
I am a forthright person, if you haven’t noticed .