Re: Kinematic Collision
"Pierre Terdiman \(GMail\)" <[email protected]>
| Newsgroups | gmane.games.devel.algorithms |
|---|---|
| Message-ID | <[email protected]> |
(for some reasons I don't receive my posts to the list, but they still seem to go through. Weird.) > It can happen for many reasons; our constraint solver runs for a fixed > number of iterations, so it can terminate without fully resolving - stacks > of objects will sink into each other over time, and the penetration vector > is essential for resolving this. Also we have lots of motored joints like > pistons etc which can force objects through each other. ...but you are talking about a physics engine here. I was only talking about an old-style "character controller", a.k.a. collide-and-slide, à la Paul Nettle / Quake / etc. Typical "modern" physics engines certainly need penetration vectors. Character controllers, not necessarily - you can go a long way without. > If you code the collision routines carefully, you should be able to pull > out the penetration info at the same time as finding the TOI... Can you give more details here? I think you can find "a" penetration vector -in the direction of motion-, yes, but it is vastly different from "the" penetration vector, a.k.a. MTD, which can be in a completely different direction. I don't think I know a way to compute both with the same piece of code. - Pierre ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ GDAlgorithms-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list