botffy / polyskel Goto Github PK

I run demo.py hole_missing_edge.txt
hole_missing_edge.txt
and got:

All the cool kids are using python3

Hi,
Looks like we use different versions or "euclid" lib.
In euclid version here, hash use Point2.__repr__ basically rounding coords values with a 0.01 precision.
The rounding for hash is likely to fix precision issues when it comes to merge points as close enough points will inherit the same hash value.

def hash_point2(p):
   # this assume a 2.f precision from __repr__
    return hash(p.__repr__())

def hash_point2(p, precision):
   return hash("Point2(%.{0}f, %.{0}f)".format(precision) % (p.x, p.y))

Is my understanding correct that Y-axis points downwards?

I drew that conclusion by examining the test data set examples/rectangle:
40, 40
40, 310
520, 310
520, 40

Hi Botffy,

Thanks for your great work.

I have a very quick question: I was trying to use your code to generate a straight skeleton for the following outline:
poly = [(36.88, 343.19), (36.88, 161.06), (115.81, 161.06), (115.81, 137.2), (184.98, 137.2), (184.98, 6.1279), (282.67, 6.1279), (282.67, 386.26), (163.67, 386.26), (163.67, 343.19)]

Here is how the output skeleton looks like:

i.e., no inside skeleton was computed. But I feel the input outline is valid. I am not sure what is wrong. Can you please help to check in this case?

Thanks a lot!

Jing

Hi,

First off, let me thank you for your work on this library. It is rare to find a pure python implementation and I found it very useful.

I am currently working on a simple implementation for Processing and am having an issue when computing the bisectors.

I understand that a bisector at an intersection point is calculated by summing the left edge of the left parent node (A) and the right edge of the right parent node (B). However, I found that in my case, very often the new bisector needs to be inverted so the algorithm can keep running without errors.

A fragment of the Florida 's contour you kindly provided:

I got around this problem by inverting all the bisectors that intersects the edge (in blue) between their parent nodes (A and B).

However, there are cases where that bisector doesn't intersects the edge between its parent nodes but still needs to be inverted:

Questions:

• How did you manage all these special cases in your implementation ?
• Could it be that my bisector function is faulty ?

def bisector(p1, p2, p3, p4):
        
        '''Returns a PVector.
           Computes the bisector of a corner between edge p1-p2 and edge p3-p4.'''
        
        dir1 = (p2 - p1).normalize() #direction between 1st point and 2nd point of edge 1
        dir2 = (p4 - p3).normalize() #direction between 1st point and 2nd point of edge 2

        dsum = dir1 + dir2
        vec = PVector(dsum.y, -dsum.x).normalize() 

        return vec 

I would really like to have your feedback on this.

Thankfully,

I think the problem's with the calculation of bisectors of vertices created by split events

I'm trying to run the demo script on some own testfiles in which the polygon is represented by geographical coordinates (float values with 7 decimal places). Do geographical coordinates in this format work for the algorithm or do I need to consider something special here? Thanks in advance!

Have you thought of implementing Stefan Huber's algorithm mentioned in the README file?

instead of requiring the use of euclid.

Hello, under what license is this project released under ? Thank-you.

Hello
I recently contacted the developer of euclid3 which polyskel depends on. They informed me that they are no longer supporting euclid3 and have not worked on it in many years. pip install complains about deprecated installation since it doesn't have a .toml file. Can you please consider migrating from euclid3? Thank you.

Hi, Botffy
Thanks for your great job, it helps me a lot.
I have a question about the selection of distance when compare the priority of events. I saw you chose the distance between two points rather than the distance between the intersect point and the edge, which is described in the paper. Here is the change you made in one of your commit:

•   ev = min(events, key=lambda event: event.distance)
  

•   ev = min(events, key=lambda event: self.point.distance(event.intersection_point))
  

  I'm a bit of confused, Can you explain why you made this change?
  Thank you so much~

I run demo.py hole_failed.txt
hole_failed.txt
and got:

Hi @Botffy ,

I have difficulties outputting the skeleton of a polygon with a hole using the skeletonize method.
I have tried with your holey example:

import polyskel

contour = [(30,100), (50, 200), (220,240), (440,240), (430,40), (230,30), (85,40)]
hole = [(175,85), (245,140), (315,90), (385,160), (330,200), (165,180)]

skeleton = polyskel.skeletonize(contour,  [hole])) # !!something must be missing here

for a in skeleton:
    for s in a.sinks:
        line(a.source.x, a.source.y, s.x, s.y)

However the output looks like it is missing the hole information:

Would you mind helping me figuring out what could be missing in the snippet above ?

demo.py t-shape_extra_edge.txt

I'm getting an incorrect skeletonization of the vector representation of キ:

I tried both clockwise and anti-clockwise:

349,282
365,365
179,392
81,400
113,565
211,542
393,512
419,649
196,684
84,696
118,856
224,835
446,796
477,966
490,1071
664,1041
638,939
605,770
805,738
919,722
887,563
777,589
577,624
551,487
732,458
836,445
807,287
701,311
524,341
509,257
498,175

Does your implementation support polygons with holes?

Hi,
I was reading through your code to understand the paper better. There is one point that I'm not quite sure about.

In step 2e (for non convex polygon), dot point 4 (I'm referring back to the paper), the author define point X and Y as end point and start point of the opposite line segment. The way I understand this is literally the 2 end points of one line segment.

But after reading your code (and to be fair I didn't spend enough time to process them all), I think the way you implemented it is the 2 vertexes that is currently pointing to that line segment. Which is not similar to my understanding, since the vertexes pointing to one edge can change during the computation...

Another thing I wasn't quite understand (from the paper) is that on step 2c (for non convex polygon), the authors mentioned outputing the "local peak" of the roof. I can see you did the same for edge event, but not with split event. Why is that?

Thanks!

Hello and thanks for your very useful library. I implemented it in FreeCAD:

github repo

there is a library called Pyskeleton that can take different angles for each edge:

different angles

Can we apply this feature in polyskel? Thanks a lot