by John Owen » Thu, 02 Nov 2000 11:05:09
Does anyone know of a document on the web which would explain how to find
this.
BTW - I already have the intersection tests working, but mine can only
determine if they intersect or not.
Thanks.
--
Live Long and Prosper
ICQ - 45835769
by Dave Eberl » Fri, 03 Nov 2000 14:41:33
For OBB-OBB intersection, seeQuote:> I need to find the point of collision between two OBBs and a OBB and a
> plane.
> Does anyone know of a document on the web which would explain how to find
> this.
For OBB-plane, project the OBB onto a normal line to the
plane. The plane projects to a single point. The OBB is
just touching the plane when the projection interval has
the plane projection point as an end point. You can easily
determine which vertex of the OBB generated the
corresponding end point of the projection interval.
--
Dave Eberly
http://www.magic-software.com
by John Owen » Sun, 05 Nov 2000 04:00:00
Thanks Dave. Makes sense.Quote:> For OBB-OBB intersection, see
> http://www.magic-software.com/Documentation/dynacoll.pdf
> For OBB-plane, project the OBB onto a normal line to the
> plane. The plane projects to a single point. The OBB is
> just touching the plane when the projection interval has
> the plane projection point as an end point. You can easily
> determine which vertex of the OBB generated the
> corresponding end point of the projection interval.
However that depends on the box not moving very far "into" the plane
(without modification).
But it is processor efficient :-)
--
Live Long and Prosper
ICQ - 45835769
by Dave Eberl » Mon, 06 Nov 2000 04:00:00
What I described is for a static OBB. For a moving OBB, youQuote:> > For OBB-plane, project the OBB onto a normal line to the
> > plane. The plane projects to a single point. The OBB is
> > just touching the plane when the projection interval has
> > the plane projection point as an end point. You can easily
> > determine which vertex of the OBB generated the
> > corresponding end point of the projection interval.
> However that depends on the box not moving very far "into" the plane
> (without modification).
--
Dave Eberly
http://www.magic-software.com
by John Owen » Tue, 07 Nov 2000 04:00:00
--
Live Long and Prosper
ICQ - 45835769
> > However that depends on the box not moving very far "into" the plane
> > (without modification).
> What I described is for a static OBB. For a moving OBB, you
> can compute the projection interval as a function of time. If
> the time interval over which you want to detect collisions is
> [0,T], then you can look at the projection interval at t = 0 and
> determine on which side of that interval the projected plane
> point is. At time t = T, it is possible that the OBB and plane
> are still separated, but you can test if the projected plane
> point is now on the *other side* of the projected interval for
> the OBB. If this is the case, then the OBB must have passed
> through the plane during the time interval. If you want first
> time of contact, you can determine that by computing the time
> when the plane projection point is one of the end points of
> the projected interval for OBB. Just linear equations in t to
> solve.
> --
> Dave Eberly
> http://www.magic-software.com
1. 3D collision detection using collision map
Hi, I have read an article on the web (I forgot where it is) about using
collision map for pixel-accurate 2D collision detection - the basic idea is
to bitwise AND the maps to find any non-zero bits.
Is it plausible to apply similar techniques for 3D collision detection?
My idea is to flatly project the objects onto the XY, YZ and XZ planes
respectively, and see if all of the 2D maps collide.
Have anyone thought about this? Does it sound like a slow algorithm for
an OpenGL game?
Thanks in advance,
Mike
2. Upgrading Irix and Wavefront
3. collision detection - contact points
5. Collision points with SOLID
6. Color depths
7. Get the point of Collision between 2 3d objects
10. fastest polygon union of OBBs?
11. Collision Normal and Point
12. Collision point and normal