Maximum Range for Mesh.Intersect Function?

I am testing for intersections from a point into a mesh at a specified direction, but it only returns hits usually if they are less than 100. I have gotten a 101 before, but, never greater than that. Is there some sort of maximum range for the intersect function I wouldn't imagine there being one, but, if so, how does one extend it

Here is my code, in case someone spots an error elsewhere:

Function HitMesh(ByRef AnotherMesh As CZoopD3D.CMesh, ByVal Direction As Vector3) As Single

Dim Hits() As Microsoft.DirectX.Direct3D.IntersectInformation, I As Integer

Dim Bottom As Vector3, Top As Vector3, PlayerMesh As CZoopD3D.CMesh = GetMesh()

'make matrix that puts everything into model space

Dim FinalMatrix As Matrix = Matrix.Multiply(PlayerMesh.Matrices.GetMatrix, Matrix.Invert(AnotherMesh.Matrices.GetMatrix))

'put bottom and top into model space

Bottom = Vector3.TransformCoordinate(New Vector3(0, 0, 0), FinalMatrix)

Top = Vector3.TransformCoordinate(New Vector3(0, CELLSIZE, 0), FinalMatrix)

'put direction into model space

Direction = Vector3.TransformNormal(Direction, FinalMatrix)

'Direction = Vector3.Normalize(Direction)

'test

Dim T As Integer, H As Integer, D As Single

Dim TestPoint As Vector3

Const HeightDivisions As Integer = 15

For T = 0 To HeightDivisions - 1

TestPoint = Bottom

TestPoint.Y += ((Top.Y - Bottom.Y) / HeightDivisions) * T

AnotherMesh.GetMesh.Intersect(TestPoint, Direction, Hits)

For H = 0 To UBound(Hits)

D = Hits(H).Dist

If D <= 3000 Then

Return D

End If

Next H

Return -1

End Function

I apologize for the horrible copy and paste job. You'd think that the MSDN forums would understand code better.

Long story short on what this does: It starts at the "feet" one the PlayerMesh. Goes up in small increments seeing if it hits another mesh.

It is simply unbelievable how many troubles I have had getting this to work right...

Answer this question

Maximum Range for Mesh.Intersect Function?

walan
I remember the days I used the function (about a couple of years ago) I had to normalize the ray direction, then multiply it by a really big value (e.g. 10000.0f)... Can you try this please
flynng
Scaling the direction vector does change the scaling of the returned hit distances, but it does not appear to catch longer distances... it's the same distance just multiplied by whatever I scale the ray to be.

I found out what the mistake was. FinalMatrix is the combination of both meshes and their transformations, put into model space. Not realizing it, when I took the position vector (in world space, so, essentially already transformed) and multiplied it by the FinalMatrix. Long story short, I transformed the position twice. So, all I did to correct this was pass in a position vector of (0, 0, 0), since FinalMatrix already contained the transformation (which included the respositioning) for the mesh.

What I copied above was particularly used to check if a player hit a terrain object. Not only had I made the same mistake of double transforming the position, I also double transformed the direction. So, I did the equivalent of what I said above for position, except for direction. If straight ahead, I transformed a ray direction of (0, 0, 1), etc. Having both of these double transformations made it really hard to notice what was going on--not only did I have the position wrong, but I had the direction wrong as well! No wonder why it was so hard to diagnose!

The reason why I was so instictively multiplying coordinates by the FinalMatrix is because originally I was taking the points out of the model space, which do need to be multiplied by the FinalMatrix. However, when taking points out of the world space, the FinalMatrix already takes that into effect, so I need to use relative vectors. So therefore, a position of (0, 0, 0) means the center of the first mesh.

Thanks for the indirect help!
Artmic
I have noticed at least 2 variables that affect the hitpoint depth value:

The back clipping plane value of your Projection transformation

The Z value of the far point of the ray you are testing.

Does that make sense

It may be that you are not getting values bigger than 100.0 or so because you back plane is at 100.0 and is clipping the ray ... just a thought.
teemuh
I noted that you commented out the normalization of the ray direction. I had a problem with unormalized ray directions and strange distance values when I started using the intersection function (c++). It seems to only work properly when you give it a normalized direction which is not mentioned in the docu.

Maybe this helps.

Nico
Nitstheone
So, you did something akin to:

'put direction into model space
Direction = Vector3.TransformNormal(Direction, FinalMatrix)
Direction = Vector3.Normalize(Direction)
Direction = Vector3.TransformNormal(Direction, Matrix.Scaling(10000, 10000, 10000))

Yes

(What does the "This post contains a code sample" do anyway )
Gita Shingala
I commented it out just to see what would happen. It still seemed like it had a range either way.
Philip Vaughn

Yes, almost... Actually it was:

Direction *= 10000.0f;

instead of transforming it with a scaling matrix...

The 'This post contains a code sample' will show a certain icon when browsing the different threads. I also thought it would apply automatic syntax coloring to the code but looks like it doesn't
bong2x

Unfortunately I don't have anything technical to add, but...

Wessam Bahnassi wrote:
The 'This post contains a code sample' will show a certain icon when browsing the different threads.
I'm pretty sure it's also quite heavily used by the forum/VStudio searching tools.

Wessam Bahnassi wrote:
I also thought it would apply automatic syntax coloring to the code but looks like it doesn't
Nope, you have to manually box up the code in [ code ] tags. Even then it's not been perfect

for(int i = 0; i < 10; i++ ) std::cout << "This should appear as C++ code!" << std::endl;

Cheers,
Jack
Maximum Range for Mesh.Intersect Function?