accel struct: ray classif via 5d subdiv about three.js-pathtracing-renderer

[dafhi]

@dafhi
Hello David! It's been a while - hope you are doing well!

Thank you for the link to that interesting paper. I have not seen that one before.

Good!

Even though I can't use it directly, it has sparked some of my creative juices in using the ray direction itself to cull possible primitives from intersection test consideration. I'm currently looking into sparse voxel octrees as another way of storing data and ray tracing inside the browser. Some parts of this technique in the paper might help in that future situation.

Thanks again!
-Erich

I have yet to implement a triangle! Anyway, your recent results are remarkable.
I invented an accel on my first ray tracer, which wasn't implemented in my 2nd (the one you saw) because I couldn't remember the theory, but I think I've got it now. It basically happens only at the first hit but maybe I can extend that.

SVOs sound fun! One day I'll get there!

[dafhi]

just noted the new update. simply stunning

[erichlof]

@dafhi
Hello David! It's been a while - hope you are doing well!

Thank you for the link to that interesting paper. I have not seen that one before. I'm not sure if I can use it directly, partly because I don't quite understand the 5D math behind the approach and there is no source code (as is the case with most papers written decades ago), and partly because their approach was intended for CPU rendering which, according to their paper, tags bundles of rays. In our case in this repo, we use GPU only and one pixel ray is not allowed to see its neighbor rays from other pixels. We utilize the truly massively parallel architecture of the GPU to divide and conquer and make real time ray tracing possible. But with that decision to use the GPU, comes along the caveat that one ray cannot peek over and see what any other rays are doing. So we cannot bundle or group rays together in a 3D ray beam or 5D hypercube (as in the paper) like CPU renderers can, nor can the intersection candidate lists be shared from one ray to another (also as in the paper), even if they are right next to each other. The paper you linked to would probably work best for a more traditional CPU raytracer (as was the only choice back in the 1980's).

Even though I can't use it directly, it has sparked some of my creative juices in using the ray direction itself to cull possible primitives from intersection test consideration. I'm currently looking into sparse voxel octrees as another way of storing data and ray tracing inside the browser. Some parts of this technique in the paper might help in that future situation.

Thanks again!
-Erich