   using mouse to click on texture and return point
  Hi,Basically what I'm wanting to do is have a flat plane with a checkerboard patterned-texture on it. The camera will always face it directly on, but can pan around and zoom in/out. If the user clicks on a particular square on the checkerboard texture on the plane, how could I get the coordinate to figure out what checker-square was clicked on?I've really been banging my head against the wall on this one and I think I might just be missing something simple. Here are the steps I've thought of already:1. project the quad's vertices onto the screen with the standard projection/view matrix (the plane is stationary, only the camera will move)2. at this point, as I understand it the rasterizer can shift all the pixels due to the fill convention used (I'm using DirectX).3. so if a user clicks the mouse, would I need to transform the click back into 3D? Then if so, would I need to interpolate the uv coordinates which would help me know what square was clicked on?And would the pixel shifting of the fill convention make it harder to know which pixel was clicked on? Thanks for any help   
  If this is for something like chess why not make 64 quads and check them separately?   ;  wow, yeah that makes total sense, I knew I must be missing something obvious, thanks :)So if I use say a 8 x 8 grid of quads, then I can just transform the mouse click back to 3D coordinates, do a ray/triangle intersection test, and use that to detect which triangle was hit and therefore which quad, correct? I guess I could even just use vertex colors to color each checker square and wouldn't need a texture at all at that rate.   ;  If you grid has a fixed size known to you its even simpler than using ray triangle intersection. Although it doesn't really matter for such a small count of quads. You can just do one single ray - plane intersection test against the plane of the checker board. The result is a point in 3d space which - using your knowledge about the equal distribution of quads on the plane - you can then use to find which quad has been hit.   ;  good point, thanks, once again I was making things too complicated. One last question on the matter, regarding my earlier query about the rasterizer shifting pixels due to top-left fill rule, does this mean I could theoretically click on the left edge pixel of a checker board square, and not register a hit? or else register a hit on a neighboring square instead?   ;  Since you deal with floating point coordinates but with a integer range display area on your screen the rendered scene is always just a close approximation of your 3d scene in a mathematical sense. But you won't notice such a scenario.   ;  for a more general solution I think you could probaly project the triangle/quad into 2d screen space, calculate triangle gradients, i.e. du/dx, dv/dx, du/dy, dv/dy and then simply work out the uv coordinate based off of a 2d screen position. I think this is probaly how it is done in games like doom3, but I could be wrong.   ;  Thanks everyone for the responses, I really appreciate it.@Waterwalker:That makes sense about the rendered scene as an approximation, good to know it won't be a problem in practice.@staticVoid2:Interesting, I think I see what you're saying, so in order to get the correct triangle gradients, would I need to use the same calculations that the rendering API is using? So I'm assuming DirectX/OpenGL uses some way of calculating those gradients, I've read through Chris Hecker's articles on perspective texture mapping, but I wasn't sure if the various API's did their own variant of that idea or something different.Or are you meaning that I just render it on the CPU by projecting it myself? I appreciate all the info.   ;Quote:Or are you meaning that I just render it on the CPU by projecting it myself? I appreciate all the info.yes and no, you don't need to render the triangles, just let directx do this but keep a separate copy of the two triangles in memory and then transform and project these onto the screen, once you have the 2d screen positions and uv coords you can calculate the gradients and work out the uv coord based on the position of the mouse. Also you would need to first find out which triangle you have selected by either casting a ray in the world or just using the projected triangle and doing a point-in-triangle test. the latter would be faster unless there were a lot of triangles that you needed to cull.   ;Quote:Original post by staticVoid2for a more general solution I think you could probaly project the triangle/quad into 2d screen space, calculate triangle gradients, i.e. du/dx, dv/dx, du/dy, dv/dy and then simply work out the uv coordinate based off of a 2d screen position. I think this is probaly how it is done in games like doom3, but I could be wrong.As pointed out this is not a noticable issue. By projection all your data to 2D manually you get really slow. For quads it might be okay but once you start working with meshes is awefully slow. Even if you have some kind of hierarchical visibility culling inside your mesh structure. It is alwas fast to convert the 2D pixel to a 3D ray and pick against the world coordinates (or even the mesh local coordinates) than doing this project 2D approach. 