Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalizing a bvh::Triangle's normal... #23

Closed
newr5 opened this issue Dec 17, 2020 · 3 comments
Closed

Normalizing a bvh::Triangle's normal... #23

newr5 opened this issue Dec 17, 2020 · 3 comments
Labels
question Further information is requested

Comments

@newr5
Copy link
Contributor

newr5 commented Dec 17, 2020

Hi,
I'm a little further in my ray tracing application and now want to use the normals of the triangles to calculate the angle of incidence of a ray.

auto dirDotN = dot(rayDirection, triangle.n);
auto incidenceAngle = std::acos(dirDotN);

I discovered that the normal inside the bvh::Triangle is not normalized after it has been calculated.
I was under the impression that when a vector is used to express a direction (and a triangle's normal is such a vector), it should always be normalized...
I tried to add a normalize() call within the Triangle's constructor:

n = normalize(LeftHandedNormal ? cross(e1, e2) : cross(e2, e1));

but then the triangle's intersection routine doesn't work anymore.
(I used the same test program as I did in #18, and it doesn't report any hits).

Of course, I can add another member that contains the normalized normal, but I would like to understand why the intersection routine apparently cannot cope with a normalized normal...

Could you please enlighten me on this subject?

@madmann91 madmann91 added the question Further information is requested label Dec 17, 2020
@madmann91
Copy link
Owner

madmann91 commented Dec 17, 2020

The normal stored in the triangle is here to speed up the intersection routine. It's just some precomputed data to solve the system of equations coming from the Möller-Trumbore method. It just so happens to be the cross product of two edges, which is the (not unit length) normal of the triangle. It is possible to recompute this all the time during intersections (just like it is possible to store the points on the triangle, instead of storing one vertex and two edges), but that is obviously going to incur a performance penalty. The layout chosen here is exactly the one used in Embree, for performance reasons. If you want to, you can create your own triangle primitive that only stores three points, and just recompute e1, e2, and n everytime, but I am not sure that this is less expensive than computing the real normal by normalizing n after BVH traversal.

@newr5
Copy link
Contributor Author

newr5 commented Dec 17, 2020

Of course I would not want to recalculate everything every time.
I understand now that n is used internally by bvh::Triangle for performance reasons, and not supposed to be used externally for other purposes...

Thanks again for your quick reply...

@madmann91
Copy link
Owner

No problem. Closing the issue then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants