   Help translate Formula to DX9 C++
  Hello.I want to use this formula for my collision response, but i don´t know how to implement this in code...V' = 2 * (-V dot N ) * N + V(where D3DXVECTOR3 V and D3DXVECTOR3 N are unit vectors).V' = new direction and velocity.N = Normal (closest_point_intersection to center of sphere)How can i code this using C++?D3DXVECTOR3D3DXVec3NormalizeD3DXVec3DotThis is what i have to work with...   
  This should do it:D3DXVECTOR3 Func(const D3DXVECTOR3& V, const D3DXVECTOR3& N){   D3DXVECTOR3 vMinus(-V);   return 2 * D3DXVec3Dot(&vMinus, &N) * N + V;};  thanks but for the 1000 times the collision response isn´t working, i can´t slide around corners using this formula. don´t understand what the problem is...   ;  Evil Steve answered the question that you asked, "How can I code this using C++?" So, I think there is a different question to be asked.Looking at your post, I wonder if you are using the wrong normal vector. In your post, next to N = Normal, you wrote "(closest_point_intersection to center of sphere)". If you meant that literally, then, that's wrong. The normal vector is not the closest point intersection to center of sphere. It isn't even the normalized, unit-length version of the point of intersection. You have to look at the contact point measured relative to the center-of-the-sphere...wherever the sphere might be, so the contact normal, N, is:N = D3DXVec3Normalize(point_of_intersection - center_of_sphere);You might very well have this right, and just described it awkwardly. That's okay.If the normal vector is good, and the velocity vector is correct, then I would begin to look and see if you are computing the correct point of intersection. Sliding around corners can be tricky, especially interior corners, where you could have two points-of-intersection to resolve simultaneously...are you having problems with exterior (convex) or interior (concave) corners? There's also the issue of tunneling, e.g., if the object moves too fast, it might interpenetrate another part of the wall in a concave corner, or might pass right through a thin wall.One thing you might try doing is debugging your code, and when you have a collision, look at the values in a watch window, then draw a picture of the situation on graph paper. Look at the velocity before and after....look at the point of intersection and the contact normal...see if visually the situation and the result makes sense.I hope this helps!   ;  Hi and thanks for your answer. I guess you are right and i don´t have 100% fully understanding of what i am doing with the formula.I can slide on walls and corners perfectly by just using the walls normal and calc how much the sphere has penetrated the wall and then push it out that much.I use a method where i have the closest point on all walls all the time using projection. i always have a point that is closest to the player from all walls.This point i am using and calculating length from wall to sphere. and if this length is < 1.1f then i determine that there is a hit.Is this a problem, lots of people are using elapsed time, this is a concept i don´t understand, the gameloop itself are always running, why use elapsed time?N = D3DXVec3Normalize(point_of_intersection - center_of_sphere);So point of intersection if the spheres radius is 1.1f is not closest point on line? My velocity vector is the movement from my cameras position to view + speedit is just a vector with a length that determines the direction and length as speed.Im beginning to loose hope on this. i can get player to slide straight perfectly, it is the corners that not are smooth enough (convex, concave works perfect), i want it to be like Quake3, now WOlf3D =)   ;Quote:Original post by MeshboyIs this a problem, lots of people are using elapsed time, this is a concept i don´t understand, the gameloop itself are always running, why use elapsed time?The problem is that even though the game loop is always running, your code is still executed at a discrete moment in time, and the next time it is executed it will be a different discrete moment in time. That is, there is always some nonzero time between animations steps. This is the time difference, the elapsed time, that is important. If objects are moving fast enough, you might get significant interpenetration (sphere deeply embedded in wall) or simple overlap tests might miss collisions entirely (e.g., two spheres fail to collide when they should)...this latter case is called tunneling. Some physics engines use continuous collision detection (CCD) to consider the fact that objects continue to move during the period of elapsed time...looking for collisions between time "A" and time "B" rather than just looking for collision at time "A" or at time "B". The essential math tutorials (linked from the sticky thread on physics engines and resources at the top of this forum) will give a much nicer introduction on this subject.Quote:Original post by MeshboyN = D3DXVec3Normalize(point_of_intersection - center_of_sphere);So point of intersection if the spheres radius is 1.1f is not closest point on line?My formula for N gives you the sphere's normal vector based on a known point of intersection. In the case of colliding with a flat wall, the sphere and wall normals will be parallel. The point of my comment was that you cannot say that "N = closest point on line". Your original post had words to this effect, but that is wrong. But, I think that you just wrote some confusing information. I believe you have a good normal vector, based on other things you wrote and another thread.Quote:Original post by MeshboyMy velocity vector is the movement from my cameras position to view + speedit is just a vector with a length that determines the direction and length as speed.Oh...here is a potential problem. But again, perhaps merely a language issue. Are you taking your camera's position, transformed into world space via the view matrix, to be the direction of velocity? If so, that is wrong. You cannot convert the camera's position into a velocity. If the player/camera is always moving in the direction the camera is looking, then you need to use the camera's "look" direction (transformed into world space) as the direction of your velocity. Using traditional 3D graphics representations, the direction the camera is looking is the camera's Z axis. If player/camera movement and look direction are independent, then you will have to have some other parameter that determines the direction of player/camera motion. I think this is still a communication/language issue. But, your words did cause me to worry that you are using an incorrect velocity vector.Quote:Original post by MeshboyIm beginning to loose hope on this. i can get player to slide straight perfectly, it is the corners that not are smooth enough (convex, concave works perfect), i want it to be like Quake3, now WOlf3D =)Don't lose hope. This isn't a very complex thing, and I think there is just a simple problem to fix. The challenge is to debug the code to find the problem. I will again recommend using graph paper. Run your code in the debugger. When you detect a collision at a corner that is misbehaving, draw a picture of your geometry. Draw in the position of the sphere, the velocity vector, the normal vector that you are using, then calculate V' and draw that too. See if, visually on graph paper, the result makes sense. This visual debugging...can be massively, extremely helpful in finding problems with physics algorithms!   