Question for velocity jitter

[kingofthebongo2008]

Hey Matt,
In the code the velocity is jittered.
I have seen the siggraph 2015 pptx and there it is said, that jitter is not used.
I have wondered what is the difference if i jitter only the velocity, other examples, jitter the frustum.

[TheRealMJP]

Hey there,

So the velocity is actually "un-jittered". When jittering is enabled, it's applied by adding an X/Y translation to the projection matrix that's used for rendering the scene. You can find the code for that right here: https://github.com/TheRealMJP/MSAAFilter/blob/master/MSAAFilter/MSAAFilter.cpp#L238. Right below that code the "jitterOffset" is computed, which is essentially the difference between the current and previous jitter. In other words, it's the movement from the previous frame to the current frame that's caused by jittering. This movement naturally shows up in the pixel shader's velocity calculations, so we basically undo that movement by subtracting jitterOffset from the calculated velocity. This is important for the case where the camera has no movement. If you didn't subtract the jitterOffset, then every frame you would end up re-projecting to the wrong pixel since your velocity would be non-zero.

As for the SIGGRAPH presentation, it is true that we did not use any jittering in The Order. Like I mentioned in the talk, jittering is really only useful when there's no geometry movement relative to the camera, since when that happens your sample positions are going to naturally move around all over the place. For that game the camera was always moving at least a little bit, and so I didn't take the time to integrate it into our engine. When I did the code sample for GitHub, I added it in since it's a commonly-used technique, and I wanted people to make the comparison of having it on and off. It also does end up looking nice in the demo, since the camera is totally static unless you move it with the mouse or keyboard.

[kingofthebongo2008]

Thank you, I have missed this part of the code.
I see that the velocity is represented in UV space, are there any difficulties working in Clip space instead?
May be precision issues?
And also do you think if some compression is applied to the velocity buffer will break the algorithm, like crytek packing in RG88 or another similar one compression and quantization.

Otherwise, great post. Thank you for sharing.

[TheRealMJP]

Clip space is fine too, I used UV space because it was convenient. It allows using the velocity as an offset to the screen UV coordinates when reprojecting, and the values don't need to be rescaled to fit into a [-1, 1] SNORM format. But either way, precision is very important. Any imprecision can cause you to reproject incorrectly, which will increase the bluriness of your results. So I would definitely recommend 16 bits for velocity if you can afford it. Otherwise you may need to clamp the velocity to a smaller range, and forego reprojection when velocity is greater than that range.