I have a quick question about the two last unit test about the jittered ray and there results.
The first "Finding a single point on a jittered area light" you say when describing the change to apply to point_on_light about the call order for the sequence next function make compeltely sense, obviously, we will not get the expected value if we run them in the wrong order compared to the value you expect.
To pass the test with the exact same result table, I have to calculate the value for V, then U, so the reverse of you say.
For exemple with U = 0 and V = 0, if I do the same order, I get a Point of (0.35, 0.0, 0.15) so X and Z are reversed compared to the expected one. If I swap the calculation of U and V, then I get the expected order.
Something could be wrong in my code, but it is such a simple thing that I don't see where it could not work.
The second is on the next test "The area light with jittered samples", I get the exact same results for all the point expect the second one, where my result is 0.25 instead of 0.5.
Is the problem on my side (all the other test are passing, or could the result table be incorrect?
It is probably not that important in the end as the jittered value is fully random, and render look correct, but I wonder if I've done something wrong?!
The exact same code, but build using clang, the value of X and Z are inverted.
Ok. The C (and C++) language don't warranty the order where these function are going to be called. And the code generated by GCC and CLANG is really different. CLANG respect more the order (and produce less code XD) and GCC interleave both operations and seems to make the second calculation running before the first.
I can't think of a clean way to solve that without potentially making the code generated worse and less efficient :/
Edit: Well the second test may fail for a similar reason in fact. The build travis build matrix I do have for my raytracer work on that test with GCC under linux, but fail with clang under linux and Mac OS X...
That's really peculiar and I clearly don't see a way to fix that without going into some weird constructs to try to force the compiler to not optimise the code this way.