pylygon

pylygon - 1.3.0rc

Chandler Armstrong (omnirizon)

Tags:

Description

a polygon object with rotation and collision detection methods.

notable algorithms and implementations:
graham-scan convex hull
separating axis theorem
GJK
GJK-based raycast

Changes

I had a minor data loss incident and lost the changelog, but here goes from memory:

* raycast algorithm modified to accommodate translation + rotation

* the 'deg' attribute controlling degrees of rotation is removed

* rotopoints and rotoedges modified to now accept rotation in radians, these two methods are NO LONGER properties

* a rotate and rotate_ip (in place) method added to rotate the polygon.

* and along with all these changes, some internal changes that do not effect usability or API.

* finally, the raycast.py example modified to showcase the new raycast algorithm and simplify the code. left-right arrows to rotate!

OUTSTANDING

* currently no obvious solution to indicate if a rotation would rotate into or out of a collision when using the raycast method.

Links

Home Page: http://code.google.com/p/pylygon/
Source: http://code.google.com/p/pylygon/downloads/list

Screenshot

click to view original size

Releases

pylygon - 1.3.0rc - Jan 19, 2012
pylygon - 1.2.0rc - Jul 6, 2011
pylygon - 1.0 - Dec 14, 2010

Pygame.org account Comments

If you wish to leave a comment with your pygame.org account, please sign in first.

July 13, 2011 11:19am - Chandler Armstrong - nickname: (omnirizon)
alright then. I can change the naming scheme if that will better accord to convention. the API will not have to change, the __init__ file will simply need to be modified. thanks for the tip on planar. it looks like planar could benefit from the functionality provided by the GJK and GJK-raycast algorithms, but otherwise has all the same features (and much much more) as pylygon. and it is developed by Casey Duncan. my noiselib library was born from his C implementation of Perlin noise.
July 12, 2011 6:53pm - Ken Lauer - nickname: (kne)
I have to agree with Xandar. This is a good start of a library. However, to the majority of those that use Python (at least as I have gleaned from user feedback), ease of use and conformance to accepted standards are almost as important as functionality itself. I would highly recommend renaming classes like 'Main' to be what they actually represent. Similarly, modules with an initial underscore usually indicate that they are compiled C/C++ extensions. (see http://www.python.org/dev/peps/pep-0008/ ). It might just be me, but I like having the examples modify the system path (i.e., add '..' in your case) to find the library so I don't have to install the library just to try the examples out. Have you thought about possibly integrating your ideas with planar ( http://pypi.python.org/pypi/planar/ )? I have yet to see another library do better than it for representing planar objects. And finally, in defense of Box2D, "top-down friction" is possible with the friction joint.
July 12, 2011 12:12pm - Chandler Armstrong - nickname: (omnirizon)
I'm so happy someone else found the code useful! I should have been converting things to ints in the examples, my OS X system give 'deprecation warngings' but I just ignored them. I'll make a minor update and fix that in the examples. The naming convention is a bit indirect but it makes me feel happy. I adopted it because I like each file to be about one thing and that thing is named Main or main. the Polygon object of the polygon file seems redundant to me. I prefer the Main object of the polygon file. I always rename things using the __init__ file so that the API isn't so indirect. I think naming the primary object of each file as 'Main' enforces that each file is about one thing, and stresses that this thing named Main is what that file is about. Your point regarding the terseness of names is well taken. 'centroid' is definitely more descriptive. I like terse names because they often look leaner and less cluttered. I think it is a hard call, but If there is a conventional symbol for a thing, like 'C' for centroid or 'a' for area, I will often use the symbol instead of a more descriptive name.
July 12, 2011 7:44am - Xandar Kablandar - nickname: (eternalcheesecake) - 4/5
Thank you for sharing your code! I think this type of library is a great resource for others. I had a little trouble getting it to run on my Debian/Kubuntu 11.04 system (Python 2.7.1, pygame 1.9.1). When running examples/collidepoly.py for example, I get this error: Traceback (most recent call last): File "c1.py", line 67, in <module> draw.circle(SCREEN, (255, 255, 255), triangle.C, 3) TypeError: integer argument expected, got float I need to add this function: def make_int( t ): return int( t[0] ), int( t[1] ) and change the lines to: draw.circle(SCREEN, (255, 255, 255), make_int( triangle.C ), 3) draw.circle(SCREEN, (255, 255, 255), make_int( rhombus.C ), 3) By the way, I understand that you transcribed the algorithms from another source, but I found some of the naming non-intuitive. Like "C" means "centroid". Well, why not name the function "centroid"? Or "_A" means "area". Similarly for the names of the polygon, line, and convexhull classes all being called Main. I don't understand why they have such an indirect abstraction. Still, this is good, thank you.