I was thinking about playing a little with path tracing (just for fun, the game which I'm working on is a mobile game so I don't think it will need path tracing any time soon). So I was thinking about ripping apart HlmsPbs and move the material array and everything that is loaded in vertex/pixel shaders const buffers into a compute shader so I can send rays from the Metal backend.
I've already played with ray traced shadows but that was on top of the normal rasterized rendering. Now I was thinking about taking it to the next level and get a bit deeper in the HlmsPbs component and modify the preparePassHash() and fillBuffersFor*().
Is there any plan on doing a path traced/hybrid pipeline for Ogre? Is there any branch where this might have been experimented on to take a look at? Or some fork of Ogre?
It's just for fun, don't plan to take it production ready (unless of course there is good interest on something like this).
I'd be interested in ray-traced shadows or other path tracing functionality, but: (1) I would like to be able to use it on Windows, so not just Metal, and (2) in my fantasy world it wouldn't require work on my part much more than "flip a switch and it just works".
Ray/Path tracing is such an overloaded term. It can refer to many things:
"Something extra". It's the normal rasterization pipeline, but ray tracing is used for specific effects like shadows and reflections. This is the first thing everyone does, because it's the quickest to implement. Its performance budget can also be measured and tweaked in rays per pixel (or pixels per ray).
Special Algorithms: Rays aren't just shot to spice things up; but to provide real time effects that were difficult in raster, such as global illumination. DDGI is the most popular one in this category, and got implemented in Doom The Dark Ages to provide WYSIWYG realtime GI during development. DDGI also has the nicety that its performance budget can be tweaked by shooting a fixed amount of rays per frame, it just takes longer to converge over time if the number of rays per frame is low.
Full Ray/Path-tracing pipeline: Screw rasterization. Rays are shot from each pixel from the camera and where it hits, it means there's a triangle to shade. SLOW. Mario 64 RT fan project when this way.
Baking accelerator: Ray Tracing is not used for realtime, but for baking traditional lightmaps. But baking them super fast. Perhaps the idea is to bake them on your machine and support non-RTX cards. Or the idea is to bake them on the user's machine during loading (or by sections in open world); to balance disk and RAM without sacrificing real-time performance.
So when you say you want to implement Ray/Path-tracing and aren't sure which path to go, the question is... which of these 4 definitions were you aiming for?
Because Path tracing usually means 3 and 4 instead of 1 and 2. Everyone's got their own preferences.
Ray/Path tracing is such an overloaded term. It can refer to many things:
"Something extra". It's the normal rasterization pipeline, but ray tracing is used for specific effects like shadows and reflections. This is the first thing everyone does, because it's the quickest to implement. Its performance budget can also be measured and tweaked in rays per pixel (or pixels per ray).
Special Algorithms: Rays aren't just shot to spice things up; but to provide real time effects that were difficult in raster, such as global illumination. DDGI is the most popular one in this category, and got implemented in Doom The Dark Ages to provide WYSIWYG realtime GI during development. DDGI also has the nicety that its performance budget can be tweaked by shooting a fixed amount of rays per frame, it just takes longer to converge over time if the number of rays per frame is low.
Full Ray/Path-tracing pipeline: Screw rasterization. Rays are shot from each pixel from the camera and where it hits, it means there's a triangle to shade. SLOW. Mario 64 RT fan project when this way.
Baking accelerator: Ray Tracing is not used for realtime, but for baking traditional lightmaps. But baking them super fast. Perhaps the idea is to bake them on your machine and support non-RTX cards. Or the idea is to bake them on the user's machine during loading (or by sections in open world); to balance disk and RAM without sacrificing real-time performance.
So when you say you want to implement Ray/Path-tracing and aren't sure which path to go, the question is... which of these 4 definitions were you aiming for?
Because Path tracing usually means 3 and 4 instead of 1 and 2. Everyone's got their own preferences.
Point 3 in short. I am curious how much more simplified the rendering pipeline would be in Ogre if I moved the PBS calculations from the fragment shader inside a compute shader and just trace rays from camera (or from depth buffer reconstruction like in the RTShadows branch) and accumulate the results from bouncing. I don't want to start from scratch because Ogre provides all the infrastructure for loading, setting meshes up, etc. And I want to load the scene in the acceleration structure (which I kind of already did with the ray tracing shadows toy project), trace the rays and denoise and see what performance I get on mac and iPhone.
I was playing with a sample app on an iPhone 15 PM and I was surprised how well the tracing was running. It would eat battery like nothing else, but it worked.
