Re: [hlcoders] Multiplayer Vehicles
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
Re: [hlcoders] Multiplayer Vehicles
-- [ 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
Re: [hlcoders] Multiplayer Vehicles
On Saturday 13 January 2007 3:36 am, Justin Krenz wrote: 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. Roll-your-own broadphase and collide. The broadphase won't be able to handle more than a single ent colliding with the BBox, given that traces only return the single ent hit. (Well, with an iterative procedure and custom tracefilter that iteratively adds each intersecting ent, maybe). I'm also not going to be able to simulate the angles on each collision, as I don't have the worldposition of the intersect point, so I can't apply the correct collision torque. Short of VALVe feeling nice, this might be the only solution though. Unless... (off-list for my insane idea.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Multiplayer Vehicles
I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. The issue is this: for a smooth experience, we need prediction. To do prediction, we need to be able to simulate a vehicle forward multiple timesteps relative to the environment as a whole. For example, when the client copies an authoritative position for some time in the past, the client must be able to simulate the object forward from that position into the present time, while not affecting the world at large. Similarly, when the server receives a collection of user commands, the server must be able to simulate the object forward as many timesteps as there are commands. The player code is able to do this, as the extent of the simulation in the player code consists of some velocity integration combined with BBOX traces nand a whole set of heuristics for game-world permissibility; as the engine exposes facilities to do BBOX traces quite well, simulating multiple commands in a client/server frame is no problem. The shadow controller tied to the player, which interacts with the VPhysics world, does not completely march in lockstep with the player, but lags (at most) close behind. For vehicles, there is no analogous procedure. To simulate vehicles in game code, one would be required to use traces of collision hulls at arbitrary angles (as collision models for vehicles generally cannot be simplified to the BBOX that serves the player rather well). Unfortunately, no such facility exists. If one were to attempt to do this in VPhysics, one could use a motion controller, but the motion controller can only integrate a single command per world timestep; this does not fit the requirements for client prediction, or multi-command server simulation. So the solution that I see is that a facility be opened in the VPhysics interface that allows the simulation of any one arbitrary IPhysicsObject (and any associated shadow controllers/motion controllers) by one timestep, leaving the rest of the world that does not interact with this object alone. In essence, putting all objects except one to sleep, then simulating the world by one timestep, but done more efficiently. As fundamentally, a physics engine must simulate its objects serially, I believe that this is possible. I don't know Havok, though, so I won't know if that's actually true. I would, however, respectfully ask that VALVe look into the possibility. As far as I know, in the land of predicted multiplayer Source vehicles, Krenzo went with client-side authoritative vehicle physics for Empiresmod (with some server-side checking). HLRally gave up. I'll see what Eternal-Silence can come up with. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] This is the reason I made my vehicles purely out of SOLID_BBOX. I was able to reduce cpu load from physics by ALOT and was able to have great prediction. On top of that, I controled my movements with 100% precision. Only downside was I had to fake my Angles to orient to the ground correctly, and fake the z Origin to have the vehicle lay flat on the ground instead of floating, this was done all clientside though, so no extra load on the servers. Overall, I'm satisfied to say people will be happy with the vehicles in our mod. It only works out great for my mod because realism rules don't apply to the gameplay design. For realistic vehicles it would not work at all due to the bounding box not being able to rotate, so you'll have square cars! I surely hope we get either better precision control over physics or bring in SOLID_OBB for all us hardcore coders to have fun with. On 1/12/07, John Sheu [EMAIL PROTECTED] wrote: I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. The issue is this: for a smooth experience, we need prediction. To do prediction, we need to be able to simulate a vehicle forward multiple timesteps relative to the environment as a whole. For example, when the client copies an authoritative position for some time in the past, the client must be able to simulate the object forward from that position into the present time, while not affecting the world at large. Similarly, when the server receives a collection of user commands, the server must be able to simulate the object forward as many timesteps as there are commands. The player code is able to do this, as the extent of the simulation in the player code consists of some velocity integration combined with BBOX traces nand a whole set of heuristics for game-world permissibility; as the engine exposes facilities to do BBOX traces quite well, simulating multiple commands in a client/server frame is no problem. The shadow controller tied to the player, which interacts with the VPhysics world, does not completely march in lockstep with the player, but lags (at most) close behind. For vehicles, there is no analogous procedure. To simulate vehicles in game code, one would be required to use traces of collision hulls at arbitrary angles (as collision models for vehicles generally cannot be simplified to the BBOX that serves the player rather well). Unfortunately, no such facility exists. If one were to attempt to do this in VPhysics, one could use a motion controller, but the motion controller can only integrate a single command per world timestep; this does not fit the requirements for client prediction, or multi-command server simulation. So the solution that I see is that a facility be opened in the VPhysics interface that allows the simulation of any one arbitrary IPhysicsObject (and any associated shadow controllers/motion controllers) by one timestep, leaving the rest of the world that does not interact with this object alone. In essence, putting all objects except one to sleep, then simulating the world by one timestep, but done more efficiently. As fundamentally, a physics engine must simulate its objects serially, I believe that this is possible. I don't know Havok, though, so I won't know if that's actually true. I would, however, respectfully ask that VALVe look into the possibility. As far as I know, in the land of predicted multiplayer Source vehicles, Krenzo went with client-side authoritative vehicle physics for Empiresmod (with some server-side checking). HLRally gave up. I'll see what Eternal-Silence can come up with. -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
Re: [hlcoders] Multiplayer Vehicles
I remember Valve said Havok doesn't want their code opened in the SDK at all, so I doubt Valve wants to start opening anything up in the VPhysics interface to get the functionality you want. I chose client-side vehicles because it's the fastest solution. You just move the vehicle code client-side, add some checks on the server, and you're done. If you really want client-side prediction of vehicles, you could code your own physics. That's what I did for aircraft. It's not as hard as you would think, but that's time that could be spent elsewhere. The bigger disadvantage is that the load still exists on the server. Once you start running out of cpu cycles with higher player counts, you'll start thinking about moving stuff to the client and appreciate client-side vehicles. What caused you to bring this topic up? Are you redoing your spacecraft movement? I thought you had prediction, albeit not a very elegant solution programmatically, but if it's not broken, why fix it? John Sheu wrote: I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. ... As far as I know, in the land of predicted multiplayer Source vehicles, Krenzo went with client-side authoritative vehicle physics for Empiresmod (with some server-side checking). HLRally gave up. I'll see what Eternal-Silence can come up with. -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
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. On 1/12/07, Justin Krenz [EMAIL PROTECTED] wrote: I remember Valve said Havok doesn't want their code opened in the SDK at all, so I doubt Valve wants to start opening anything up in the VPhysics interface to get the functionality you want. I chose client-side vehicles because it's the fastest solution. You just move the vehicle code client-side, add some checks on the server, and you're done. If you really want client-side prediction of vehicles, you could code your own physics. That's what I did for aircraft. It's not as hard as you would think, but that's time that could be spent elsewhere. The bigger disadvantage is that the load still exists on the server. Once you start running out of cpu cycles with higher player counts, you'll start thinking about moving stuff to the client and appreciate client-side vehicles. What caused you to bring this topic up? Are you redoing your spacecraft movement? I thought you had prediction, albeit not a very elegant solution programmatically, but if it's not broken, why fix it? John Sheu wrote: I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. ... As far as I know, in the land of predicted multiplayer Source vehicles, Krenzo went with client-side authoritative vehicle physics for Empiresmod (with some server-side checking). HLRally gave up. I'll see what Eternal-Silence can come up with. -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
Re: [hlcoders] Multiplayer Vehicles
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. 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? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
I believe someone from Valve mentioned earlier that SweepCollideable() and TraceRay() are currently stub implementations in IPhysicsEnvironment, so they don't do anything meaningful. - Original Message - From: Justin Krenz [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, January 12, 2007 1:34 PM Subject: Re: [hlcoders] Multiplayer Vehicles 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. 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? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ 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
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] That's interesting Krenzo. I will have to check out how PhysShouldCollide works. If it works alright, it could really help with the prediction. At the very least we could implement something like sv_turbophysics. What may be difficult is getting the point of contact. What do you think of that John? On 1/12/07, Justin Krenz [EMAIL PROTECTED] 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. 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? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ 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
Re: [hlcoders] Multiplayer Vehicles
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