-- [ Picked text/plain from multipart/alternative ] That sure is helpful Justin. I think we may be able to hack together something with that. I remember finding an algorithm to compute an AABB from an arbitrary collide that we could trace the hull of to do a broadphase collision. Then we could do it accurately with TestEntityTriggerIntersection_Accurate. I'm not quite sure how performance would be affected, but it could work.
We are also working on a split collision routine which uses two physics objects (with one "tied to" the other) with mutually exclusive collision groups. This would allow players to collide with a 12 or 13 convex model (since these ships can be pretty big) and the world and other ships could collide with a single convex model. It makes the broadphase stage a bit slower, because it is testing double the objects, but it should provide a speed up, especially in tight spots like the hangar. I'm gonna give John a call and see what we can work out with this. We'll keep this discussion open because Multiplayer vehicles of this sort are a big topic. Thanks Justin. On 1/13/07, Justin Krenz <[EMAIL PROTECTED]> wrote: > > Ok, so let me see if I understand you: > > You want vphysics collisions because they're more accurate than OBBs. > You can't predict a vphysics collision because you rely on the vphysics > simulation code which will only tell you of a collision once it's > actually occuring. Is that correct? > > If that is correct, then I suggest you use the OBB trace or an AABB > tracehull to detect if the ship is going to hit something as suggested > already. Now, if it is going to hit an object, then you can perform a > more accurate vphysics collidable trace on it to ensure that it does hit > the more accurate vphysics collision model of the ship. Look in > triggers.cpp line 1716 for an example of how to do this. This would > require you do the same on the client and server and handle everything > about the collision on your own. > > > John Sheu wrote: > > On Friday 12 January 2007 3:34 pm, Justin Krenz wrote: > >> Does "SweepCollideable(...)" not support OBB? I know const.h says > >> SOLID_OBB is not implemented, but from what little I played with it, > >> SweepCollideable seemed to correctly orient the entity's bounding box > >> before doing the trace. > > > > Not sure, but I'm not a fan of BBox collisions. We have this fancy > VPhysics > > doohickey, and so I'd rather get some more accurate collisions out of > it. > > > >> As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject > >> *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the > space > >> ship entity to alert you that a collision is taking place and then > >> override the response (return false, halt its velocity, and create > >> opposing reaction force) to make things "less crazy?" > > > > I have something similar going on in the codebase as it stands, with an > > added "VPhysicsPreCollision" call in the physics code that does some > velocity > > fixups before collisions. Trying to fix it there I think is trying to > fix > > the wrong problem though. > > > > Essentially, when you collide, the player is expecting to be banged > around a > > bit. Going crazy on collision is not very distracting. The problem is > that > > since we cannot predict collisions, I have to switch prediction off on > the > > client whenever we come into physics contact, and only switch it on when > we > > come out. There's a jolt as prediction switches off, another as it > switches > > on, and what's in between is rather laggy. If you want a true smooth > > experience, you're going to have to predict all the time, and that > requires > > more than we currently have in VPhysics. > > > > IIRC turbophysics does well for player interactions against > VPhysics. It does > > little for player interactions against CWorld. Unfortunately, the > latter is > > where most of our interactions lie. > > > > -John Sheu > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
