Dave eberly Game Physics book

he uses a time bisection algorithm to find intersections. Basically, if two objects are intersecting more than some epsilon, back up time until the point of original contact.

Using his methods, it does matter if they intersect, since an intersection will throw off the intersection code - objects could become stuck together. It also may jinx the collision response code.

ok, thanks, that's what I though. I'd think the LCP solver should stil be able to apply constraints. I think the non-penetration comes to that. The LCP solver will probably shuffle the objects around ensuring non penetration after that point. I used Math Engine, and it uses a sinple intersect col det, so objects are actually overlapping at the time. And it uses a LCP, so it seems to be all right with that.

And I was wrong. He's got some stuff for broad phase collision detection, and a bit on the BSP stuff. Although with so many partitioning algortihms around (box tree, compression, sphere tree, extruded bsps, plane shifting bsps, heightmap collision), that would probably have extended the book another 200 pages

the joints would have been nice, and it does not seem to be that complicated, once you have a constraint solver already in place. And the friction stuff. I haven't seen much of it, although I'll have another look. Ragdolls, as an example would have probably made a good demo application.

[edited by - oliii on January 14, 2004 3:38:43 PM]

Look for Russ Smith''s chapter in Game Programming Gems 4 (March release this year) for a discussion of formulating constraints. This chapter might be a nice complement to Dave''s discussion of the LCP solver.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Ack. No joints? I was really hoping he''d cover that. Does he mention any constraints at all?

[teamonkey]

there is constraint motion chapter, and a chapter of lagrangian dynamics. Which is a shame, with that material, he could have talked about joint constraints. I don't think it would have been that hard (for him anyway ), to produce an example of say, a robot arm. I think I'll be OK. The book, and Baraff's papers, that should be all I need to know.

EDIT : Actually, constraint are well covered, there is also Linear programming, ect... It's a very good book, covers loads of materials, from matrices and vectors to dynamic collsion detection, but it could have been awesome Maybe the ODE guys should publish a book, they know a thing or two about physics

[edited by - oliii on January 15, 2004 4:46:26 AM]

quote:

---

Original post by teamonkey
Ack. No joints? I was really hoping he''d cover that. Does he mention any constraints at all?

---

Not in terms of implementing joints between bodies etc.

I haven''t read it yet (planning on doing so over the next couple of weeks, since my journey to work involves sitting on a ferry...), but glancing through it I get the impression that it consists of:

1. a very thorough coverage of all the fundamentals - matrices, linear equations, integration, etc

2. Description of _one_ way of implementing a rigid-body physics system

3. Some other stuff (deformable bodies, "physics and shader programs").

Maybe it''s a bit premature to say this (as I''ve only glanced through it so far) but I''m a bit disappointed that there isn''t more about the different ways of implementing physics - bearing in mind this is called "game physics". Going down the LCP route isn''t the only way of doing things, and isn''t always appropriate.

So, I''m sure it''s an excellent book, but suspect it''s probably got a slightly misleading title (like "3D Game Engine Design", which has more to do nuts-n-bolts than design...).

I agree. There is a lot of mathematical background, but not as much practical stuff. But given the current choice of books on game physics, it''s as good as it gets.