- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I've come across a pretty serious BVH build bug in the embree. Sometimes, spatial builders would build an empty tree, and the other builders would build a functional, but horribly slow tree. I was able to trace it to the code computing area of box in the file default.h:
/*! Box to use in the builders. */
typedef BBox Box;
/*! Computes half surface area of box. */
__forceinline float halfArea(const Box& box) {
ssef d = size(box);
ssef a = d*shuffle<1,2,0,3>(d);
return extract<0>(reduce_add(a));
}
Problematic part is the last line of the routine, that adds the fourth, undefined component of the sse vector into the result, resulting in an undefined behaviour.
It worked before I had made some changes in my code. I think the change that broke it was that I started using the second ID attribute of build triangles, which overlaps the fourth component a point vector, and that caused injection of random bits into the equation.
I've also noticed the same problem in the volume function, although that one is not used at the moment.
I've come across a pretty serious BVH build bug in the embree. Sometimes, spatial builders would build an empty tree, and the other builders would build a functional, but horribly slow tree. I was able to trace it to the code computing area of box in the file default.h:
/*! Box to use in the builders. */
typedef BBox
/*! Computes half surface area of box. */
__forceinline float halfArea(const Box& box) {
ssef d = size(box);
ssef a = d*shuffle<1,2,0,3>(d);
return extract<0>(reduce_add(a));
}
Problematic part is the last line of the routine, that adds the fourth, undefined component of the sse vector into the result, resulting in an undefined behaviour.
It worked before I had made some changes in my code. I think the change that broke it was that I started using the second ID attribute of build triangles, which overlaps the fourth component a point vector, and that caused injection of random bits into the equation.
I've also noticed the same problem in the volume function, although that one is not used at the moment.
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for reporting this bug. This issue will show up in the original code only when rendering very large models (as this last component stores the object ID as an integer).

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page