ray: Fix ray/box intersection on systems without isnanf#224
Conversation
There was a typo in the code copied from the HAVE_ISNANF path that caused systems without isnanf (such as those using musl) to wrongly detect an intersection when there is none. Fixes ebassi#223
|
It would be awesome to add a testcase for this issue. |
|
Indeed, it would be awesome to have a test case. :-) |
|
I think merging this as a simple patch is reasonable, but I would recommend going with #225 later. I can rebase it. |
|
I wasn't sure about adding a test case, because due to the nature of the bug that would just be some random numbers for which it happens to fail instead of a real class of issues. But I can add the example from the bug report as a test. Can't think of a good name for such a test though. |
|
I was thinking of turning the code I used to find these random numbers into a test that does picking for ~1000 random coordinates like it would be done in clutter/mutter. Not sure how useful such non-deterministic tests would be though. |
|
I couldn't find a way to make a useful test with random positions, so I went with some hardcoded ones. This includes code based on Mutter/Clutter which was written by @GeorgesStavracas. Since Mutter is GPL and graphene is MIT, are you okay with using that code under MIT @GeorgesStavracas? |
This test is based on the picking code in Mutter/Clutter.
sbstnk
force-pushed
the
fix-ray-box-non-isnanf
branch
from
bc80fc9 to
e262a98
Compare
|
I'm fine with it 🙂 |
|
Would it make sense to open a separate PR with just the test since a test was specifically requested here and the merged fix did not have one? |
|
Yes, sure. |
5 participants
Fixes #223
Proposed changes:
HAVE_ISNANFcode path to match the behavior of theHAVE_ISNANFcode path.