I'm trying to create a method that will take in two arbitrary lists of nodes, for a subject and a clipping polygon, and output either:
a) the area of the overlap
b) a list of nodes for the resulting (clipped) polygon so that I can calculate the area
I've found lots of examples which clip an arbitrary polygon using a rectangular window (which is fairly standard in graphics) but that's not what I need. I understand that it's fairly complex, particularly when you get holes, convex polygons and the like. The only simplifying assumption which I can make is that the arbitrary polygons will not contain any holes.
I'm not at all an expert in this field, so would something like the Sutherland-Hodgman algorithm work? Are there any libraries out there which already do this, or is my best bet to simply implement the algorithm as described in pseudo-code on Wikipedia?
Thanks for the help!
Are there any libraries out there which already do this ...
Polygon clipping is a complex task. I wouldn't recommend trying to do it yourself unless you want to spend many months on it.
Wikipedia lists a number of clipping libraries (and IIRC in that list only Clipper is free for use in commercial applications):
http://en.wikipedia.org/wiki/Boolean_operations_on_polygons#External_links
ps: I admit to a personal bias for Clipper since I'm the author :)
More info here: http://angusj.com/delphi/clipper.php
Sounds like Weiler-Atherton is the one you need:
The algorithm requires polygons to be
clockwise and not reentrant (self
intersecting). The algorithm can
support holes (as counter-clockwise
polygons wholly inside their parent
polygon), but requires additional
algorithms to decide which polygons
are holes.
Your polygons fit those criteria, right?
I don't know about implementations, but it sounds like you would be better off implementing W-A than S-H if either of your polygons could be concave.
Try gpc.
I found that using the JavaGeom library worked very well. It integrates the code from the Java port of GPC (which is no longer available) and thus allows arbitrary polygon operations. Using SimplePolygon2D and Polygon2DUtils.intersection() I was able to get the desired operation.
I've tried a lot of different libraries and the one that worked best was the JTS Topological Suite which is pure Java and LGPL2 licensed.
Related
I'm using Java2D in conjunction with apache batik to draw some fairly large svg images.
So far it is working quite nicely, but i am frustrated with the performance of areas. In particular, i have three things i want to accomplish:
merge a bunch of colliding shapes to one large area
removing a bunch of shapes from one large area
checking for colliding shapes
naively, point 1 and 2 can be accomplished with Area.add and Area.subtract.
This works, but can easily take up to twenty minutes in an average use case.
Point 3 can be accomplished by subtracting the areas from each other and checking the remaing area. Still slow, but can be sped up to be usable by using some prior spatial hashing or something similar.
Is there a better and faster way to merge/subtract Java2D areas?
If not, is there another library which can do this sort of thing faster?
unfortunately, libraries like JOGL or LWJGL do not work on a resolution independent space like svg-paths or the Java2D Paths.
You can try this: AreaX
According to the author:
The AreaX class is intended to achieve exactly the same visual results as the Area class. However several possible optimizations have been carefully implemented to reach those results faster.
I'm hoping for the equivalent of CGAL (in C++)--I want convex partitioning of polygons or at least triangulation. It also has to be free. A previous question suggested JTS, but it doesn't seem to have those functions.
JTS supports delaunay triangulation, but not constrained triangulation (holes):
http://lin-ear-th-inking.blogspot.com/2009/04/delaunay-triangulation-in-jts-111.html
For constrained delaunay triangulation you can use Poly2Tri.
Works quite good, but could not triangulate polygons with holes, where the holes touch the outline or touch another polygon.
At the moment I use the OpenGl Tesselator (glut) with the java wrapper jogl (http://jogamp.org/) for triangulation in java.
You have to implement the correct callbacks and do some fiddling in there.
Neither of them satisfies all (my) needs, but until now I haven't found a better one.
GeoTools has a pretty extensive library of geometry manipulation algorithms, but of course just like JTS it is somewhat GIS-oriented.
http://www.geotools.org/
CGAL has SWIG driven bindings since 2012. 2D conforming triangulation and meshes is part of it. Please visit the github wiki for furhter info's.
You could try GeoLib which is an excellent geometry package.
I'm trying to find out what effects the Photoshop "Poster edges" filter is composed of. It seems it's a combination of edge detection and posterization, but I haven't been able to duplicate it, not even close, with these so I guess I'm missing something. The image below shows the same image before and after the Poster edges filter:
I've tried performing posterization (and quantization) on the image, along with edge detection using Sobel, but apparently Photoshop is doing something different as the results are very different. Basically the posterization looks very different and edges are very weak compared to the photoshop filter.
So does anybody know how the Poster edges filter is implemented, or have any idea what image-processing should be done to achieve the latter image from the former.
Not that it really matters, but I'm using Java, and my image filtering code is based for the most part on the filters found here: http://www.jhlabs.com/ip/filters/index.html
Edit Description of the filter from adobe.com:
Poster Edges Reduces the number of colors in an image (posterizes it) according to the posterization option you set, and finds the edges of the image and draws black lines on them. Large broad areas have simple shading, and fine dark detail is distributed throughout the image.
Regarding the edges: I would assume that Photoshop uses something more sophisticated than a simple derivative filter (like Sobel) for edge detection. There are edge detection algorithms that try to find only "salient" edges, i.e. those that are relevant to human vision, edges a human artist would draw if he does a line sketch. An old and (rather) simple algorithm that goes in this direction (at least a bit) is the Canny edge detector. You should be able to find an implementation of this one. Google for "salient edges" for current research literature, but don't expect implementations or nice pseudocode in research papers.
Regarding posterization: Given their talks at SIGGRAPH, the Adobe guys are very much into bilateral filtering (please Google, I can't link any more), a smoothing technique that preserves important edges. I think if you apply the bilateral filter and posterize afterwards you should come closer to the look you want. Unfortunately, efficiently implementing the bilateral filter is not trivial.
Update for anyone still interested in this topic
The Bilateral filter, which I suggested above, is increasingly replaced with the Guided filter, at least in the Computer Vision community (the graphics people don't seem to have realized the Guided filter yet). The Guided filter achieves similar results, but is much easier to implement efficiently. The exact algorithm for the Guided filter is highly efficient, while efficient Bilateral filtering requires approximations or insanely complicated algorithms.
I suspect you have to do this at several scales, in order to filter the edge response.
Run your edge detection at several levels(scales) of a gaussian smoothed pyramid of the input image [sigma_min, sigma_max]
Then, either sum or select maximum edge magnitudes across scales
Posterize with original image (blend ?)
Copy the original image and then apply a PosterizeFilter. Then apply EdgeFilter, GrayscaleFilter and InvertFilter to the copy. Finally multiply the posterized original with the copy. At that point you should have something close to Poster edges.
I have a set of points that i want to turn into a closed polygon in Java. I'm currently trying to use java.awt.geom.Point2D and java.awt.geom.Area but can't figure out how to turn a group of the points into an Area.
I think I can define a set of Line2Ds based on the points and then add those to the Areas, but that's a lot of work and I'm lazy. So is there an easier way to go.
The problem is I have a list of lat/lon coordinates and want to build up an area that I can use for hit testing.
Non-core Java libraries are a possibility as well.
Update, I looked at using java.awt.Polygon but it only supports ints and I'm operating with doubles for the coordinates.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4077518
Hear that, "customer"? You should be using GeneralPath, even though the absence of Polygon2D since the late 1990s is an obvious monster-truck-sized hole in the API.
If you are actually working with Geodetic lat/lon values, you can actually use OpenMap to do some of this work. I just spent some time using the Geo class in that API to bounce an object around an area defined by a polygon of lat/lon points. There are intersection calls and everything and all of the math is done spherically so that the points are more correct as far as projections go.
The simplest (and laziest) thing to do is to create a bounding box for the points from the maximum and minimum of the X, Y ordinate values.
If you need a closer fit then rather than devise your own algorithm, this might be a good place to start:
What would be a relatively easy algorithm to code in Java for solving a Rubik's cube. Efficiency is also important but a secondary consideration.
Perform random operations until you get the right solution. The easiest algorithm and the least efficient.
The simplest non-trivial algorithm I've found is this one:
http://www.chessandpoker.com/rubiks-cube-solution.html
It doesn't look too hard to code up. The link mentioned in Yannick M.'s answer looks good too, but the solution of 'the cross' step looks like it might be a little more complex to me.
There are a number of open source solver implementations which you might like to take a look at. Here's a Python implementation. This Java applet also includes a solver, and the source code is available. There's also a Javascript solver, also with downloadable source code.
Anthony Gatlin's answer makes an excellent point about the well-suitedness of Prolog for this task. Here's a detailed article about how to write your own Prolog solver. The heuristics it uses are particularly interesting.
Might want to check out: http://peter.stillhq.com/jasmine/rubikscubesolution.html
Has a graphical representation of an algorithm to solve a 3x3x3 Rubik's cube
I understand your question is related to Java, but on a practical note, languages like Prolog are much better suited problems like solving a Rubik's cube. I assume this is probably for a class though and you may have no leeway as to the choice of tool.
You can do it by doing BFS(Breadth-First-Search). I think the implementation is not that hard( It is one of the simplest algorithm under the category of the graph). By doing it with the data structure called queue, what you will really work on is to build a BFS tree and to find a so called shortest path from the given condition to the desire condition. The drawback of this algorithm is that it is not efficient enough( Without any modification, even to solver a 2x2x2 cubic the amount time needed is ~5 minutes). But you can always find some tricks to boost the speed.
To be honest, it is one of the homework of the course called "Introduction of Algorithm" from MIT. Here is the homework's link: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-fall-2011/assignments/MIT6_006F11_ps6.pdf. They have a few libraries to help you to visualize it and to help you avoid unnecessary effort.
For your reference, you can certainly look at this java implementation. -->
Uses two phase algorithm to solve rubik's cube. And have tried this code and it works as well.
One solution is to I guess simultaneously run all possible routes. That does sound stupid but here's the logic - over 99% of possible scrambles will be solvable in under 20 moves. This means that although you cycle through huge numbers of possibilities you are still going to do it eventually. Essentially this would work by having your first step as the scrambled cube. Then you would have new cubes stored in variables for each possible move on that first cube. For each of these new cubes you do the same thing. After each possible move check if it is complete and if so then that is the solution. Here to make sure you have the solution you would need an extra bit of data on each Rubiks cube saying the moves done to get to that stage.