Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

accel struct: ray classif via 5d subdiv #51

Open
dafhi opened this issue Sep 21, 2020 · 3 comments
Open

accel struct: ray classif via 5d subdiv #51

dafhi opened this issue Sep 21, 2020 · 3 comments

Comments

@dafhi
Copy link

dafhi commented Sep 21, 2020

this looks interesting - http://artis.imag.fr/Members/Cyril.Soler/DEA/Ombres/Papers/Arvo.Sig87.pdf

@erichlof
Copy link
Owner

erichlof commented Sep 21, 2020

@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

@dafhi
Copy link
Author

dafhi commented Sep 22, 2020

@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
Copy link
Author

dafhi commented Dec 2, 2020

just noted the new update. simply stunning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants