Recommended Posts

Find it here. In short, it works most of the time, but in some cases where the polygon cuts the cube near its corner (it seems to me, this only happens when the cube contains a portion of an edge, but only in some cases - yes I've pentuple checked the segment_intersects_cube() routine :)*), it fails.
* edit: ack! - just noticed a case where it also fails when a polygon slices through the cube, but none of the actual edges are involved.
I have been going over this code for almost three hours now: I'm fairly sure my input is correct and that I've made no mistakes adapting it. Just to be sure, however, here's the adapted version (comments removed):

I'm sure people have used this code before and I'm sure in its original form it works correctly, but I'm failing to see where I'm going wrong here. So, if anyone has an idea or can spot a mistake, I'd appreciate it a lot :)

Share this post

Link to post

Share on other sites

Is there a better test you have in mind? I'm all ears :). This test is cheap becuase I can optimize my code to produce unit size octree nodes at leaves, which means I only have to translate the polygons by the node's origin to do the test (eg no scaling involved).

If there's a better way out there, I'd love to hear about it, though. I tried to tackle this using my own brain, but all the various cases and tests got pretty expensive pretty fast.

Share this post

Link to post

Share on other sites

note that this is the unoptimised version. IF you do for example axis aligned boxes and triangles, you can reduce the maths, branching, ect to something much faster (although the raw test is plenty fast to start with).

The principle of their algorithm is the same, except optimised for speed.

If you have polygons and not triangles, I'd consider reducing your polygons into triangles and using the moller test.

Dave Eberly has another version of the algorithm, reduced to its minimum components, although the implementation would be more cryptic (since it's an optimised version of the optimised version!).

0

Share this post

Link to post

Share on other sites

Hey - I adapted your code and it works perfectly! Thank you for ending this - I've been stuck on it for ages now :D!

About triangulation - I can't (well, it'd simply be stupid to) do that at this stage, which is why I've been racking my brain over how to do full polygon tests - I need the polygonalized data and it would be far less efficient to start triangulating the geometry at this stage as much of it is temporary and there can be a lot of faces involved in the tests (I'm triangulating as the last stage for rendering only).

Share this post

Link to post

Share on other sites

Thanks for the warning - this might have ended up being a bit of a surprise as there's no guarantee that I'll only be dealing with convex polygons.

Incidentally, will the code fail or simply produce unexpected output if I pass a concave polygon to it? A vast majority of my geometry is convex (I'd say 99.9%), but since I'll be running CSG passes over it repeatedly, there's a chance that it might produce concave results at one point or another. I'd be willing to settle with assuming a very small error margin for the time being if there's a good chance the collision will handled correctly.

0

Share this post

Link to post

Share on other sites

Undefined results. However, if you can use the convex hull (the convex polygon around your concave polygon, should be relatively easy to compute), that would work. Of course, tessellation or triangulation will work better.

OpenGL has some utility libraries to tessellate polygons, if that's any help. Tessellation is not easy, however if your polygons are not self intersecting, it shouldn't be difficult to do.

If this real-time or 'cooking' your geometry?

Furthermore, have you considered using a bounding volume of some sort around your polygons for space partitioning? For example, using bounding boxes, or as I said briefly, using the convex hull around your polygon (which would be the polygon itself if it is already convex, or the polygon hull around your polygon vertices, which would be as simple as removing vertices that are creating concave corners). From experience, false positives are not that much of a problem, except for performance, but I think that's a trade off worth considering in your case.

Finally, what about other methods for space-partitioning? I'm quite partial to loose KD-trees from the collision detection stand point.

Also, for the collision tests themselves, convex geometry simplifies things greatly (even though it's not really simple in itself). Concave polygons means you cannot use the SAT and most algorithms discussed everywhere, so I suspect you will have to triangulate / tessellate your polygons anyway.