Raycast failure

[obsius]

Haven't had time to get all the data, but visually I have some screenshots. When I disable the BVH, and use un-indexed raycasting I'm seeing this:

With the indexing:

Profile:

Those lower vectors mimic the upper ones when the vector X,Y fails to hit the topography at the vector origin Z (tries a higher Z value until an intersect is found). You can see that these vectors are failing to detect an intersection on the initial downward slope, but then intersect later on the gradual upwards slope (far right side). In the non-indexed raycast it works properly and those vectors never continue past the topography.

It's only happening in one "column" of triangles, it raycasts properly if it was a little more left in the next screenshot:

And works properly if it was a little more right in the next one:

It is only between those two arrows where this failure is happening. Works fine everywhere else. I'll try to put some data together later this week, and I'll try an earlier version.

[obsius]

Here's a quick video to show the error. Those really long vectors are precisely inside of that problem column.

[obsius]

Looks like it's actually working but failing to report the first hit properly. With firstHitOnly = false I get the behavior I'd expect.

[gkjohnson]

Hey again @obsius! Thanks for the repot and the detailed description. If you get a chance providing a minimal html page along with the data that demonstrates the problem would be really helpful and I can dig in more quickly.

When I disable the BVH, and use un-indexed raycasting With the indexing:

Can you explain what you mean by with indexing and unindexed here?

[obsius]

@gkjohnson Yeah, I mean to say that the stock raycaster in THREE works, but when I enable the BVH I see the anomaly. I don't have the data currently but I can work on getting it out. Was hoping something would pop out from the screenshots as it'll take a bit of time to get the data extracted.

If I had to guess, and this could be totally wrong, but some of the triangles in that "column" so to speak are flipped, the diagonal line alternates back and forth from each grid cell to the next, an artifact of how the delaunay triangulation algorithm ran. I wonder if that has something to do with why just in that one spot the further intersection point is returned instead of the closer intersection when firstHitEnabled = true.

I should note that THREE.DoubleSide is set on the mesh. If I recall correctly I had to set this to ensure that raycasts from either side of a triangle would work. In this case the initial intersection would be from the bottom, and the second intersection is from the top since the topography dips down and back up, and the raycast line is completely horizontal starting below the topography.

[gkjohnson]

Got it. So just to be clear everything works correctly when firstHitOnly === false and it only fails when firstHitOnly === true. The algorithm for traversal when firstHitOnly is true is different than when it's false so it sounds like there's a bug there -- I wouldn't expect any of the triangulation or material attributes to only affect the first hit case.

I don't have the data currently but I can work on getting it out. Was hoping something would pop out from the screenshots as it'll take a bit of time to get the data extracted.

Nothing immediately sticks out. I think I'm gonna have to see the bounds and dig into the traversal a bit more once the data's available.

I assume you're working with version 0.3.2 of the library, as well, right?

[obsius]

Correct, when setting firstHitOnly = true the issue occurs. Yeah, 0.3.2 is the version I'm using.

[gkjohnson]

Hey @obsius I wanted to check back in to see if you were able to make any data available. I'm very interested in tracking this issue down.

Thanks!

[gkjohnson]

Hey @obsius I've finally gotten around to finding the source of some intermittent test failures when randomly raycasting (#180) and I suspect it's fixed your issue here, as well. Specifically we weren't always returning the proper first hit point then the ray entered the area where two child bounding boxes intersected and the projection of the ray origin was within that intersection region so it wouldn't have happened often.

It's been fixed and published in v0.3.5 so when you have a chance give it a try and let me know if that fixes it for you.

[obsius]

@gkjohnson Awesome, great to hear. I've been super busy lately, but I'll pull the latest version of this library, dig around for the data I was using to test with, and let you know what I find. Thanks for the heads up.

[gkjohnson]

Gonna close this for now because I'm fairly certain the issue fixed in v0.3.5 is the same one -- if the issue comes up again feel to open a new issue or we can revisit this one.

Thanks again for the report!