## RE: [Algorithms] Box<>Tri(Mesh) contact filtering

 RE: [Algorithms] Box<>Tri(Mesh) contact filtering From: Bob Dowland - 2004-04-30 11:56:01 ```Hi Alen, I begin to wonder if we should take this conversation off-list as it = doesn't seem to be generating a whole lot of interest. I also feel that = I'm scratching around for ideas at the moment rather than offering = anything of general interest. Anyways... I should answer some of these = points in the meantime. > What exactly would classify as coplanar contact points? You=20 > can't remove any of four points if box lies on a plane, e.g., right? I'm proposing a slightly more restrictive definition of coplanar by = saying that two box-tri contacts are "coplanar" if the respective tris = are coplanar. Examples would be two contacts on the same tri or two = contacts on different tris which are coplanar with eachother. Because = tris are clipped to the interior of boxes this definition should always = give points that satisfy the usual one but not necessarily vice versa. = The intention is to find a way to group contacts that helps to recover = some of the high-level structure of the mesh. > >contacts" can be dumped with impunity. for eg below >=20 > Is this also not a finished sentence? No, I was refering to the convex hull idea as an eg of a way/situ in = which contacts can be discarded. > that would be an excellent great simplification. sadly not mine - :) > >the whole lot can be discarded and the contact can be recomputed as a > >box<>plane contact. >=20 > But, you cannot really do that with one contact. Can you? It=20 > would need at > least 4 points to balance the box properly. Yes - if the box is just sitting there, but there could of course be = less than four points depending on the sort of contact eg. an impact = might just be one, a deep impact might yeild three(?). Again I'm really = just trying to find ways to infer high-level mesh structure. > What with penetration? As you pointed out before you can get sep norms that are artefactual (if = this is a word) in that they arise becase of the per-tri cd approach - = usually least penetrated direction is the normal right? Our penetration = values are dependent on the sep norm choice, if we change the one = (because we deduced that it was nonsense in the given context) then we = need to consider changing the other. > Btw, this still doesn't tack the problem at edges, does it? :/ Errhh, no.. although aspects of these ideas may help. Here's what I mean = - at a shared edge we get one of these screwy edge contacts because on = one side of the edge we're sitting on the flat of the tri, on the other = we're just touching it's edge. In our contact set there exist two = "coplanar" (in the above sense) contacts with points very close together = (spatially) but with sep norms that don't agree. If one of the contacts = is from the "good side" it will have sep norm parallel to tri norm and = only the other will have the edge direction sep norm. Now I've not fully = tested this but I'd say that is enough to eliminate srewy edge contacts = in this kind of scenario. Can you think of any cases that might be = missed or result in falsely discarded info from such a scheme? Bob. > -----Original Message----- > From: Alen Ladavac [mailto:alenl-ml@...] > Sent: 29 April 2004 17:13 > To: gdalgorithms-list@... > Subject: Re: [Algorithms] Box<>Tri(Mesh) contact filtering >=20 >=20 > > 1 eliminate duplicates: > [snip] > > So this is a no brainer. >=20 > Agreed. >=20 > > 2 identify coplanar contact points: >=20 > What exactly would classify as coplanar contact points? You=20 > can't remove any > of four points if box lies on a plane, e.g., right? >=20 > >this can be done quite cheaply as we keep both tri and sep=20 > normals in a > >box-tri contact: the trinormal and the sep normal. If one is=20 > careful with > >how the trinorm is calc'd then it should be possible to rely on > >Dot(tri.norm, tripoint) as a measure of coplanarity -=20 > certain "coplanar > >contacts" can be dumped with impunity. for eg below >=20 > Is this also not a finished sentence? >=20 > > 3 convex hull points: > Clearly one can compute a 2D convex hull of the contacts=20 > (once grouped as in > 2) and at least in some cases discard everything except those=20 > hull points. >=20 > Yes, that would be an excellent great simplification. Speedup might be > questionable, but stability could be improved a bit with it. Perhaps. >=20 > >on a good day (not always) this will make a contact set with=20 > an unequivocal > >separating plane. If the convex hull contains only box=20 > surface points then > >the whole lot can be discarded and the contact can be recomputed as a > >box<>plane contact. >=20 > But, you cannot really do that with one contact. Can you? It=20 > would need at > least 4 points to balance the box properly. >=20 > >These are the sort of avenues I've been exploring, but there=20 > are lots of > >gotchas - penetration is one area that needs to be=20 > addressed. In general I > >think one can get away with a pretty redundant contact set=20 > (depending on > >solution method) but once you start filtering a lot of=20 > special cases can > >start being missed - so on a general note as is often the=20 > case the less one > >can get away with, the better. >=20 > What with penetration? >=20 > Btw, this still doesn't tack the problem at edges, does it? :/ >=20 > Alen >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market...=20 > Oracle 10g.=20 > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > 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 ********************************************************************** The information contained in this email and its attachments is confidential. It is intended only for the named addressees=20 and may not be disclosed to anyone else without consent from Blue 52 Games Limited. Blue 52 give no warranty that this email=20 message (including any attachments to it) is free of any virus=20 or other harmful matter and accepts no responsibility for any=20 loss or damage resulting from the recipient receiving, opening or using it.=20 ********************************************************************** ```