   Jitter in character movement in 3D game
  Hello,I've written a 3rd person 3D game in C++ and DirectX, here's a link to some YouTube videos showing current progress:The collision detection/response is basically a swept-sphere algorithm that I took from Kasper Fauerby's online document. It works quite well, except I am experiencing annoying jitter when I move the characters around the world.Every collidable in the game world has a low-poly collision mesh (including the heightmapped terrain), which gets submitted to the collision det/res algo when the character gets close to it (taking into account the meshes' world position center vector, the meshes' radius and the character's max speed).Each character is modelled as an ellipsoid whose 3 radii vary dep. on the character's size (so larger character's are a taller, wider ellipsoid).The jitter happens when the character changes heights, usually downwards, walking down a hill, falling off a bridge, etc.Each frame, every character has a requested displacement vector, which represents their desired displacement along the (x, y, z) axis. If there was no collision, at the end of the frame, the character's new position would simply be:new_posVector = old_posVector + desired_dispVectorIn reality, the dispVector is adjusted by feeding the current position, the desired displacement (velocity) and the world gravity vector to Kasper's swept-sphere algorithm and receiving an adjusted displacement vector, which is then added onto the character's old position:new_posVector = old_posVector + adj_dispVectorSo this adjusted displacement will take into account the "slide" vector computed via Kasper's algorithm and basically be the desired vector adjusted so that there is no collision (the slide) and so that gravity has been accounted for.Well, that's where my trouble comes in. The movement is annoyingly jittery as the character does something simple like walk down a hill, and also has annoying jitter when the character runs into a corner or against a table for example.The jitter gets even worse when the desired displacement vector reflects a y-axis adjustment for jumping. Here's how the desired displacement vector is computed (variable is called m_vRequestedVelocity):float xAmt = m_fSpeed * deltaT * sinf(m_fFacing);float zAmt = m_fSpeed * deltaT * cosf(m_fFacing);D3DXVECTOR3 newPos = D3DXVECTOR3( m_vPos.x + xAmt, m_vPos.y,  m_vPos.z + zAmt );if (m_fSpeed != 0.0f){    D3DXVECTOR3 a = (newPos - m_vPos);    m_vRequestedVelocity.x = a.x;    m_vRequestedVelocity.z = a.z;}// Animate jumpif (m_jumpPrc < 1.0f){    m_jumpPrc += deltaT;    if (m_jumpPrc < 0.0f) m_jumpPrc = 0.0f;    if (m_jumpPrc > 1.0f) m_jumpPrc = 1.0f;    D3DXVECTOR3 pos = D3DXVECTOR3( 0.0f, 0.0f, 0.0f );    pos.y += ( sinf((float)m_jumpPrc * D3DX_PI));    m_vRequestedVelocity.y = pos.y;}As you can see the character's only request movement along the (x, z) axis unless they are jumping.Now the collision detection/response algorithm will generally adjust this incoming vector (m_vRequestedVelocity) to have some amount of change in y (even when not jumping) to reflect the collision from the character being pushed down by gravity.Can someone with a little more experience in this than me analyze what I'm doing and give me some insight into why I'm getting annoying jitter as my ellipsoid character's collide and slide around my 3-d world?   
  Since this hasn't received any replies yet, I'll go ahead and post (although I'll probably give the same answer I always give to this question).I did the whole 'swept ellipsoid' thing some time ago, and finally got it working perfectly with no jitter, fall-through, problems with acute or obtuse corners, or other undesirable behaviors. I'm fairly certain that the method presented in Kasper's paper doesn't handle these cases correctly 'out of the box'; from my own experience at least, I had to add special handling for these cases.The special handling mostly involved detecting when multiple surfaces were intersected in the same step (and when the same surface was intersected more than once), and responding accordingly. In some cases this involved restricting the object's velocity to be parallel to a 'crease vector' defined by two intersecting surfaces.In short, I got it working, but it was a pain. If I were doing something like this now, I would instead try to find a pre-existing physics engine with reasonable licensing terms and use that instead. PhysX, for example, has great built-in support for exactly this type of motion. (I can't remember what the licensing terms are for PhysX currently though.)Nice video by the way :)   ;  Thanks for the reply, I've been sort of dreading the kind of answer you gave. I had been trying to do stuff like smooth out the final position (via interpolation) after applying the adjusted displacement vector and keep Kasper's algo. a black-box.Naturally that didn't work because it causes interpenetration. For example I was reading Brandon Pelfrey's post about Verlet Integration and I tried doing a simple Verlet integration between old final position and current final position using the adjusted displacement vector as the velocity, but it would place the player so that they were interpenetrating geometry.Since the integration was applied after the collision det/response was computed, it would basically undo it. This could result in falling through the floor.Actually Kasper has an improved collision detection and response algo that I implemented when first got started on the project, which eliminated a lof of the fall-through you were talking about, but it still turns out to be jittery.http://www.peroxide.dk/papers/collision/collision.pdfI am conflicted about whether I should try to fix what I have or rip it out and start over with a 3rd party library.   ;Quote:Actually Kasper has an improved collision detection and response algo that I implemented when first got started on the project, which eliminated a lof of the fall-through you were talking about, but it still turns out to be jittery.http://www.peroxide.dk/papers/collision/collision.pdfYeah, unless I'm mistaken, even the 'improved' algorithm doesn't address problems (e.g. jitter, getting stuck, etc.) related to intersecting multiple surfaces in one update.Quote:I am conflicted about whether I should try to fix what I have or rip it out and start over with a 3rd party library.I know this topic has come up a few times on the forums - you might try searching the archives for phrases such as 'collision detection' + 'corners/jitter/ellipsoid/etc.', and see if you can find some of those threads. I know others have dealt with this problem as well, so you might be able to find some useful info in these previous threads.And yeah, I'd at least look into using a third-party library for this if I were you - it could save you considerable time and effort.   