I'm working on a tweaked version of the script to make it more friendly for a strict "Lasso" selection...

It will be sufficient to draw the "Lasso" and select it. Then fire the script.

And...voilá!

I have to add the code that should automatically remove the "lasso" at the end of execution if something has been found.

N.B. Keep in mind the same considerations of my previous posts. It uses the "project" command with "closes pt".
Then all the previous considerations can be applied also to this "modified" implementation I'm working on for the "Lasso"

Thanks a lot, I missed this command quite often. Maybe it would useful to combine this script with "SelectInetrescted" script which works as a lasso selection for solids, then "Lasso selection" script could be universal.

Your idea to combine this script with your "SelectInetrescted" it's a great idea!

I hope soon, maybe tonight, to release the 0.2 version of "PlanarHolesFinder" and also the special modified version "LassoSelCurves"
and the in the next days I will study "SelectInetrescted" to see what can I do to combine both!

It could be a great thing having these kind of scripts combined, but also in the case it will be too complex,
with the very fast workflow of Moi's shortcut we can always fire commands/scripts at the speed of light :)

My intention is to create a little set of very specialized script especially dedicated to 2D Workflows,
and "PlanarHolesFinder"/"LassoSelCurves" are just the first,
but...at the moment it's best for me not make too many plans :)

> But...I didn't understand very well this part of the sentence :
>
> @You : "It doesn't work too well with curvy surfaces when the curve isn't right near the surface though."

If you have a curvy surface instead of a flat surface, this type of projection down by surface normal will make the projected result squish together or expand and the Solids++ routine for this function doesn't deal very well with that, it tends to produce a curve with little zig-zags in it. If the curve is pretty close to a wavy surface it can work ok though.

But I need to make a new implementation for it at some point here since it can give bad results.

@You : "...If you have a curvy surface instead of a flat surface..."
But...the problem is that I never have Non-flat surface.
The surface that I use with as the target for "Project" is always flat, but there are some situation where it fails anyway.

As you can see at position 01:58 I use the Circle as reference to find holes in it.
The circle if is simply rotated but is FLAT.
And as you can see the blue curve is not considered "hole". Is not "captured" by the "Project" command.

Hi Marco, yes it sounds like the "closest point" mode for project isn't reliable enough for you, the direction mode should work better. Or another possibility could be the steps that I mentioned earlier - determine if any curves intersect the outer boundary (use the "intersect" factory from the Construct > Curve > Isect command and see if it generates any result), remove those then send the rest to planarsrf to generate loops. Use the hole loops to identify the curves they came from by seeing if any start/end points match between the curve segments and the hole edges.

Because this part of the sentence " if any start/end points match between the curve segments and the hole edges" it's too restrictive.
I could have more than one curve that shares the same start/end point but with different shapes.

For example :

Furthermore also this part of the sentence is not what I want to do : "...remove those then send the rest to planarsrf to generate loops."

Because I want to use my script to find not only "totally enclosed curves" but also "partially enclosed", that is the curves that intersect the boundary of
the "container".

I really don't know.

Maybe for the moment I can continue to use "Project" with "ClosestPt" and for the moment not to take into account the rare cases where it fails .

Or I can decide to witch to "Direction" mode and for the moment restrict the scope of my scripts to "TOP plane only", that also was the original idea.

I don't know.

Have you got a final suggestion to give me about these considerations ?

Hi Marco, my suggestion for the shared point case you show there would be to not consider that to be a hole, that will be malformed geometry if you try to actually create a hole like that where a hole boundary intersects with the outer boundary. Boundaries should not be self intersecting and outer/inner boundaries should not intersect with each other. If they do then there become areas of a trimmed surface where the inside and outside regions of the surface are not well defined.

For the other part you mention:

> Furthermore also this part of the sentence is not what I want to do : "...remove those then send the rest to planarsrf to generate loops."
>
> Because I want to use my script to find not only "totally enclosed curves" but also "partially enclosed", that is the curves
> that intersect the boundary of the "container".

Ok, then instead of removing the intersected curves from consideration just put them also into the "captured" list but don't send them over to planarsrf.

But another problem is it sounds like you're not just looking for "holes" anymore, to make a "hole" it has to be a closed curve.

Hi Marco, also for direction I think you should be able to automatically figure out a projection direction by getting the bounding box of your containment curve and then seeing which direction has a zero extent.

@You : "...But another problem is it sounds like you're not just looking for "holes" anymore, to make a "hole" it has to be a closed curve..."

You're right Michael :)

The fact is that I wanted initially to start a script for "2D workflows" not for "solids" or "solids boolean" stuff.

My script does this main things :

1) Capture all curves that can be considered "holes" of another flat curve.
I know that this part of the sentence was not very clear.
When Is said "Hole" I wanted to say : closed curves that, when projected, are totally enclosed into the "planar surface" created using the"container" curve.

2) During my coding I also wanted to add capabilities to capture also other situations.
So, now I'm coding my script to be fired in 3 different ways :

A) Capture all "totally enclosed" in "container curve"
B) Capture all "partially enclosed" in "container curve", that is the curves that when projected they intersect the boundary of the "container"
3) Capture both of them

But...during the coding and also during the various experiments and tests popped into my mind that the scripts also could works with
other planes, not only TOP plane, and I started to face with the problem of "Direction" vs "ClosestPt."

Now I try to switch to "Direction" mode and leave the script with the minimum interaction with the user,
assuming that the direction in forced to TOP plane.

Later, when the first official version of the script will be tested by other users, I will try to make it more complex.

I'm also writing the variant for a quick "Lasso" selection !

Thanks for all your help :)

I think I need some suggestion for using the "Project" factory with "Direction", but I want first to try.

Hi Marco, we might have been writing posts at the same time so make sure not to miss my additional message above about how to automatically determine the projection direction.

Also another thing you might be able to use for containment detection is Construct > Curve > Isect - if you build a planarsrf with your main boundary you could then run intersect on other curves and it will return points if the curve is on the face.

re:
> Do you think I should create a brand new thread for this first official release to give
> it the chance to be viewed and tried by as many users as possible ?

Sure, that sounds like a good idea.

re:
> Meanwhile could you please remove the old thread that I created some days ago named : "A
> possible script for finding "holes" of a planar closed curve" ?

Are you sure you need to have it removed? Since there was some discussion there about possible strategies maybe it could be useful for someone doing research on how to approach a particular kind of script in the future...