Good job. It's a decent undertaking for a single person.
From a cursory glance, you might also be able to speed up the CPU backend by getting rid of the shared_ptrs and defining a stricter memory ownership model.
What's the story with regards to high dynamic range and tone mapping in raytracers in general? I only know of Filmic Blender to advertise this as a feature
I'm kind of with you, but I suppose its a culture/mind-set thing.
I hate reinventing the wheel, but who knows what kind of innovation could happen by combining unique experiences and lessons someone can learn for future use.
For instance, I made a laser pointer, I could have bought one for $10-$100, but I decided to make my own, learn about Electrical Engineering and optics. I never finished it, but it taught me a ton about EE along the way. Now I am quite comfortable with EE, except the parts I'm uncomfortable about ofc :)
To learn! Everyone should write a ray tracer (or three) on their own before even attempting to dive into a big open source production renderer. An established high profile project isn’t a great place to learn the fundamentals, since those parts are already done, and they don’t necessarily want people contributing who aren’t ready for it or are just there for personal learning purposes. It’s not fair to call it ‘reimplementing’, this project isn’t trying to be Blender. There are loads of other reasons to write a non-Blender renderer aside from learning, including writing one for games or interactive or scientific applications, needing special features, doing research and experimenting with rendering algorithms and data representations, needing a very small/fast/light renderer codebase, etc. etc.
TBH, I'm amazed at how efficient CUDA is compared to CPU on even a fairly lowly GPU. RTX 3050ti vs AMD Ryzen 5 6600H and I see close to 30x in pytorch.
It makes me wonder if CPUs will start adding a lot of matrix math specific extensions in the near future.
I thought ray tracing was very branchy type code which is not suited for GPU. If I have a bundle of rays strike an object, they could all scatter different directions and end up following very different paths in the scene. Is it hard to make all rays execute the same code at the same time?
19 comments
[ 0.16 ms ] story [ 49.7 ms ] threadFor a open source path tracer with a full glTF compatible material model and lighting and runs in the browser check out:
https://github.com/gkjohnson/three-gpu-pathtracer
Or if you want hardcore features look at Moonray from Dreamworks:
https://github.com/dreamworksanimation/openmoonray
From a cursory glance, you might also be able to speed up the CPU backend by getting rid of the shared_ptrs and defining a stricter memory ownership model.
I feel like nvcc supports at least 17 maybe even 20 already.
I hate reinventing the wheel, but who knows what kind of innovation could happen by combining unique experiences and lessons someone can learn for future use.
For instance, I made a laser pointer, I could have bought one for $10-$100, but I decided to make my own, learn about Electrical Engineering and optics. I never finished it, but it taught me a ton about EE along the way. Now I am quite comfortable with EE, except the parts I'm uncomfortable about ofc :)
It makes me wonder if CPUs will start adding a lot of matrix math specific extensions in the near future.