I think I know what the problem with the release version and the Ward BRDF might be. I have one assumption in the program I already know doesn't hold in all cases and the point it crashes and what I see in the call stack hint into the same direction. I have tried to minimize allocations in the inner loop of the raytracer, but that has a problem, I can't handle recursion any longer, so when a ray hits an object, which sends out another ray which in the end hits the original object again some data can't be damaged. I assume that is what happens, the stochastic rays in that area hit the plane and the sphere multiple times. In debug mode it seems to muddle through, but the release build (fully optimized, no debugging code) crashes.
I already have been thinking about how to solve that issue, as it it one key issue with the parallelization I intend to do. There the problem is even worse, I don't even know for sure how much state I have to preallocate, so it won't work the way I implemented it in any case. Therefor I have been planning to change that stuff to use a custom allocator, that should make it possible to have low overhead and solve the current problem. It also should enable me to start with parallelization. In addition I will change something closely related to that which should speed up the raytracer (a rather simple space/time trade off).
It is August and I can finally do the review of July. Ward BRDFAfter I had started the implementation of Ward BRDF last month I started early in the month to actually implement it in the raytracer. But before I could even start I still had to fix a p
Tracked: Aug 02, 15:54