The Stupid, Lazily Optimized pathtracer Which is an Erroneous and Slow Tarnation (S.L.O.W.E.S.T) ok so this project doesn't actually use the balance heursitic quite right, and I am too lazy to update the definitions but just keep that in mind This project uses BVH to speed up rendering a lot, it also uses NEE (balance heuristic) to speed up convergence time by a lot. I will explain some of this in the bottom. Press SPACE to render, please use turbowarp (https://turbowarp.org/1030649679) for this. Basically, the BVH is done by surrounding all the triangles in the scene with their minimum bounding box, then you find the closest 2 bounding boxes and combine them aswell, you keep doing this until there is only one bounding box left (the root node), this creates a binary tree with bounding boxes in each node except at the leaves. To traverse the tree, you check if the ray intersects against the root node, and if it does, recursively traverse down the left child until it doesn't hit anything or hits a leaf node, then traverse recursively down the right child. For the NEE, at each ray bounce, you shoot the ray from intersection point to a random light source AND a random ray based on the material (which is why it's called MIS, multiple importance sampling), then you weigh the contribution with both directions' PDF (probability density function), currently it's weighed using the balance heuristic (provably not *much* worse than the best method for that scenario, according to veach anyway) which is just pdf1/pdf1+pdf2 (you would see it with scary math notations in the wild, but for 2 random directions, this is it). Thanks to @completeness for helping a lot with it If you have any questions, just can ask in the comments The scene in the thumbnail uses only 54 samples with res 1. Also happy pride month #ray #raymadness #path #pathmadness
