Re: [Algorithms] Kinematic Collision

[Pierre T. \(GMail\) <pie...@gm...>]

(Hi Dave! It's great to hear from you!)

> I found that the most important thing to make this work is a very robust
> sweep test(including hit normal etc). The sweep should also handle
> initial intersection (no matter what you do 8h1t Happens(tm)) giving a
> sensible depenetration vector and a distance to move to depenetrate the
> objects. Pair wise seems good enough, although it would probably be
> possible to make this recursive as well.
>
> Since I added initial penetration handling my controller has not had any
> problems, including moving lifts/platforms.

I suppose it depends on your game. It's true that providing a "depenetration
vector" can be useful, but I found it easier and more robust to just make
sure it's never needed. In my small-game-at-home
(http://www.codercorner.com/blog/?p=355) I more-or-less use the same code as
NxCharacter, and so far it has been robust enough. Granted, I don't have big
needs or requirements out there, but I do have moving platforms :)


> About using the PhysX stuff, I would say the CCD is OK for demo/basic
> use but is probably not modular enough to do something more
> sophisticated (eg Tomb Raider style) it doesnt have the concept of
> states/transitions

I think there is a lot of IK in Tomb Raider that is clearly beyond the scope
of a classic character controller. I would say that states/transitions are
part of an animation engine, it's unrelated to "the CCT". (But maybe we are
not talking about the same things here.). In the game above for example, I
have some small IK, a hell of a lot of "states" and "transitions", and a
"character controller". They all interact with each other, but I would say
they are different things.

In any case if you guys have requests/suggestions about this, what to
improve, what to add, what to do better, etc, feel free to list them here.


> plus it seems too tied to the underlying geometric
> database.

I have to strongly disagree about that one :) It's like the opposite. The
game above uses "NxCharacter" but does *not* use PhysX otherwise. The
character controller logic is the same, but the collision queries are
performed against a completely different database than PhysX.


> Plus I think that handling of initial
> intersection is "undefined". Not sure if this is still the case? (Any
> idea Pierre?)

AFAIK it is still the case, yes. The rationale was that:
- when used correctly (again, see small game above) penetration never
happens
- running an initial overlap check "just in case" seemed too costly

I left the company 2 years ago (although I'm going back now), so take this
with the proverbial grain of salt, things might have changed.

- Pierre