-
Notifications
You must be signed in to change notification settings - Fork 76
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
Path-tracing with Nonlinear projections (for wider FOVs) #10
Comments
Thanks, looks like the call to q2vkpt/src/refresh/vkpt/shader/path_tracer.h Line 484 in a4de8e9
|
Yes, you just need to make sure to also change all the code that uses global_ubo.VP |
My practical knowledge of path tracing is too limited to be any help here, but as someone who's spent far too much time trying to come up with needlessly clever raster projections to do this in other engines without the post-process step (spoiler alert: haha nope), I'm super excited to see if you can make this work. 😃 |
vp = vector projection? found this reference:
|
This is the view-projection matrix, going from world-space to clip-space. |
Ah I see now, thanks. Here's a plan, if you wanna check it: Standard Projection MatricesThese matrices are used for standard projection:
Non-linear projection functionsNOTE: Non-linear projections can't be performed by matrices—it's a linear algebra afterall. To swap out the standard projection with a non-linear one—any time the above matrices are multipled by a vector, we have to replace them with calls to custom projection functions:
Where to change?Add projection functions to global_ubo.h:
Modify to use inverse projection ( q2vkpt/src/refresh/vkpt/shader/path_tracer.h Line 282 in a4de8e9
Modify to use forward projection (
|
The plan looks good! Let me know if you need any additional information. There might be the need to fix some of the reconstruction filter but we'll have to see the results first. |
Congrats on the project 🎉 I wanted to add that path-tracing isn't just the holy grail for lighting—it also frees the renderer to use different projections for showing wider FOVs without terrible distortion:
Before I jump in—could you weigh in with your thoughts? I imagine this wouldn't be hard to do since each pixel just has to map to a different ray determined by the chosen projection, but I'm not sure if anything in the pipeline assumes the standard projection. Thanks for your thoughts.
The text was updated successfully, but these errors were encountered: