intersectRayTriangle returns barycentric Z 4.5

[joobei]

when fed with
ray origin glm::vec3(0,0,0);
ray direction glm::vec3(0,0,-1);

and 3 vertices (already transformed to world coordinates):
v0 = glm::vec3(0.5,0.5,-4.5);
v1 = glm::vec3(-0.5,-0.5,-4.5);
v2 = glm::vec3(0.5,-0.5,-4.5);

It returns barycentric coordinates a = 0, b = 0.5 , c = 4.5
If I understand correctly, a+b+c should equal to 1.

They don't seem to be barycentric coordinates, they seem like.. normal cartesian coordinates of the intersection point.

[nlguillemot]

for any poor soul wandering upon this post in confusion,

the baryPosition output uses barycentric coordinates for the x and y components. The z component is the scalar factor for ray.

That is,

1.0 - baryPosition.x - baryPosition.y = actual z barycentric coordinate

if you compute the point inside the triangle that corresponds to those barycentric coordinates, you'll find the exact same answer as if you did:
origin + direction * baryPosition.z

tl;dr:

[ v0.x v1.x v2.x ]   [ baryPosition.x ]
[ v0.y v1.y v2.y ] * [ baryPosition.y ]
[ v0.z v1.z v2.z ]   [ (1.0 - baryPosition.x - baryPosition.y) ]

is equal to

origin + direction * baryPosition.z

[evg-zhabotinsky]

Well, I feel it is exactly the way it should work, but should not it be documented?
I've noticed that sum of baryPosition coordinates is not 1 but really could not understand what the hell is going on until I've read the above explanation.
EDIT: as of version 0.9.6.1:
In fact barycentric coordinates are [(1 - bary.x - bary.y); bary.x; bary.y], which is a bit counter-intuitive.
So intersection result is as follows:
v0 * (1 - bary.x - bary.y) + v1 * bary.x + v2 * bary.y
= origin + direction * bary.z
= intersection coordinates (cartesian)
Also, triangle vertices must go counter-clockwise when looking along the ray for them to intersect.
(That is, in context of OpenGL, only front face of triangle intersects the ray, not the back one.)

[JesseTG]

Can this be considered closed?

[evg-zhabotinsky]

Barycentric coordinates are still not explained in docs.
Should I check that my observations still hold (except for backface culling, #194) and post a 1-line pull request?
Edit: Actually, I am not sure how to edit docs properly. No relevant code changed (except removal of culling), so my observations still hold.

[Groovounet]

If somebody is interested to improve / fix this code, I think a pull request is the best approach. :)

[Groovounet]

This issue should be fixed in master branch for GLM 0.9.9 release.

Thanks for reporting,
Christophe

[Squareys]

It looks like now the barycentric z coordinate is never assigned, instead the value passed for it is merely divided by a determinant? (https://github.com/g-truc/glm/blob/master/glm/gtx/intersect.inl#L89)

Also, the test case doesn't actually use the z coordinate for the triangle vertices which makes it impossible to catch this "bug" (?) with it: https://github.com/g-truc/glm/blob/master/test/gtx/gtx_intersect.cpp#L12

I guess you can always calculate it from the other two coordinates, in which case a little documentation about that would be very appreciated.

Or am I missing something?

Kind regards, Jonathan.

[edap]

thank you @nlguillemot for your explanation

[jpanneton]

@nlguillemot
Note that when calling glm::intersectRayTriangle(orig, dir, v0, v1, v2, baryPosition),
intersection = orig + baryPosition.z * dir
should in theory be equal to
intersection = v0 + (baryPosition.x * (v1 - v0) + baryPosition.y * (v2 - v0))
However, in practice, the latter is more accurate than the former.
In fact, I was playing with a 3D Gaussian function the other day and as we all know, this function usually converge to 0 pretty quickly. So, I tried to draw a contour line around it at mouse position using glm::intersectRayTriangle and it turned out that using the latter allowed me to draw the contour line further and more accurately than the former (using the resulting y-coordinate of the intersection to generate it).

So, if floating-point precision is an issue, use the latter.
Otherwise, since it's faster to compute, use the former.