> 5) 12 axes that are orthogonal to each edge of box and=20
> cylinder's top circle edge
> 6) 12 axes that are orthogonal to each edge of box and=20
> cylinder's bottom circle edge
Alen,
As usual very interesting to hear your angle on this!=20
24 seems like such a large number! I have to admit I would have probably =
stopped after the first seven in your list :)
So are you picking the normal to each circle at the point (on the =
circle) that is closest to that edge?
=09
ie. p =3D circlePointClosest(edge, circle)
n =3D grad(circle(p))
testaxis =3D cross(n, edge)
Bob.
> -----Original Message-----
> From: Alen Ladavac [mailto:alen-gdalgs@...]
> Sent: 18 July 2003 09:05
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] seperating axes with cylinders
>=20
>=20
> Generally, when we were designing our separating-axis=20
> colliders, we were following this idea: You
> need one separating axis for each possible pair of closest=20
> features (all combinations of
> vertex-vertex, vertex-face, etc). Canonically, for box-box,=20
> each box has 6 faces, 12 edges and 8
> vertices, it would give you (6+12+8)^2=3D676 combinations. In=20
> most cases, a lot of combinations are
> usually represented by the same axis. E.g, one axis of box A=20
> handles separation of its two faces
> against all other features on box B. That's why the box-box=20
> collider ends up with only 15 axis.
>=20
> For cylinder-box, there are 6 box faces, 12 box edges, 8 box=20
> vertices, 2 cylinder flat surfaces (top
> and bottom), 1 cylinder shell (is this the right word for the=20
> curved surface on the cylinder?) and 2
> cylinder's circle edges (the sharp helix along the end of the=20
> cylinder shell).
> That would give (6+12+8)*(2+1+2)=3D130 axes. Unfortunately,=20
> these don't merge as easily as box-box, so
> we actually have 39 (!) axes. The 24 axes I mentioned in the=20
> post you refer to, are just that last
> 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me.
>=20
> Here's the whole set:
> 1) 3 box axes - they handle box faces against all cylinder features,
> 2) 1 cylinder axis - handles the top and bottom ends of the=20
> cylinder against all box features,
> 3) 3 cross products of cylinder axis with box axes - they=20
> handle cylinder shell against box edges
> 4) 8 axis through the box vertices orthogonal to cylinder=20
> axis - handle vertices against the
> cylinder shell
> 5) 12 axes that are orthogonal to each edge of box and=20
> cylinder's top circle edge
> 6) 12 axes that are orthogonal to each edge of box and=20
> cylinder's bottom circle edge
>=20
> This uses only projection onto axes, and there is no=20
> numerical root finding involved - the solution
> is completely analytical.
>=20
> The axes in 5) and 6) are a bit more complicated to derive=20
> than the others, but not nearly as hard
> to understand as the root-finding methods proposed in the=20
> paper from MagicSoftware website (all
> praises to Mr. Eberly, as I honor his work a lot, but some=20
> parts are just too complicated for
> something I'd have in my collider's inner loop :)). All other=20
> axes are simple and straight forward.
>=20
> I don't claim to have a mathematical proof of the correctness=20
> of the method, or to say that it is
> faster than numerical methods. But it certainly works for us=20
> so far, it is _very_ simple to
> implement, works in constant bounded time, and offers a lot=20
> of early-outs.
>=20
> Also, there is a great potential in quickly discarding most=20
> of the axes in 4), 5) and 6). I believe
> that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are=20
> relevant. But it will need to wait
> until this starts choking on some more complex scenes, so we=20
> are forced to devote time to optimizing
> it. :)
>=20
> If anyone finds a problem with this, or sees some=20
> optimization, please do let me know. I plan to
> make a document explaining all the colliders we use (sphere,=20
> box, capsule, cylinder, mesh), together
> with the actual contact point and penetration depth=20
> computations. I'd like to have that public so
> that it can be verified, and also to help putting an end to=20
> this never-ending secrecy around simple
> and robust collision detection methods. Unfortunately, I=20
> don't have that much spare time right now,
> so I'll just resort to short (?) discussions like this.
>=20
> Alen
>=20
>=20
>=20
> ----- Original Message -----
> From: metanet metanet
> To: gdalgorithms-list@...
> Sent: Thursday, July 17, 2003 7:00 PM
> Subject: [Algorithms] seperating axes with cylinders
>=20
>=20
> hi,
> i'm currently trying to find all seperating axes that need to=20
> be checked for box-cylinder
> intersection.
>=20
> in a previous thread, it was stated that there are=20
> (allagedly) 24 axes to test. a magicsoftware .pdf
> was linked to, but not only is it a bit over my head, it=20
> requires projection on to planes as well as
> axes.
>=20
> is there a projection-onto-axes-only method? and if so, any=20
> hints as to what the 24 axes are? i've
> only found about 10.
>=20
>=20
> thanks,
> raigan
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a=20
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188
>=20
|