2 replies to this topic

[brianasu]

Hi I've been working on implementing LPV in Unity3D. It looks quite nice but I can't seem to get my head around how to avoid flickering when objects or the light move. I'm assuming this is because the reflective shadow map depth values are changing. I noticed other people's videos have no flickering so I'm stumped.

I think I'm doing a lot of things wrong. Basically I 

 

1. Render depth normal and flux from light view. 
2. Recreate world pos from depth and frustum of the light camera.
3. I inject into the volume converting from world position to unwrapped light propagation volume texture space. (Is this correct? Or should I be using the light's view space -> LPV?) I inject the world normal offset by the surface normal and light direction dotted with the first 2 band SH multiplied by the luminance of the flux. (only SH no occlusion data yet). Because Unity3D has no gl point I have to setup a pixel matrix then render a small quad the size of a pixel to write to the unwrapped texture.
4. Propagate on the 6 corners.
5. Then I grab the world pos from the camera view and convert it to LPV tex coord. I then do a manual trilinear interpolation (Unity3D dx9 has no tex3D) in the shader of the SH values. Then dot the trilinear lerp value with the first 4 coefficients dot with the worldspace normals.

My questions are

What it means by calculating the weight of the surfel? Is that just how much I multiply the value when injecting it into the volume?

How do I prevent flickering?

- I heard of texel snapping but I'm not sure how to implement it.

- Does RSM downsampling help? 

- Is it caused because I'm doing a manual trilinear interpolation? I use the method stated in wikipedia.

 

Sorry for all the questions.

 

Here is a screen shot with exaggerated irradiance along with LPV textures rendered on top.

 

Thanks!

 

 

 

 

[Lightness1024]

Yes flickering is avoided by being super careful with RSM sampling and RSM generation. your RSM is sampled by the retroprojected region of your LPV into the RSM, this has to be snapped.

the RSM, has to be snapped itself when rendering just so that when camera moves and it is re-rendered, the pixels that were rendered in the overlapping zone (the zone that has RSM pixels in the last frame and that also has RSM pixels in this frame) get the exact same alignment.

generally it is done by doing that the RSM rendering camera moves by amount of the size of one RSM texel in view space. extra careful with the view space because the camera to render the RSM is positioned in world space, so you can't snap the position after calculating the position of the camera, that is actually difficult. you need to first calculate a "hint" position for your RSM rendering camera, using classic viewable frustum extents, or LPV region in your case (because it is better to make that the RSM perfectly covers the LPV). Then return into view-space by using the inverse of your just-found view matrix, then snap by using 1/resolution into up vector and side vector, then re-use the view matrix to change back into world space. recompute the view matrix from that new position.

 

also, you need to keep power of two dimensions, otherwise the sampling during injection will get aliased and you'll get flickering. doing the downsampling can help in different things; notably it significantly accelerates the method because, contrarily as what is written in the paper, injecting by using one vertex = 1 point primitive that can rasterize anywhere is actually a pipeline killer. so the less you inject the better you are, trust me.

if you have shader model 5, you may use unordered access writes, i don't know how that performs, could be better. not sure.

 

anyways, also incrase your RSM resolution, that helps.

 

last thing, the sampling during injection, is the second most important thing to ensure no flicker. you need to be sure that your UV calculation in the vertex shader (injection shader) falls on stable zones of the RSM and is not based on some too finely changing position.

like e.g. your LPV, it cannot move otherwise than by snaps of its own cell size. actually i didn't mention it, but its a strict requirement.

the LPV matrix as well has to be position snapped. this one is easier because you dictate that matrix, and you can make it axis aligned (no rotations) so the snapping is very easy to do. just a LPVmatrix[3][0] = LPVmatrix[3][0] - fmod(LPVmatrix[3][0], cellsize), and same thing for [1] and [2].

well anyways, you got the concept.

[brianasu]

Hi Lightness1024,

 

Thanks for the detailed reply. I couldn't really find any details on the actual RSM sampling except some shader code in the Crysis paper to downsample it. I'll try implementing what you mentioned. Is this similar to creating stable shadow maps?

 

Also does this also apply to using a perspective camera or only an orthographic projection? In case I wanted to do a spot light do I need to do anything special?

 

Unfortunately I'm stuck with opengl or dx9 right now. Unity3D version 3 also doesn't have tex3d.

 

Thanks again.