Re: Triangle-Triangle Intersection Tests

["Miguel A. Osorio" <maos@gbl.com.br>]

Gregor Mückl wrote:
> >
> Why don't you use one of the collision detection libs that are already
> out there? There's SOLID, RAPID and OpCode to name only a few of them.
> These are highly optimized (and most of them seem to use layered sets of
> algorithms to avoid triangle-triangle-checks on almost every available
> combination).
> 
> Opcode homepage: http://www.codercorner.com/Opcode.htm
> 
> If you follow a few links from there you'll find a lot of algrithms and
> implementations readily available.


	I appreciate your help very much, but using a third-party package is
unfortunately not an option for me. One of the goals of my engine is to
keep the dependencies down to a small bit. This of course takes us down
to the old "re-invent the wheel" kind of stuff, but then again, this
engine I'm coding is what I consider a very good practice of a *lot* of
skills needed to code a decent 3D application, IMHO.
	Anyway, I had an idea just a few minutes ago of how to solve this
problem. I'm thinking of mixing OBB trees and Octrees for the case of
collision detection. You see, in our case, the modelers build the OBB
hierarchy in the 3D modeling app, and the tree can be of any complexity,
but it sure won't come out *that* complex because it doesn't need to, at
least in the case of using the OBB tree for visibility.
	But given my recent bad experiences with tri-tri intersection tests,
the tree should go a lot deeper than that. I was thinking that we could
use octrees aligned with each individual leaf as deeper structures,
storing smaller and smaller lists of faces, as an alternative to
building the tree as the RAPID package does, for example. What do you
people think of this idea?




Thank you for your attention,
M.