I need an OBBxOBB collision algorithm that returns all relevant contacts. I have one that returns one relevant contact and another, hacked-together version that sort-of returns relevant point contacts. However, something complete would be a definite help.
Thanks.
I need an OBBxOBB collision algorithm that returns all relevant contacts
Author
New post edit: By "relevant contacts", I mean one for each corner point in contact and one for each edge in contact with the other object. If either two points or an edge could be returned, one or the other should be chosen.
Continuous/swept is not needed at this point; I haven't gotten that far with my engine.
Continuous/swept is not needed at this point; I haven't gotten that far with my engine.
You did not specify your problem quite well.
What is the exact input and output of the algorithm?
Whatever you really want, it boils down to an intersection problem.
Check this out: http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php?page=5
What is the exact input and output of the algorithm?
Whatever you really want, it boils down to an intersection problem.
Check this out: http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php?page=5
When you say "relevant contacts", the statement is a bit unclear. The intersection of two OBBs can be a point, an edge, a triangle, a polygon, or a (convex closed) polyhedron. What kind of representation of the intersection set are you looking to receive?
In all its genericity, you can get the polyhedron of the intersection by representing the OBBs as plane-bounded-volumes (a list of planes, and a volume is defined by their intersections). Computing the intersection of the OBBs is the same as merging the two lists of planes. To generate the vertices/edges/faces of the intersection volume, convert this plane-bounded-volume to a polyhedron.
Yes, the whole thing will be tons slower than a simple test based on the SAT test or the GJK algorithm. That is why it is often approximated by only reporting a single point of contact, or a list of contact points, if the surface area (volume) of intersection is larger.
In all its genericity, you can get the polyhedron of the intersection by representing the OBBs as plane-bounded-volumes (a list of planes, and a volume is defined by their intersections). Computing the intersection of the OBBs is the same as merging the two lists of planes. To generate the vertices/edges/faces of the intersection volume, convert this plane-bounded-volume to a polyhedron.
Yes, the whole thing will be tons slower than a simple test based on the SAT test or the GJK algorithm. That is why it is often approximated by only reporting a single point of contact, or a list of contact points, if the surface area (volume) of intersection is larger.
Author
@Domii: Input: Two positions, two orientations, two bounding box half-sizes. Output: Zero or more contacts with: A contact point (sufficient to use in "realistic-looking" collision), a contact normal (same) and a contact penetration (yep).
@clb: My second post contains the intersections I'm looking for; this post contains the output.
I've possibly heard of that before, but if so, my knowledge of 3D math was not sufficient to retain it in memory.
For an end goal, I want to generate one or more contacts that, when fed through my collision response, will generate "realistic-looking" collision when fed into my collision response algorithm (in essense, the one from "Game Physics Engine Development", by Ian Millington).
I'm trying to get rid of annoying wobbling. The desired collision algorithm should be a step in the right direction, if my understanding of one of the reasons why it's not working correctly is true.
@clb: My second post contains the intersections I'm looking for; this post contains the output.
I've possibly heard of that before, but if so, my knowledge of 3D math was not sufficient to retain it in memory.
For an end goal, I want to generate one or more contacts that, when fed through my collision response, will generate "realistic-looking" collision when fed into my collision response algorithm (in essense, the one from "Game Physics Engine Development", by Ian Millington).
I'm trying to get rid of annoying wobbling. The desired collision algorithm should be a step in the right direction, if my understanding of one of the reasons why it's not working correctly is true.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
