Hi, it's me again
I wonder how do I know the end point in advance if rays are supposed to be infinite.
I am interested in knowing (as in the code) if the distance between origin and dest is shorter than the ray, it would return a false to the invoker.
Thanks
Jack

Hi, it's me again
I wonder how do I know the end point in advance if rays are supposed to be infinite.
I am interested in knowing (as in the code) if the distance between origin and dest is shorter than the ray, it would return a false to the invoker.

So is it a ray test or a segment test that you want? If you want to impose a 'max distance' limit on the ray, then it's actually a segment test that you want.

Also, did you see my post above? It includes some info that might be relevant to your question.

Hi jyk,
Now that I know how to handle the endpoint, so what is the method that handles edge tests uniformly as you mentioned? Any code snippets for me to reference.
Sorry, I've read your post, it's a matter of coincidence we posted at the same time
Thanks
Jack

Now that I know how to handle the endpoint, so what is the method that handles edge tests uniformly as you mentioned?

If books are an option for you, there's good coverage of the topic in Christer Ericson's collision detection book. (That's actually the only reference I can think of off the top of my head that covers it in detail, although I'm sure there are others as well.)

Ok, many thanks, i shall check that out too...

Why do you assume it falls through the cracks if you don't have the code for sameSideLine? Well, it doesn't because 0 value is counted as positive.

Counting 0 as positive doesn't address the problem. (Feel free to post the code for sameSideLine() though if you want.)

The other method is to use is actually less accurate and has more round error.[/quote]
What method are you referring to?

but no one (but you apparently) would argue it's more accurate.[/quote]
Nope, it's not just me. (For example, the book I mentioned earlier advocates the alternate approach as well.)

but computing barycentric coordiantes should not be more accurate but less, and if anything this method will give false positives.

Well, I'm not sure what you mean by that. Using barycentric coordinates is standard in point-triangle containment tests and intersection tests involving linear components and triangles (just check the literature). It's not inaccurate, and it won't return false positives. Although I'd have to see the code to be sure, I'd guess that even your sameSideLine() function uses barycentric coordinates.

If needed, I can provide links to articles, tutorials, books, and code samples that use barycentric coordinates to solve this problem. (Among other things, the book I mentioned earlier is a standard reference on collision detection, and it uses exactly the method I'm talking about here.) It's completely standard, so I'm not sure why you think there's something wrong with this approach.

There are different ways to compute the barycentric coordinates, of course, and the point of the method I'm advocating is to compute them in a way that avoids false negatives due to numerical error. Otherwise, there's nothing remarkable (or problematic) about the method in question.

The only thing I can guess is that we're not actually talking about the same thing here. In any case, there's nothing wrong with using barycentric coordinates for this, and that is in fact the standard solution to the problem.