Screen space reflections on Epsilon Engine
- 1. Screen Space Reflections on Epsilon Engine by Imanol Fotia
- 2. Motivations
- 3. Motivations
- 4. Previous reflection approaches ● Static Cubemaps ● Parallax Corrected Cubemaps ● Planar Reflections
- 5. Previous reflection approaches Static Cubemaps ● Pros ○ Fast to render ○ Pre-computed offline ○ low storage size ● Cons ○ Only works for objects that can be approximated as a point ○ Don’t take into account dynamic objects ○ Doesn’t take viewer position into account
- 6. Previous reflection approaches Parallax Corrected Cubemap ● Pros ○ Fast to render ○ Pre-computed offline ○ low storage size ○ Take viewer position into account ● Cons ○ Don’t take into account dynamic objects ○ Objects that are not in the boundaries are projected incorrectly
- 7. Previous reflection approaches Planar reflections ● Pros ○ Can create mirror-perfect reflections ○ High Accuracy ● Cons ○ Very expensive ○ Need to render the scene twice (at least)
- 8. The screen space approach Of course, SSR are not a perfect solution: ● Pros ○ Reflects static and dynamic objects accurately ○ Doesn’t depend on scene complexity ○ Works well along a deferred physically-based rendering pipeline ● Cons ○ Expensive ray-marching for high quality results ○ Limited information to work with
- 9. Our approach ● The calculation is done in a fragment shader at full resolution using a single ray. ● Instead of using importance sampling methods like BRDF, roughness is aggressively approximated by jittering the reflection ray according to the roughness value ● The ray-marching step is gradually incremented in each iteration, since in farthest objects details are not as relevant ● A mipmap chain is used to reduce the bandwidth overhead ● Infinite projection of missing data is countered by using binary refinement and a constant depth threshold
- 10. Required data Metallic (0, 1) Roughness (0, 1) View-Space Normal (RGB 16 F) Depth (FLOAT 32 F) Previous frame
- 11. Setting up The view-space position is reconstructed using the depth buffer With that, we can reconstruct the view vector from where the camera is looking Then, using the simple reflect function, get the reflection ray and start the ray-marching process.
- 12. Not as simple The former example is the less encountered in real life applications The following is one of the most usual problems we run into: Having encountered a false positive, the foreground object is infinitely projected
- 13. Not as simple Because we are working with very limited information, there might be no way to find the correct color for that collision To avoid this artifact, two methods are used: ● Binary Refinement if that also fails ● Constant Depth Threshold
- 14. Binary refinement Because the ray step is constant, whenever we have a collision, the only thing we know is that the collision occurred somewhere between the last and the current step. We just perform a binary search to get close to the actual value, or in pseudo code: for(maxRefinementSteps) depth = getDepth(projectedCoords); depthDiff = hitCoordinate.z - depth; if(depthDiff > 0.0) hitCoordinate += direction*0.5; else hitCoordinate -= direction*0.5;
- 15. Constant Depth Threshold But sometimes, the ray is way too far from the actual hit, so we simply discard the result using a numeric threshold:
- 16. Approximating Roughness Because we are using a single ray, importance sampling wont be performed, instead we jitter the reflection ray “randomly” to generate a roughness appearance. This is done with a hash function, that takes as seed the view-space position, so the camera movement is not as annoying to the user: Perfectly flat surface Rough surface
- 17. Hash function The hash function is defined as follows:
- 18. The Results
- 19. The Results
- 20. The Results