5 years ago I was 17 and learning to code C/C++ in a coding bootcamp (42). One of the projects was a simple C ray tracer. I really enjoyed working on the project and always loved computer graphics, so I decided to create my own path tracer from scratch, in C++, without using any third-party libraries.
I ended up working on it consistently for over a year, then sporadically when CG excitement hit me again. Recently I polished it and completed some unfinished features and decided to make it public, finally. It's a C++20 Path Tracer with a CPU renderer. It is able to render good-looking images with reasonable performance and sample count.
Btw this was initially coded without AI, but I've used it for the recent clean up and features. This project is a personal favorite of mine, and it can improve a lot, so I'd love to hear your feedback.
Then it makes sense to update the submission title. To me it reads as if the project was written completely without the help of AI (which might be a quality badge to some), but it is not 100% true then.
Anyhow, cool project ;)
1 week is enough to build out a full-featured application with AI if you know what you're doing and are using proper tooling.
You may want to use a better metric to quantify what AI tooling did in the project.
So write "almost without AI" in the title, then!
Also, as you're using full double/f64-precision all the time, you're leaving a fair bit of performance on the table: transcendentals (sin(), cos(), etc) in particular - can be a lot slower than when using f32, and generally double precision can be special-cased to particular areas of the renderer that need it (curve, sphere intersection, and some situations where volume scattering produces very small distances).
There's another issue that popped up on my quick naive profiling run: std::shared_ptr<Material> in the HitRecord/HittableLightSample is assigned/copied and destroyed a lot, and somehow these refcount operations show up as half of all samples on my profile (presumably because even if there's no hit and the pointer stays nullptr, the smart pointer still must check if there's anything to deallocate).
Should pass them by const refs really to avoid this.
The scene is only going to be loaded / unloaded all at once, you can just load the data into contiguous arrays and index from them. No need to use shared_ptr since lifetimes aren't that complex.
std::shared_ptrs can also (because they're implicitly for sharing) alias, so the compiler has to assume the worst and emit loads in other cases, and there's no way (unless a newer C++ version has introduced it and I haven't noticed?) to use '__restrict__' with shared ptrs.
However, I'd just condition it for the moment.
so:
invDirX = dirX != 0.0 ? 1.0 / dirX : 0.0; etc, etc for each dimension.
Obviously doing the != 0.0 comparison is not great, as it suffers from potential issues again (especially if you have denormals), but you can generally get away with it I've found in most cases.
One of my worries about AI is that doing these deep dives are a lot harder to justify.
I think many people go through the very popular https://raytracing.github.io/
There was a big influx of this when Sebastian Lague did his video series on building a ray tracer.
which is effectively the bible, and has been for years (I wrote mine and moved into the VFX industry when the Second edition was still out! - I feel old now)
Very fun! Packing data for GPU-side BVH was quite tricky.
Now this is how you catch attention
You need a second order effect, like “I did X using this thing I built Y”, where X is the actual impressive part and the Y is just an implementation detail. Maybe like that Roman Empire Names thing.
???
It sounds to me like there is some point in this project's history when both of the following were true:
1) It was a C++ raytracer
2) It was entirely human-written
So technically there is no lie here.
Out of 557 total commits in the repo, 510 have been done before the past 2 weeks. All those (minus 5 in 2023-2024) have been done on or before July 2022, months before ChatGPT had even launched.
Out of the 47 commits in the last 2 weeks, 26 were README updates / CI / docs. The remaining 21 commits are clearly cleanups, speedups, bugfixes, and tangential features like Blender import/export. Which leaves us with 505/557 commits (90%) if we're not generous --or 531/557 commits (95%) in the best case-- of non-AI commits to the repo.
OP clearly wrote most of the project by hand and has just been cleaning things up for public release the last couple weeks. Exactly as he disclosed in his comment.