Jump to content
  • Advertisement
Sign in to follow this  
IMYT

Propagation in LPV

This topic is 2785 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone:

I am currently working on the implementation of Crytek's LPV algorithm. I am a little bit confused by the "propagation" part so I want to check with you guys if my understanding is correct.

For each cell in the light propagation volume I try to gather radiance from its neighbors. Two LPV buffers are used, in each step one is used to fetch SH Coefficients and another one is used as a render target, those two buffers will be swapped after each iteration.

According to my understanding in each iteration I should do the following steps:

for each neighboring cell (6 in total), i.e. "source"
for each face (except the one adjacent with current neighbor, 5 in total) of the center cell (i.e. destination cell).
I = SHBasis(inLightDir) * coeff * solidAngle / (4 * PI), where "inLightDir" is an unit vector points to the center of destination face from the center of the "source" cell and coeff is the coefficients stored in the "source" cell.
reprojection = SHCoeff(outLightDir) * (I / PI). outLightDir is an unit vector point to the center of destination face from the center of the "destination cell".
Add reprojection into both the accumulation buffer and another LPVBuffer.

Does any part of the above description look incorrect?

Thanks for your help.

Share this post


Link to post
Share on other sites
Advertisement
I think you're wrong on a few points.

For each neighbor cell, evaluate its SH to obtain the color that goes in the direction of the destination cell and scale it by the solid angle (like you said, solidAngle/(4*PI)). Then, create a SH that represents a cone of light pointed in that direction (actually it's not possible to represent that cone with 2 band SH, but you can get an approximation) and with the color that you extracted from the neighbor cell. Then, just add that cone of radiance to the destination cell's SH.
There's no need to process all the faces for every neighbor cell, in fact there's no need to process faces whatsoever. Also I do not understand which coefficients (coeff) you're talking about, there should be no need for such thing. I believe there's also no need for any kind of reprojection, just add the radiance that comes from the source cell to the destination cell.
Everything else seems correct.

Share this post


Link to post
Share on other sites

I think you're wrong on a few points.

For each neighbor cell, evaluate its SH to obtain the color that goes in the direction of the destination cell and scale it by the solid angle (like you said, solidAngle/(4*PI)). Then, create a SH that represents a cone of light pointed in that direction (actually it's not possible to represent that cone with 2 band SH, but you can get an approximation) and with the color that you extracted from the neighbor cell. Then, just add that cone of radiance to the destination cell's SH.
There's no need to process all the faces for every neighbor cell, in fact there's no need to process faces whatsoever. Also I do not understand which coefficients (coeff) you're talking about, there should be no need for such thing. I believe there's also no need for any kind of reprojection, just add the radiance that comes from the source cell to the destination cell.
Everything else seems correct.


Thanks for your reply.

By "coeff" I mean the SH coefficients stored in the cells. SHBasis(dir) * coeff is the way I calculate light intensity. "SHBasis()" is the function I used to calculate the basis function for a 2 band SH given a normal/direction. The dot product of SHBasis and coeff will restore the original function I think.

I read the propagation part for a second time but I still cannot agree with youhuh.gif.

I think in Crytek's paper they propagate light from the source cell to each face of the destination cell. In "Intensity propagation" section they said "Next we compute the ?ux on to each of the faces of the adjacent destination cell". So I guess they calculate the flux into each face separately. When calculating the flux value they use the intensity of center direction of the visibility cone as the average intensity over the solid angle. So they multiply this value by solidAngle/4*PI to get the total flux from source cell to this face. However the above calculation will give us a "flux" value, to store it in the destination cell we need to represent the flux value in Spherical Harmonics Coefficients, that is what "reprojection" part try to do. To calculate the SH Coeffs for this incident flux they put a new point light source at the center of the destination cell and let that point light source to "cause exactly as much flux as the face received". Then they add the new SH Coeffs for the incident flux to the destination cell's SH Coeffs.

Please correct me if I was wrong. I'm still new to this topic.smile.gif

And if you do not understand my English please tell me, I'll try my best to explain. (And I'm sorry for bad English skills, it is some kind of difficult for me to express my idea even in my native language.)

Share this post


Link to post
Share on other sites
By "coeff" I mean the SH coefficients stored in the cells. SHBasis(dir) * coeff is the way I calculate light intensity. "SHBasis()" is the function I used to calculate the basis function for a 2 band SH given a normal/direction. The dot product of SHBasis and coeff will restore the original function I think.
[/quote]

Ok, I'm not sure if the math terms are correct (I tend to ignore all the math mambo jumbo) but the idea is. I'm sorry for misunderstanding.

I think in Crytek's paper they propagate light from the source cell to each face of the destination cell. In "Intensity propagation" section they said "Next we compute the ?ux on to each of the faces of the adjacent destination cell". So I guess they calculate the flux into each face separately. When calculating the flux value they use the intensity of center direction of the visibility cone as the average intensity over the solid angle. So they multiply this value by solidAngle/4*PI to get the total flux from source cell to this face. However the above calculation will give us a "flux" value, to store it in the destination cell we need to represent the flux value in Spherical Harmonics Coefficients, that is what "reprojection" part try to do. To calculate the SH Coeffs for this incident flux they put a new point light source at the center of the destination cell and let that point light source to "cause exactly as much flux as the face received". Then they add the new SH Coeffs for the incident flux to the destination cell's SH Coeffs.[/quote]

I think what you're saying is partially true. The first LPV paper suggests that "flux per face" approach that you're mentioning. The problem with that approach is that it requires you to represent visibility cones using 2-band SHs which are too inaccurate for that purpose. Notice that the first band represents radiance going in all directions while the second band represents a 90º cone with a cosine weight, so there's no way you can represent a visibility cone accurately, in particular a narrow one.

I think it was due to this fact that in their second paper they suggested the approach I told you about. Even though they over complicated the explanation with mathematical jargon, at some point of the paper they did explain it in simple terms. When transferring radiance from one cell to another, they just get the color of the radiance that goes in the direction of the destination cell, scale it by the solid angle and build a SH that represents the 90º cone of radiance that goes in that direction.

Notice that unlike what you said, you don't create a point light on the destination cell, you creating a spot light (the cone) which represents the radiance that goes in that particular direction (e.g. left or right or anything else). If you create a point light, in the next propagation step you would be propagating the radiance you received back to its source cell because the radiance would have lost its directionality.

PS: your English is fine, no need to apologize.

Share this post


Link to post
Share on other sites

By "coeff" I mean the SH coefficients stored in the cells. SHBasis(dir) * coeff is the way I calculate light intensity. "SHBasis()" is the function I used to calculate the basis function for a 2 band SH given a normal/direction. The dot product of SHBasis and coeff will restore the original function I think.


Ok, I'm not sure if the math terms are correct (I tend to ignore all the math mambo jumbo) but the idea is. I'm sorry for misunderstanding.

I think in Crytek's paper they propagate light from the source cell to each face of the destination cell. In "Intensity propagation" section they said "Next we compute the ?ux on to each of the faces of the adjacent destination cell". So I guess they calculate the flux into each face separately. When calculating the flux value they use the intensity of center direction of the visibility cone as the average intensity over the solid angle. So they multiply this value by solidAngle/4*PI to get the total flux from source cell to this face. However the above calculation will give us a "flux" value, to store it in the destination cell we need to represent the flux value in Spherical Harmonics Coefficients, that is what "reprojection" part try to do. To calculate the SH Coeffs for this incident flux they put a new point light source at the center of the destination cell and let that point light source to "cause exactly as much flux as the face received". Then they add the new SH Coeffs for the incident flux to the destination cell's SH Coeffs.[/quote]

I think what you're saying is partially true. The first LPV paper suggests that "flux per face" approach that you're mentioning. The problem with that approach is that it requires you to represent visibility cones using 2-band SHs which are too inaccurate for that purpose. Notice that the first band represents radiance going in all directions while the second band represents a 90º cone with a cosine weight, so there's no way you can represent a visibility cone accurately, in particular a narrow one.

I think it was due to this fact that in their second paper they suggested the approach I told you about. Even though they over complicated the explanation with mathematical jargon, at some point of the paper they did explain it in simple terms. When transferring radiance from one cell to another, they just get the color of the radiance that goes in the direction of the destination cell, scale it by the solid angle and build a SH that represents the 90º cone of radiance that goes in that direction.

Notice that unlike what you said, you don't create a point light on the destination cell, you creating a spot light (the cone) which represents the radiance that goes in that particular direction (e.g. left or right or anything else). If you create a point light, in the next propagation step you would be propagating the radiance you received back to its source cell because the radiance would have lost its directionality.

PS: your English is fine, no need to apologize.
[/quote]


Thanks for your reply.

I didn't know there are two papers on LPV, I'll search for the second one.
And yes, they use a small spot light, thanks for your comments.


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!