RE: [hlcoders] Player Physics
All right, I'm going to try to phrase the question in what might be a more intelligent manner. Suppose that I have a physics object, with a physics shadow, whose position I set at ( 0, 0, 0 ) and whose velocity I set as ( 1, 0, 0 ). I then update the shadow twice, first with a target of ( 3, 0, 0 ) with a time-to-arrival of 1 sec., then again with a target of ( 4, 0, 0 ) with a time-to-arrival of 1 sec. The physics system then simulates. Would I be correct in assuming that calling GetPosition and GetVelocity on the physics object now gets me a position of ( 4, 0, 0 ) and a velocity of ( 2, 0, 0 )? The impulse applied, I assume, would be ( 1, 0, 0 ). That is in the case of no collision. In the case of a collision, will the physics object be updated with the "correct" after-collision position/velocity values? I ask because I'm having some trouble with this (obviously), and I'd like to see if I'm using the shadow system correctly. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
Except for, I assume, the "time to target" argument, which is incremented with each call. Correct? Quoting Jay Stelly <[EMAIL PROTECTED]>: > yes > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Thursday, April 06, 2006 10:55 AM > > To: hlcoders@list.valvesoftware.com > > Subject: RE: [hlcoders] Player Physics > > > > So would I be correct in presuming that only the last call to > > Update() on the shadow controller "matters"? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
yes > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, April 06, 2006 10:55 AM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] Player Physics > > So would I be correct in presuming that only the last call to > Update() on the shadow controller "matters"? > > Quoting Jay Stelly <[EMAIL PROTECTED]>: > > There aren't any intermediate states, so there is a loss of > precision > > as the entire movement is linearized per batch of updates (single > > target position). The important difference is that the > velocity and > > error stuff doesn't get aggregated across the batch of user > commands > > so the player doesn't suddenly teleport or move faster. > > > > And yes, the underlying functions still work, but the > controller will > > of course modify the velocity of the object. > > > > Jay > > ___ > 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] Player Physics
So would I be correct in presuming that only the last call to Update() on the shadow controller "matters"? Quoting Jay Stelly <[EMAIL PROTECTED]>: > There aren't any intermediate states, so there is a loss of precision as > the entire movement is linearized per batch of updates (single target > position). The important difference is that the velocity and error > stuff doesn't get aggregated across the batch of user commands so the > player doesn't suddenly teleport or move faster. > > And yes, the underlying functions still work, but the controller will of > course modify the velocity of the object. > > Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
There aren't any intermediate states, so there is a loss of precision as the entire movement is linearized per batch of updates (single target position). The important difference is that the velocity and error stuff doesn't get aggregated across the batch of user commands so the player doesn't suddenly teleport or move faster. And yes, the underlying functions still work, but the controller will of course modify the velocity of the object. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu > Sent: Friday, March 31, 2006 7:59 PM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] Player Physics > > A few more questions: > > So, as I understand it, how the player controller works: > > If there is no backlog of CUserCmds, then the player is > simulated by CGameMovement and VPhysics for one tick, and at > the end of the frame the two are reconciled. > > If there is a backlog of CUserCmds, then the player is > simulated by the CGameMovement as before. The player shadow > is given a set of "intermediate targets" (based on the > positions calculated at the end of every batch of CUserCmds), > and then this is VPhysics-simulated in one frame, but with a > time delta to match the difference between the first > simulated backlogged frame and the last simulated backlogged frame. > > Given that, as said, the player and shadow controllers are > almost identical, I conclude that the shadow controller works > as well by setting a bunch of "intermediate states" and > associating a time with each of them, then simulating it all > in one frame. Is that correct? > > Also, am I right in assuming that the underlying > IPhysicsObject functions still work? (e.g., SetVelocity(), etc.)? > > > ___ > 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] Player Physics
A few more questions: So, as I understand it, how the player controller works: If there is no backlog of CUserCmds, then the player is simulated by CGameMovement and VPhysics for one tick, and at the end of the frame the two are reconciled. If there is a backlog of CUserCmds, then the player is simulated by the CGameMovement as before. The player shadow is given a set of "intermediate targets" (based on the positions calculated at the end of every batch of CUserCmds), and then this is VPhysics-simulated in one frame, but with a time delta to match the difference between the first simulated backlogged frame and the last simulated backlogged frame. Given that, as said, the player and shadow controllers are almost identical, I conclude that the shadow controller works as well by setting a bunch of "intermediate states" and associating a time with each of them, then simulating it all in one frame. Is that correct? Also, am I right in assuming that the underlying IPhysicsObject functions still work? (e.g., SetVelocity(), etc.)? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
On Fri, 2006-03-31 at 18:19 -0800, Jay Stelly wrote: > So reconciliation could mean that the vphysics data is copied over to > the game - which means the original game simulation is replaced with the > physics simulation. It could also mean that the vphysics data is thrown > away, or blended into the result. It's much more correct to say that > the players are always simulated in game code AND vphysics code. Then > the results are selected or blended based on heuristics. Gravity runs > in both simulations - the output position of the game physics provides > the input direction for the vphysics simulator. Perhaps I should have clarified. As I see it, the CGameMovement code computes an end position, given a start position, and feeds that target into the VPhysics system. The VPhysics system then does its best to reach that target. The difference between the VPhysics position and the CGameMovement position is then heuristically reconciled. > The shadow is updated once, but the resulting output target is reached > over some amount of future ticks. That's what I meant; perhaps I should have said that explicitly. > Player and shadow controllers are nearly identical. The idea is to > solve an overdetermined system for impulses that will cause the physics > object to arrive at the target position & orientation at some point in > the future (usually the beginning of the next tick). Vehicle > controllers include a vehicle suspension, steering, and engine model - > and are generally forward controllers (you give them input and they > generate physics, they don't solve for impulses). > > Motion controllers are just generic hooks to let you introduce your own > impulses to the object at the time that it is integrated. You implement > IMotionEvent and add velocity to the object to "steer" it. A shadow > controller is a motion controller with some specific behavior that > chases targets. Those two paragraphs are worth their weight in gold. Thanks Jay :) John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
This is a pretty good summary, but you're missing a couple of things: > For player movement, what happens is that player's aren't > really physically simulated at all! But your own explanation says this isn't true: > After physics simulation occurs, the player entity is > reconciled with the VPhysics entity. Any VPhysics damage or > position/velocity differences are copied back into the > entity. So reconciliation could mean that the vphysics data is copied over to the game - which means the original game simulation is replaced with the physics simulation. It could also mean that the vphysics data is thrown away, or blended into the result. It's much more correct to say that the players are always simulated in game code AND vphysics code. Then the results are selected or blended based on heuristics. Gravity runs in both simulations - the output position of the game physics provides the input direction for the vphysics simulator. > Correction: the shadow is not updated for every CUserCmd, but > for every _batch_ of commands. correct. > When the commands > finally to arrive, they are then all simulated in the > timespace of a single frame. not correct. float flSecondsToArrival = ( ctx->numcmds + ctx->dropped_packets + additionalTick ) * TICK_INTERVAL; The shadow is updated once, but the resulting output target is reached over some amount of future ticks. > What exactly are the non-obvious differences between the > Player/Vehicle/Shadow/Motion controllers? Player and shadow controllers are nearly identical. The idea is to solve an overdetermined system for impulses that will cause the physics object to arrive at the target position & orientation at some point in the future (usually the beginning of the next tick). Vehicle controllers include a vehicle suspension, steering, and engine model - and are generally forward controllers (you give them input and they generate physics, they don't solve for impulses). Motion controllers are just generic hooks to let you introduce your own impulses to the object at the time that it is integrated. You implement IMotionEvent and add velocity to the object to "steer" it. A shadow controller is a motion controller with some specific behavior that chases targets. > > To get movement code identical to HL1, effectively all you > would need > > to do is remove the code from VPhysicsShadowUpdate(), but then your > > player would lose all interaction with physics objects, and > why would > > you want that? sv_turbophysics is effectively this plus some forces that push you out of moving physics objects. Short of predicting the simulation on the client, this is a reasonable tradeoff once latency is high enough. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Physics
On Fri, 2006-03-31 at 15:09 -0500, Jorge Rodriguez wrote: > Wow! For once, an informative, accurate and thoughtful post in a list > that usually contains nothing but cruft! You caught me off guard. > Thanks, John. All hope is not dead on teh intarnets. A few notes: Correction: the shadow is not updated for every CUserCmd, but for every _batch_ of commands. If the user's commands are dropped for some reason, then the player is not simulated at all server-side. (His physics shadow doesn't move, but it still exists). When the commands finally to arrive, they are then all simulated in the timespace of a single frame. What exactly are the non-obvious differences between the Player/Vehicle/Shadow/Motion controllers? > Actually, CGameMovement is pretty much a direct port to C++ of HL1's C > pm_shared code. Most of the physics and alot of the code has been > retained. The only real functional difference between HL1 and HL2 > movement code is the player vphysics shadow, and all that does is move > the player around a little bit if his movement interferes with vphysics. > To get movement code identical to HL1, effectively all you would need to > do is remove the code from VPhysicsShadowUpdate(), but then your player > would lose all interaction with physics objects, and why would you want > that? That was essentially my point. It's not my problem, though, it's KMod's problem. I just brought it up because I noticed a few mailings on this list from them. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Physics
Wow! For once, an informative, accurate and thoughtful post in a list that usually contains nothing but cruft! You caught me off guard. Thanks, John. John Sheu wrote: QUESTIONS 1. Are we guaranteed only 1 CUserCmd processed per frame? I don't think so. I think that in high-lag situations the net code may receive more then one user command in the space of one frame. There's definitely the capacity to process more then one command, so I assume that Valve wrote that because there is a possibility of that happening. OTHER THOUGHTS I haven't seen any GoldSrc code before, but I suspect that the only way to _exactly_ reproduce GoldSrc player physics would be some crazy coding in VPhysicsShadowUpdate(), or even stripping the player of VPhysics simulation entirely. You'll likely do a _lot_ of copy-pasting of GoldSrc code either way. I think, to be honest, that you'll have to go the latter route (nuking VPhysics) because there's no way that VPhysics will exactly reproduce GoldSrc physics. You'll have to do it all in CGameMovement. Actually, CGameMovement is pretty much a direct port to C++ of HL1's C pm_shared code. Most of the physics and alot of the code has been retained. The only real functional difference between HL1 and HL2 movement code is the player vphysics shadow, and all that does is move the player around a little bit if his movement interferes with vphysics. To get movement code identical to HL1, effectively all you would need to do is remove the code from VPhysicsShadowUpdate(), but then your player would lose all interaction with physics objects, and why would you want that? -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Physics
I'm going to put this here both as a note to myself and as a way of getting commentary on this from anybody who is interested in player physics, server-side. Please do correct me if anything is wrong here. So how does player physics work? At the very base are the CUserCmds that are fed into the server. CServerGameClients (I will be referring to these by implementation, not interface) gets these through ProcessUsercmds() and passes them on to CBasePlayer's ProcessUsercmds(). They're buffered there. Now there comes a time when GameFrame() is called in CServerGameDLL. The call chain of interest is: CServerGameDLL::GameFrame() Physics_RunThinkFunctions() Physics_SimulateEntity() CBasePlayer::PhysicsSimulate() Now is where the CUserCmds are actually used. For each CUserCmd, this happens: Each CUserCmd is passed into CBasePlayer::PlayerRunCommand(). CPlayerMove::RunCommand() is called, calling these three: CBasePlayer::SetupMove() [prepares the CMoveData] CGameMovement::ProcessMovement() [updates pos, vel, etc.] CBasePlayer::FinishMove() [copies the updated data back] The VPhysics shadow object is updated with new pos and vel. Ok then, all CUserCmds are processed. Then, CServerGameDLL::GameFrame() calls IGameSystem::FrameUpdatePostEntityThinkAllSystems(), and this happens: CPhysicsHook::FrameUpdatePostEntityThink() PhysFrame() In this function, the entire physics environment is first simulated. Then, CBasePlayer::VPhysicsShadowUpdate() is called. This is where the fun stuff is, where the player entity's position is reconciled with what the physics system thinks it is. Then, after all this, data is sent off to the client, yadda yadda. SO What's the moral of the story? Here's what I get out of the code: For player movement, what happens is that player's aren't really physically simulated at all! Everything (movement, gravity, swimming, etc.) is handled by the CGameMovement class. With every CUserCmd: 1. CGameMovement "simulates" the player and derives new pos/vel. 2. A physics "shadow object" is updated with the new pos/vel. This happens for every CUserCmd. Then, after all the CUserCmds have been processed that frame, the physics simulation actually occurs. At this time, _all the VPhysics shadow updates for that frame are processed at once_. Let's say, there were 3 CUserCmds from the player processed this frame, then the 3 shadow state updates will happen sequentially in the same frame. After physics simulation occurs, the player entity is reconciled with the VPhysics entity. Any VPhysics damage or position/velocity differences are copied back into the entity. Then the ent data is packaged and shot off to the clients. QUESTIONS 1. Are we guaranteed only 1 CUserCmd processed per frame? OTHER THOUGHTS I haven't seen any GoldSrc code before, but I suspect that the only way to _exactly_ reproduce GoldSrc player physics would be some crazy coding in VPhysicsShadowUpdate(), or even stripping the player of VPhysics simulation entirely. You'll likely do a _lot_ of copy-pasting of GoldSrc code either way. I think, to be honest, that you'll have to go the latter route (nuking VPhysics) because there's no way that VPhysics will exactly reproduce GoldSrc physics. You'll have to do it all in CGameMovement. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player physics
Jim Hunter wrote: >> Does anyone have an idea how I would make a player turn on a dime? >> I don't want there to be any acceleration, I just want the player >> to instantly move in the direction he's facing > > Acceleration is handled in PM_Accelerate (in pm_shared.c) IIRC. You > just need to take the forward, side and up move commands in the cmd > structure and multiply them by the forward, right and up vectors > obtained from the angles and add them together to get your new > velocity vector. Then you'd need to clamp the speed to maxspeed. That's basically it. I think that PM_Friction (or something like that) also needs to be changed, and that they are tightly coupled. I have to admit that I never really figured out how it was supposed to work. I just ripped that whole section out and did it my way. Actually, I was never able to (objectively) tell the difference between the default behavior and instantanious acceleration, it is pretty close. Messing with the parameters just made the behavior get yucky. If you do anything other than instantainous or the default, you have to be a bit carefull to make sure that the movement is stable. TIme delays and limited velocity and position accuracy can make the view shake if you aren't carefull. Ralph Hartley ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player physics
>Does anyone have an idea how I would make a player turn on a dime? >I don't want there to be any acceleration, I just want the player to >instantly move in the direction he's facing Acceleration is handled in PM_Accelerate (in pm_shared.c) IIRC. You just need to take the forward, side and up move commands in the cmd structure and multiply them by the forward, right and up vectors obtained from the angles and add them together to get your new velocity vector. Then you'd need to clamp the speed to maxspeed. You could probably ditch most of the code in PM_Accelerate. Sorry I can't be more specific, I don't have access to the code ATM. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player physics
turning and acceleration are somewhat different; acceleration in HL is generally when you move forward slowly then of course build up speed... if you mean that then you need to look around in the pm_shared.c file, and i believe from there PM_PlayerMove - Original Message - From: "Georges Giroux" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 11, 2002 8:09 PM Subject: [hlcoders] Player physics > Hey guys, > > Does anyone have an idea how I would make a player turn on a dime? > I don't want there to be any acceleration, I just want the player to > instantly > move in the direction he's facing... anyone have any ideas? > > Georges > > -- > Project Lead/Coder > Gladiator mod > [EMAIL PROTECTED] > ICQ: 11425443 > http://gladiator.lan-gaming.com > > ___ > 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
[hlcoders] Player physics
Hey guys, Does anyone have an idea how I would make a player turn on a dime? I don't want there to be any acceleration, I just want the player to instantly move in the direction he's facing... anyone have any ideas? Georges -- Project Lead/Coder Gladiator mod [EMAIL PROTECTED] ICQ: 11425443 http://gladiator.lan-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders