I'm coding a physical simulation and after having done the dynamical parts I would like to use some geometric tools to analyze my system. These interesting parts are several clusters of points forming different closed loops (or polygons). The way I parameterized makes it really difficult (at least for me) to separate these loops one from each other. I'm pretty confident about using the boost geometry library for the geometric manipulation of this data, and that's why I'm thinking about sending all these points forming polygons in one boost geometry object (or vector of points simply) and I'm looking for a way of separating them after that using the fact that points too far apart can't be part of the same polygon and then forming several polygons I will manipulate separately.
I haven't manipulated much of boost geometry so far, and I don't know how easy/difficult it can be to implement something like that within it. Are there some default functions that could be of good use in these tasks.
I'm giving you a picture of what I'd like my program to do:
You can triangulate the points and remove the longest edges. I use it for my concave hull algorithm: http://www.phpdevpad.de/geofence.
Related
Setup
Function will need to provide the distance from a point to the closest edge of a polygon
Point is known to be inside of the polygon
Polygon can be convex or concave
Many points (millions) will need to be tested
Many separate polygons (dozens) will need to be ran through the function per point
Precalculated and persistently stored data structures are an option.
The final search function will be in C++
For the function implementation, I know a simple method would be to test the distance to all segments of the polygon using standard distance to line segment formulas. This option would be fairly slow at scale and I am confident there should be a better option.
My gut instinct is that there should be some very fast known algorithms for this type of function that would have been implemented in a game engine, but I'm not sure where to look.
I've found a reference for storing line segments in a quadtree, which would provide for very rapid searching and I think it could be used for my purpose to quickly narrow down which segment to look at as the closest segment and then would only need to calculate the distance to one line segment.
https://people.cs.vt.edu/~shaffer/Papers/SametCVPR85.pdf
I've not been able to locate any code examples for how this would work. I don't mind implementing algorithms from scratch, but don't see the point in doing so if a working, tested code base exists.
I've been looking at a couple quadtree implementations and I think the way it would work is to create a quadtree per polygon and insert each polygon's line segments with a bounding box into the quadtree for that polygon.
The "query" portion of the function I would be making would then consist of creating a point as a very small bounding box, which would then be used to search against the quadtree structure, which would then find only the very closest portions of the polygon.
http://www.codeproject.com/Articles/30535/A-Simple-QuadTree-Implementation-in-C
and
https://github.com/Esri/geometry-api-java/blob/master/src/main/java/com/esri/core/geometry/QuadTree.java
My real question would be, does this seem like a sound approach for a fast search time function?
Is there something that would work faster?
EDIT:
I've been looking around and found some issues with using a quadtree. The way quadtrees work is good for collision detection, but isn't setup to allow for efficient nearest neighbor searching.
https://gamedev.stackexchange.com/questions/14373/in-2d-how-do-i-efficiently-find-the-nearest-object-to-a-point
R-Trees look to be a better option.
https://en.wikipedia.org/wiki/R-tree
and
efficient way to handle 2d line segments
Based on those posts, R-trees look like the winner. Also handy to see that C++ Boost already has them implemented. This looks close enough to what I was planning on doing that I'll go ahead and implement it and verify the results.
EDIT:
Since i have implemented an PMR quadtree, I see now, that the nearest neighbour search is a bit more complex than I described.
If the quad search result for the search point would be empty then it gets more complex.
I remeber a description somewhere in Hannan Sammets:Multidimensional search structure.
Giving the answer below I had in mind searching for all objects withing a specified distance. This is easy for the PMR quadtree, but just finding the closest is more complex.
Edit End
I would not use a R-Tree.
The weak point (and the strong point!) on R-trees is the separation of the space into rectangles.
There are three algorithms known to do that separation but none is well suited for all situations.
R-trees are really complex to implement.
Why then do it? Just because R-Trees can be twice fast than a quad tree when perfectly implemented. The speed difference between a quadtree and a R-Tree is not relevant. The monetary difference is. (If you have working code for both I would use the PMR quadtree, if you have only code for the R-Tree then use that, If you have none use the PMR Quadtree)
Quad trees (PMR) always work, and they are simple to implement.
Using the PMR quad tree, you just find all segments related to the search point. The result will be a few segments, then you just check them and ready you are.
People that tell quad trees are not suited or neighbour search, do not know that there are hundreds of different quad trees. The non suitability is just true for a point quad tree, not for the PMR one, which stores bounding boxes.
I once remebered the compelx description of finding the neighbour points in a POINT-Quadtree. For the PMR-quadtree I had nothing to do (for a search within a specified rectangular interval), no code change, Just iterate the result and find the closest.
I think that there are even better solutions than Quad tree or R-Tree for your spefic questions, but the point is that the PMR always work. Just implement it one time and use if for all spatial searches.
Since there are so many more points to test than polygons, you could consider doing some fairly extensive pre-processing of the polygons in order to accelerate the average number of tests to find the nearest line segment per point.
Consider an approach like this (assumes polygons have no holes):
Walk the edges of the polygon and define line segments along each equidistant line
Test which side of the line segment a point is to restrict the potential set of closest line segments
Build an arithmetic coding tree with each test weighted by the amount of space that is culled by the half-space of the line segment. this should give good average performance in determining the closest segment for a point and open up the possibility of parallel testing over multiple points at once.
This diagram should illustrate the concept. The blue lines define the polygon and the red lines are the equidistant lines.
Notice that needing to support concave polygons greatly increase the complexity, as illustrated by the 6-7-8 region. Concave regions mean that the line segments that extend to infinity may be defined by vertices that are arbitrarily far apart.
You could decompose this problem by fitting a convex hull to the polygon and then doing a fast, convex test for most points and only doing additional work on points that are within the "region of influence" of the concave region, but I am not sure if there is a fast way to calculate that test.
I am not sure how great the quadtree algorithm you posed would be, so I will let someone else comment on that, but I had a thought on something that might be fast and robust.
My thought is you could represent a polygon by a KD-Tree (assuming the vertices are static in time) and then find the nearest two vertices, doing a nearest 2 neighbor search, to whatever the point is that lies in this polygon. These two vertices should be the ones that create the nearest line segment, regardless of convexity, if my thinking is correct.
I need to generate an isosurface from chunks of voxels in an octree or array that supports both rounded and sharp geometry. I have searched for algorithms that seem to be capable of completing this task and found several, including Dual Contouring, Extended Marching Cubes and Dual Marching Cubes. The first two however, require Hermite data that seems like a massive memory drain. In addition, I can't find the actual algorithm for any of these, only equations from journals and vague descriptions. Any help to find an algorithm that will solve my problem would be very appreciated.
The ones you have mentioned are the most prominent ones.
However keep in mind that they have some limitations too:
Extended Marching Cubes (EMC) - preserves sharp features by taking into account the sample normals (and thus gradients of the normals), this method however is still not topologically consistent (homeomorphic), it doesn't allow adaptive refinement (simplification of the mesh) and has inter-cell dependency (due to the edge flipping process; which wont allow for an eventual GPU acceleration).
Dual Contouring (DC) - preserves sharp features and could be adaptively refined, but has inter-cell dependency, and also produces non-manifold meshes.
Dual Marching Cubes (DMC) - preserves sharp features, and produces manifold meshes (dealing with ambiguities), also allows for adaptive refinement, however still suffers from inter-cell dependency (due to it's dual nature) and also wont be as accurate, due to it's sliver elimination process, which rounds up the vertices (error might be negligible)
There are other possible combinations of these, as well as completely different techniques, I believe. Nevertheless I suggest you have a look at Cubical Marching Squares (CMS). I am currently trying to get my head around it as I was hoping to implement it. There are not too many implementations online for it. However it still works with Hermite Data (which was concerning you as far as I could tell).
I'm working in C++ with large voxel grids in a scientific context and I'm trying to decide, which library to use. Only a fraction of the voxel grid holds values - but might be several per voxel (e.g. struct), which are determined by raytracing. I'm not trying to render anything, but I have to determine the potential number of rays passing though the entire target area, thus an awful lot of ray-box computations will have to be caluculated and preferebly very fast...
So far, I found
OpenVDB http://www.openvdb.org/
Field3d http://sites.google.com/site/field3d/
The latter appeals a bit more, because it seems simpler/easier to use.
My question is: Which of them would be more suited if put to use in tasks, which are not aimed at rendering/visualization? Which one is faster/better when computing a lot of ray-box-intersections (no viewpoint-dependent culling possible)? Suggestions, anyone?
In any case, I want to use an existing C++ library and not write a kdTree/Octree etc. myself. Don't have the time for inventing the wheel anew.
I would advise
OpenSceneGraph
Ogre3D
VTK
I have personally used the first two. However, VTK is also a popular alternative. All three of them support voxel based rendering.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
A simple algorithm for polygon intersection
I'm looking for an outline on how to quickly calculate the intersection of two arbitrarily oriented quadrilaterals (no preset corner angle or side length constraints). I am not looking to simply check whether they intersect, but wish to get the points making up the resulting intersecting region. I know that in general polygon intersection isn't a trivial problem and there are libraries available that do a good job.
But since in this special case where I'm only concerned with four sided shapes, I was wondering if there was a quick method I could use without including an entire additional library in my application.
So far all I've thought of is:
Run 'point in polygon' on both shapes with respect to each other
Intersect each edge of each polygon with each other
Do the above two steps definitively get me all the points that make up the resulting intersection region? Is there a better method to use?
Also it would be nice if I could get the correct ordering of the points that make up the resulting region. It's not mandatory -- if you are aware of any clever/quick ways of doing this bit (convex hull?) I'd appreciate any suggestions.
You didn't state wether the 2 quadriliterals are convex or not; if they are, you could use a regular convex polygon intersection algorithm such as http://www.iro.umontreal.ca/~plante/compGeom/algorithm.html
From what I can gather, it doesn't require any exotic datastructures or operations, so it shouldn't be difficult to implement.
Intersection of convex polygons is relatively easy. Google it, there's a lot of resources both on SO and elsewhere.
Not all quadrilaterals are convex though. Intersection of two non-convex quadrilaterals can result in several disconnected polygons, having just their points will give you very little, but if that's what you need go ahead and intersect each pair of edges. It will be much easier and faster than any general method
Even for convex shapes, the dumb brute-force method may be faster. You have to do some testing to find out what works best for you.
I searched and I found some tutorials how to do terrain collision but they were using .raw files, I'm using .x. But, I think i can do same thing they did. They took x,y,z values of an object can checked it against every single triangle in the terrain. It makes sense but It look like it will be slow. It is just like picking checking against every single triangle is slow.
Is there faster way to do it and good?
UPDATE
My terrain is not flat, if it was i would use bounding boxes.
Last time I did this, I used the Bullet library, and it worked great. It has various collision shapes to choose from, optimised for different scenarios, including general triangle meshes and heightfields. You can use the library's collision routines without the physics.
One common way to significantly reduce the time it takes to detect collisions is to organize the space into an octree, which will allow you to very quickly determine whether or not a collision could occur in a particular node. Generally speaking, it's easier to accomplish these sorts of tasks with a game engine.