-- [ Picked text/plain from multipart/alternative ] I just noticed that HL1 has a TraceSphere function available. Did this function become flawed once the Physics system was entered in the the scene equation? Just wondering why it was removed from HL2.
On Sep 29, 2007 4:50 PM, Daniel Menard <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Not having a method of tracing a VCollide to the world really limits what > we > can do with prediction, especially when talking about vehicles. Since > VPhysics is essentially unpredictable in the networking sense, we can't > run > the collision code client-side (unless we limit ourselves to an AABB, > which > really won't work for proned players, cars, trucks, planes etc..). The > ability to sweep a collidable and implement our own physics in game code > would fix this... There is a SweepCollideable function in the physics > interface, but it is stubbed. > > We've found a happy medium, which is to have predictable simulation code > much like the players and having a Physics Shadow follow the object server > side. This works for flying vehicles (since most of the time they don't > hit > stuff). Any mod working with ground vehicles has a huge problem though, > since they're always colliding. Not predicting vehicles is an option, but > expect your player base to complain about laggy controls... > > On 9/29/07, John Sheu <[EMAIL PROTECTED]> wrote: > > > > Jay Stelly wrote: > > > But it's not a framework that lets you sweep a > > > vcollide against the entire scene - which is probably what you want > (and > > > what John wanted as I recall). In fact it's pretty straightforward to > > > extend vphysics to do this, but the current implementation would be > > > incredibly slow if you used any displacements at all because it would > > > have to consider each triangle separately. > > > > > > > That would be really nice. Or actually, would have been really nice. > > And kinda overdue, since the SDK-side framework is there > > > d) "physics tests only happen once per frame in static positions" - > not > > > exactly sure what you are trying to say here but it sounds incorrect > to > > > me. The movement in vphysics though not described as sweeps/traces is > > > still computed as continuous motion. It's not like all of the objects > > > move and then do a static test to see if they are inside another > object > > > or have passed through another object. The collisions are computed > > > continuously along the path of translation/rotation. It may still be > a > > > pain for your player movement strategy, but it certainly isn't > evaluated > > > in "static positions" if that helps to understand it better. > > > > > > > I realize that VPhysics fundamentally does continuous collisions. I've > > played around some with the Bullet physics library some, and an idea of > > how things work. (Whether this is a correct "idea" or not is another > > question.) What I mean was that from game code, you cannot evaluate > > collisions on a collideable from more than one position in a given > > frame, or move/sweep them during the frame for movement tests. > > > > -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
