How to determine if mouse "touches" a mesh? (HLSL)

Started by
2 comments, last by Adam_42 16 years, 3 months ago
I know how to do it without HLSL, we can calculate the "normal" of the window on the mouse point, and if the "normal" intersects the mesh, it means that mouse touches a mesh. But my question is how to do it with out HLSL? The codes without HLSL are as follows: public void OnMouseMove(object sender, System.Windows.Forms.MouseEventArgs e) { Vector3 p1 = new Vector3( e.X, e.Y, (sender as Framework).Device.Viewport.MinZ ); Vector3 p2 = new Vector3( e.X, e.Y, (sender as Framework).Device.Viewport.MaxZ ); p1.Unproject( (sender as Framework).Device.Viewport, (sender as Framework).Device.Transform.Projection, (sender as Framework).Device.Transform.View, (sender as Framework).Device.Transform.World ); p2.Unproject( (sender as Framework).Device.Viewport, (sender as Framework).Device.Transform.Projection, (sender as Framework).Device.Transform.View, (sender as Framework).Device.Transform.World ); if (mesh.Intersect(p1, p2)) { touched = true; } }
Advertisement
It's not practical -- in many cases, flat out impossible in fact -- to write collision detection code in a shader, especially in the tradional way for the traditional picking usage.

Why do you want to do this?
I concur with jpetrie - HLSL isn't really set up for this sort of thing.

You could do it using Direct3D 10's Geometry Shader with Stream Out - you can generate the plane equation and/or barycentric coordinates for this sort of test and then emit/cull accordingly. You'd then get an SO buffer containing a list of triangles that intersected with your ray.

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

The other way of doing it with HLSL is to render the scene an extra time. Use that extra pass to write a unique colour per mesh (or per triangle if need be), and you can then test that colour to see which mesh a given point is over. Just make sure the colour isn't adjusted by antialiasing, filtering, etc. You could even set a single pixel scissor rect to speed things up a bit more.

It still adds a lot of overhead though, and of course transferring that result back to the CPU will be slow if you need it there.

This topic is closed to new replies.

Advertisement