Check if objects intersects between two points?

Started by
27 comments, last by perroned 13 years, 1 month ago
Hi :)
So I have two position vectors, whats the best way to determine if a mesh intersects inbetween the two points. I was getting confused with ray picking so I developed an alternative to get the points, but how can I now check if anything is inbetween the 2 points?
thank you
Advertisement
I'll be honest I don't know the math for this. My first tact would be to do a ray-triangle intersection test ( first result on google, maybe not the best source: http://www.softsurfer.com/Archive/algorithm_0105/algorithm_0105.htm ) on a bounding box surrounding my meshes and then on every triangle in the mesh when the first check works. There are likely quicker methods and with at least D3DX for Direct3D 9 there is a function just for this ( http://msdn.microsoft.com/en-us/library/bb172882%28v=vs.85%29.aspx ).

In your case you are talking about having a line segment which is basically a ray with an extra condition. I don't see how the math could possibly be easier with a line segment than with a ray but I'm happy to be wrong!

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

nobodynews basically covered it, but it sounds like you're looking for a segment-mesh intersection function.

The first things I'd do would be:

1. Determine if you really need an exact segment-mesh intersection test, or if using a simpler approximating shape would suffice.

2. See if any of the APIs you're using already offer this functionality.

If the answers to the above two questions are 'yes' (you need an exact test) and 'no' (you don't already have the functionality available), then the first thing you'll want to do is early-out if you can based on a simple bounding volume test (e.g. sphere or box - of these, the segment-sphere test is a little easier to implement).

The next issue is numerical robustness. For intersection tests between a linear component and an arbitrary mesh, you have to handle things in a certain way or risk intersections falling 'between the cracks' due to numerical error. This can be done by ensuring that the necessary calculations for each edge are performed in exactly the same way whenever that edge is encountered.

Finally, you'll need to decide if a broad phase is needed, which will depend on the average number of triangles in the mesh and the frequency with which the test is performed. (Whether the mesh deforms at all will also be a factor.) If you need a broad phase and the mesh does not deform, a local-space octree or grid (you could use 3D-DDA with the latter) might be a reasonable choice.

I'll be honest I don't know the math for this. My first tact would be to do a ray-triangle intersection test ( first result on google, maybe not the best source: http://www.softsurfe...orithm_0105.htm ) on a bounding box surrounding my meshes and then on every triangle in the mesh when the first check works. There are likely quicker methods and with at least D3DX for Direct3D 9 there is a function just for this ( http://msdn.microsof...v=vs.85%29.aspx ).

In your case you are talking about having a line segment which is basically a ray with an extra condition. I don't see how the math could possibly be easier with a line segment than with a ray but I'm happy to be wrong!



Well I tried to use ray picking for a while but was never able to get it. I searched for weeks and posted threads on websites all over for help but was never able to get any help as to get the ray working so I basically did it another way where I just get two points, cuz I was hoping there'd b a simple method for testing it

nobodynews basically covered it, but it sounds like you're looking for a segment-mesh intersection function.

The first things I'd do would be:

1. Determine if you really need an exact segment-mesh intersection test, or if using a simpler approximating shape would suffice.

2. See if any of the APIs you're using already offer this functionality.

If the answers to the above two questions are 'yes' (you need an exact test) and 'no' (you don't already have the functionality available), then the first thing you'll want to do is early-out if you can based on a simple bounding volume test (e.g. sphere or box - of these, the segment-sphere test is a little easier to implement).

The next issue is numerical robustness. For intersection tests between a linear component and an arbitrary mesh, you have to handle things in a certain way or risk intersections falling 'between the cracks' due to numerical error. This can be done by ensuring that the necessary calculations for each edge are performed in exactly the same way whenever that edge is encountered.

Finally, you'll need to decide if a broad phase is needed, which will depend on the average number of triangles in the mesh and the frequency with which the test is performed. (Whether the mesh deforms at all will also be a factor.) If you need a broad phase and the mesh does not deform, a local-space octree or grid (you could use 3D-DDA with the latter) might be a reasonable choice.


A simple bounding box for my purpose will suffice, I do not need exact precision. And I am using DirectX9 & C++
If you use ray picking, you'll end up with an intersection point on the ray somewhere. You can then compare the length from the ray origin to the intersection point to determine if that length falls within the two distances you're interested in - which I think is what nobodynews is suggesting.

In any case, if your ray-picking doesn't work, the most common errors are not setting up the ray origin and direction correctly, or not considering the mesh's world transform in the intersection test.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.


If you use ray picking, you'll end up with an intersection point on the ray somewhere. You can then compare the length from the ray origin to the intersection point to determine if that length falls within the two distances you're interested in - which I think is what nobodynews is suggesting.

In any case, if your ray-picking doesn't work, the most common errors are not setting up the ray origin and direction correctly, or not considering the mesh's world transform in the intersection test.



Well my problem is getting the direction of the ray. I am using a first person camera with the DXUT class, and I have been trying everything and just cant seem to get the ray to work properly. Because since there is no mouse that you move around in first person, I dont know what I need to change in the formula.

And I know there are very easy intersection functions for a ray and the direction, thats why I wanted to do that, but I was never able to get the ray to work properly
It sounds like you're looking to shoot a ray from the eyepoint of the viewer. That's likely just screen center and your "mouse" position would be ( screenWidth/2, screenHeight/2 ). Unproject* the points p0=(mx, my, 0) and p1=(mx, my, 1). The ray position (in world space) is then (after unprojection) p0, and the ray direction is p1-p0 (the difference between unprojected p1 and unprojected p0).

*You can use D3DXVec3Unproject.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

@The OP: Another option for computing the direction vector for the ray would be to use the forward direction vector of the (uninverted) camera transform.

It sounds like you're looking to shoot a ray from the eyepoint of the viewer. That's likely just screen center and your "mouse" position would be ( screenWidth/2, screenHeight/2 ). Unproject* the points p0=(mx, my, 0) and p1=(mx, my, 1). The ray position (in world space) is then (after unprojection) p0, and the ray direction is p1-p0 (the difference between unprojected p1 and unprojected p0).

*You can use D3DXVec3Unproject.



Everyone kept telling me to go here http://www.toymaker.info/Games/html/picking.html but I wasn't sure exactly how to implement it. So are you saying all I would really need would be to do this -> Unproject* the points p0=(mx, my, 0) and p1=(mx, my, 1) , and then I have the ray?

Also could you just clarify the second and third parameters to D3DXVec3Unproject for me please? Im not sure exactly what to pass

and THANKYOU sooo much!! :)

This topic is closed to new replies.

Advertisement