If you (_Sauce_) are still looking for a parametric method, then I can contribute this basic method:
Assume a ray in parameter form
r(k) := r0 + k * rt
with its origin and track vectors both given in the same co-ordinate system as the triangle.
The triangle itself with its 3 vertices
{ p0, p1, p2 }
can be expressed in parameter form as
t(u,v) := p0 + u * ( p1 - p0 ) + v * ( p2 - p0 )
where
u,v >= 0 and u+v <= 1
If both have a common point then
r0 + k * rt == p0 + u * ( p1 - p0 ) + v * ( p2 - p0 )
and this equation system of 3 equations needs to be solved for { k, u, v } once. Care must be taken for k because it would become infinity if the ray is parallel to the plane where the triangle lies in. In such case you have to abort further calculations with a "miss", of course.
Ray-triangle intersection
If you use haegarr's method, getting the intersection point's texture coordinates becomes very easy:
You have to multiply intersection_text with the sizes of the texture image to obtain the texel.
So I suggest you to use haegarr's method.
My method is good for convex polygons and other kinds of testing: for example picking.
t1 = p1_text-p0_text;t2 = p2_text-p0_text;intersection_text = p0_text + t1*u + t2*v;You have to multiply intersection_text with the sizes of the texture image to obtain the texel.
So I suggest you to use haegarr's method.
My method is good for convex polygons and other kinds of testing: for example picking.
Quote:Original post by _Sauce_
now according to the slides in the Princeton lecture, in order for P to be inside the triangle, a and b must both be in the range 0..1. My 3D math isn't the best but I recognised that a is simply the scalar projection of Z onto X, and b is the scalar projection of Z onto Y, where Z = P - v3, X = v2 - v3, and Y = v1 - v3. Correct?
This is where you are going wrong. The a, b in the slide aren't the scalar projections, they are fractions of the triangle side length.
If you interpret a and b as scalar projections instead, then your test needs to be changed to:
0 < a < |Y|
0 < b < |X|
or equivalently,
0 < a/|Y| < 1
0 < b/|X| < 1
also, the slide fails to mention the additional constraint
0 < a/|Y| + b/|X| < 1
Author
Okay, so it appears there's some really funky stuff going on inside my raytracer. I've done a bit of investigating and tested on a less complex model (a dodecahedron). I used the surface normals for shading in order to get a better idea of what's going on.
As you can see, the edges of the tris don't line up at all. In fact, all of those pentagons are inverted around the origin. The blue one on top there belongs on the bottom of the model, towards the back. left is right, up is down, and in is out.
Kinda sucky. Now I gotta figure out just why that is. The model data is fine (I've viewed the mesh in meshlab just fine) so somewhere along the line things are getting messed up.
As you can see, the edges of the tris don't line up at all. In fact, all of those pentagons are inverted around the origin. The blue one on top there belongs on the bottom of the model, towards the back. left is right, up is down, and in is out.
Kinda sucky. Now I gotta figure out just why that is. The model data is fine (I've viewed the mesh in meshlab just fine) so somewhere along the line things are getting messed up.
Author
Quote:Original post by iMalc
I found this using google, and it looks pretty good, doing just what you appear to want.
As much as I appreciate all the suggestions, I'd prefer to get at least one of these algorithms working correctly before attempting to use a more efficient one. It's like changing multiple variables in a scientific experiment and then trying to figure out what effect each one had.
I'm currently using Szec's method, which isn't quite working (see failed dodecahedron) but after I've done some uni work, I'll draw up a diagram of what the algorithm is doing and work out exactly why it's broken (if it's even the algorithm that's the problem)
The problem is with the transformations of the vertices, wrong order of them or something like that.
The problem is that the red angles aren't 90 degrees. To achieve the real u and v coordinates the lines should be parallel to a and b like the green ones.
Author
You're right c1984.
I've finally found some material on the barycentric method I was attempting to use before, including a nifty flash demo illustrating it a little more clearly.
http://www.blackpawn.com/texts/pointinpoly/default.html
After all this time googling "ray-triangle intersection", I tried "point in triangle" instead. The number of results increased significantly! :)
I've finally found some material on the barycentric method I was attempting to use before, including a nifty flash demo illustrating it a little more clearly.
http://www.blackpawn.com/texts/pointinpoly/default.html
After all this time googling "ray-triangle intersection", I tried "point in triangle" instead. The number of results increased significantly! :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement