   RTS games
  How do you implement object movement in an RTS game???As in, i know how to make an object move to a specific point in 3d space, but how do you find out that specific point in 3d space? I want this to be like in other RTS games, where you click on an object, then on the terrain, and the object moves there, with extreme granularity. How do you do this? Thanks in advance! :)   
  search for A-star (A*) pathfinding   ;  Well, that wasn't what i was looking for. I was looking for a way to know the point where the user clicked on in world coordinates, not just how to make an object move from one place to another.;  Do an unprojection of the point. In opengl, you can do this using glUnproject (not sure about direct X). The basic idea is you take the coordinate in 2D screen space, and multiply by the inverse projection modelview matrix to get a point in 3D world space (however, a point on the screen actually corresponds to a vector in 3D space - from depth 0 (near plane) to depth 1 (far plane), as you need to give the x y pixel coordinates and the depth).If you want to be really accurate, take the ray from unProject (x, y, 0) -> unProject (x, y, 1) and intersect it with the scene/ground. Additionally, you can do the cheaper intersect ray with ground plane.   ;  another way might be to render everything with positions or IDs into some buffer. on click you just read that pixel position from the backbuffer.while this might be not as elegant as raycast, it might be a good solution if you have non-trivial rendering going on that might affect the click result (like skinned shader, alphatest textures etc.);  Thanks terra0nova! so now this becomes a problem of ray-plane intersection...I wonder where I'll find how to do that....Anyway, Krypt0n, that's the exact same thing that the picking mechanism does. I'll use that for object selection, but I can't really do this for finding out the vertex for an object to move to on the ground..but thanks anyway!   ;  and no sarcasm was intended in my previous post   ;  Yea - reading from texture/frame buffer is also possible to get the position where you click - however this tends to be much slower due to the memory bottleneck between the GPU and CPU (transfer from CPU -> GPU is fast, GPU -> CPU is much slower). Additionally, if you have to re-rasterize the entire scene just to get that one point when you click (instead of reading from a texture or framebuffer previously rendered to), then this becomes much slower.Ray-plane intersection is very easy and fast. Given a point P on the plane, and the normal N of the plane, you can compute the t value as follows:t = (P-O) dot N / (D dot N)where O is the origin of the ray, and D is the direction of the ray (O = point at depth 0, D = vector between depth 1 and depth 0 in this case).You can then get the point by plugging t in the equation for the ray: O+t*D.t should be between 0 and 1 to be inside the view frustum. If t is less than 0, it is before the near plane, and greater than 1, it is beyond the far plane.   ;  see my journal :)ray -> plane test is only gonna work if the terrain is a plain (+ will fail if u click on say a unit or object on the terrain)the easiest method, cast a ray from cameras pos through the cursors pos, find out what objection, position it intersects first + yse as Matt Aufderheide saiz use Astar or something to handle the movement to that spot   ;  zedz, that's the same thing that terra0nova says (with the ray). And (for now, at least) the terrain is a flat plane. I'll use OpenGL's object selection/picking for object/unit selection. I will use A*  (once I learn how to do it, probably later though) for path finding, just like you and Matt said.terra0nova: thanks a bunch, again. So D is just the vector of the ray, right? I'll implement this now, and hope it works, which it probably will. But will gluUnproject work if I translate/rotate the view with glRotate/glTranslate?   