[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: linuxgames@sunsite.dk*Subject*: Re: Triangle-Triangle Intersection Tests*From*: "Miguel A. Osorio" <maos@gbl.com.br>*Date*: Wed, 12 Feb 2003 10:55:21 -0200*Delivered-to*: archiver@seul.org*Delivered-to*: mailing list linuxgames@sunsite.dk*Delivery-date*: Wed, 12 Feb 2003 09:39:48 -0500*Mailing-list*: contact linuxgames-help@sunsite.dk; run by ezmlm*References*: <20030202143627.71FA3E43A@whouse.4orsi.it> <3E3D304A.90204@airmail.net> <20030202151533.4A655E43A@whouse.4orsi.it> <3E3D450E.3050501@airmail.net> <3E481ACA.C89B4715@gbl.com.br> <3E491CD4.7010409@gmx.de>*Reply-to*: linuxgames@sunsite.dk*Sender*: hornet@seul.org

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.

**References**:**3d graphics***From:*"Francesco Orsenigo, Xarvh Project" <xarvh@lombardiacom.it>

**Re: 3d graphics***From:*Steve Baker <sjbaker1@airmail.net>

**Re: 3d graphics***From:*"Francesco Orsenigo, Xarvh Project" <xarvh@lombardiacom.it>

**Re: 3d graphics***From:*Steve Baker <sjbaker1@airmail.net>

**Triangle-Triangle Intersection Tests***From:*"Miguel A. Osorio" <maos@gbl.com.br>

**Re: Triangle-Triangle Intersection Tests***From:*Gregor Mückl <GregorMueckl@gmx.de>

- Prev by Date:
**Re: OpenGL question** - Next by Date:
**Re: Triangle-Triangle Intersection Tests** - Previous by thread:
**Re: Triangle-Triangle Intersection Tests** - Next by thread:
**Re: Triangle-Triangle Intersection Tests** - Index(es):