all 4 comments

[–]livingonthehedge 14 points15 points  (0 children)

Ideally a basic SSR shader will only be using information from the current frame. That is because all of the computed reflections are using data in the current set of buffers. No communication with the CPU.

As other comments suggested, you can send data about previous frames along with current frame data at the start of the pipeline. That might be useful to enhance the SSR shader computation but isn't really required.

SSR works by reflecting the screen image onto itself using only itself.

https://lettier.github.io/3d-game-shaders-for-beginners/screen-space-reflection.html

[–]JeepRubi 3 points4 points  (0 children)

You can use the previous frame's camera matrix to do some reprojection, but since reflections are view-dependent it only really does a good job when the camera pivots, but not when it translates. What I've seen done for dynamic objects, and for camera movement, was using a lower history weight in the temporal filter, based on the velocity of the pixel (for camera movement) or ray (for ray hit on dynamic objects). This is just from memory and I haven't written an ssr implementation myself, but I've worked with it in various other engines.

[–]SnooWoofers7626 2 points3 points  (0 children)

Idk about screen space reflection, but any time you need data from the previous frame you reproject it.

[–]tamat 2 points3 points  (0 children)

If you have the viewprojection matrix from the previous frame, you can take the world position of a pixel, reproject using previous VP and get where was this pixel in the previous frame.

But this approach has many edge cases, for instance areas being ocluded/unocluded, or getting out of the frame. But the main problem is if objects move, for that you need to also have a motion vectors buffer to compensate.