openmw.org

If we're going to have a non-sucky post-process system, it will at least need a way for post-process effects to request access to the previous frame, so it wouldn't be unthinkable to request multiple views of the scene, too.

It's a bit different since most other post-process shaders deal with things the renderer already has. It already rendered the previous frame, so it's just a matter of holding on to a copy for the next, and it already renders a depth map, so it can just provide it. The inputs are (would be) already there, it's just a matter of the shader declaring them to access them. But a multi-view input requires the engine to know about it ahead of time. It's not something the engine already has, and shaders don't have that kind of influence to change the rendering pipeline.

Lots of games implement post-process effects that require the renderer to output things that it normally wouldn't bother with. For example, in games with motion blur as an effect, (excluding when it's based only on the change of the view matrix as that always looks bad) vertices have a velocity vector associated with them which gets propagated through the vertex shader and rasteriser and gets saved to an extra FragData layer that would go unused otherwise. This velocity vector then controls the magnitude and direction of the blur applied to that pixel. Without the motion blur effect, the velocity vector isn't needed.

To clarify, the point of my point was that reprojection, as something with a post-process component, can't be done until we figure out and implement our post-processing framework.