[Edited by - Ganga on December 7, 2009 7:55:56 PM]
Implementing Light Propagation Volumes :)
Author
I'm currently working on Light propagation volumes, as crytek's siggraph09 course note expressed. I'm confused by the different coordinate systems those articals used. It seems I have to change some of the signs of face normal to dot with SH coeffs when the final scene lighting. Also volume radiance seems to attenuate too fast by distances when propagating. It's still a long way to go~ Any how, show pic. Wish your suggestions :)
[Edited by - Ganga on December 7, 2009 7:55:56 PM]
[Edited by - Ganga on December 7, 2009 7:55:56 PM]
Put it on imageshack.us please, this site asks for login. I'm working on it too and I'll be glad to communicate.
Author
Quote:Original post by KRIGSSVIN
Put it on imageshack.us please, this site asks for login. I'm working on it too and I'll be glad to communicate.
Done. Thanks for your site, but it is blocked by our Big Brother's F**king GFW. Using a proxy to upload images was really slow :<. I've decide to inject some light lobes with the same direction to check the dot normal issue.
Thanks for another hosting. I.e you injected (0.282; 0; 0; 0) and this picture is done without propagation phase, which you have troubles on, don't you?
Author
Yes, that was only propagated once( to each 6 adjacent cells ) and found my original lighting methods are totally wrong. I injected one point light and drew some instanced balls at each volxel, whose radius were scaled with the radiance value of that volxel. as the following picture.
(hemisphere and it's color indicates radiance value.)
It shows that, quite strangely, to gain the correct propagated radiance direction, i have to use SHProjectCone(offsets * float(-1,1,-1), PiOver2) instead of SHProjectCone(offsets, PiOver2). And during rendering, using dot(float4(1.0f, faceNormal.yzx), sampledSHCoeffs) for each color creates the right lighting. I think that maybe caused by the different coordinate systems of the SH functions i used for calculating and rendering. Something At last seemed a little more fixed is like these:
(lamp icon indicates a point light, and line indicates directional light lobes)
Although the original cell appears to be too bright, and grid artifacts is obvious without "Anisotropic upsampling", which i'm not quite understand currently~
[Edited by - Ganga on December 8, 2009 7:02:21 PM]
(hemisphere and it's color indicates radiance value.)
It shows that, quite strangely, to gain the correct propagated radiance direction, i have to use SHProjectCone(offsets * float(-1,1,-1), PiOver2) instead of SHProjectCone(offsets, PiOver2). And during rendering, using dot(float4(1.0f, faceNormal.yzx), sampledSHCoeffs) for each color creates the right lighting. I think that maybe caused by the different coordinate systems of the SH functions i used for calculating and rendering. Something At last seemed a little more fixed is like these:
(lamp icon indicates a point light, and line indicates directional light lobes)
Although the original cell appears to be too bright, and grid artifacts is obvious without "Anisotropic upsampling", which i'm not quite understand currently~
[Edited by - Ganga on December 8, 2009 7:02:21 PM]
Quote:Original post by Ganga
Yes, that was only propagated once( to each 6 adjacent cells ) and found my original lighting methods are totally wrong. I injected one point light and drew some instanced balls at each volxel, whose radius were scaled with the radiance value of that volxel. as the following picture.
(hemisphere and it's color indicates radiance value.)
It shows that, quite strangely, to gain the correct propagated radiance direction, i have to use SHProjectCone(offsets * float(-1,1,-1), PiOver2) instead of SHProjectCone(offsets, PiOver2). And during rendering, using dot(float4(1.0f, faceNormal.yzx), sampledSHCoeffs) for each color creates the right lighting. I think that maybe caused by the different coordinate systems of the SH functions i used for calculating and rendering. Something At last seemed a little more fixed is like these:
(lamp icon indicates a point light, and line indicates directional light lobes)
Although the original cell appears to be too bright, and grid artifacts is obvious without "Anisotropic upsampling", which i'm not quite understand currently~
Uhm, you might not have recognized it, but [IMG]-tags are not supported. See this for proper display.
Quote:Original post by Ganga
It shows that, quite strangely, to gain the correct propagated radiance direction, i have to use SHProjectCone(offsets * float(-1,1,-1), PiOver2) instead of SHProjectCone(offsets, PiOver2). And during rendering, using dot(float4(1.0f, faceNormal.yzx), sampledSHCoeffs) for each color creates the right lighting. I think that maybe caused by the different coordinate systems of the SH functions i used for calculating and rendering.
Lets assume we have a vector N(x;y;z). Then its projection onto SH basis for first two bands is:
c.x = 0.5 / sqrt(pi);c.y = -N.y * 0.5 / sqrt(pi) * sqrt(3);c.z = N.z * 0.5 / sqrt(pi) * sqrt(3);c.w = -N.x * 0.5 / sqrt(pi) * sqrt(3);This is constant for all implementations, thus coordinate system doesn't matter. You use N.yzx, pay attention to your offsets multiplier (-1; 1; -1) and look at my equation again.
Question to you: do you scale your point light injection coefficients (0.282; 0; 0; 0) by some normalization factor, not counting light intensity? All coefficients - point light, hemispherical light injection, normal - all must be normalized to work correctly and this seems to be the place I'm quite stuck with atm.
Author
Quote:Original post by phresnel
Uhm, you might not have recognized it, but [IMG]-tags are not supported. See this for proper display.
Thank you!
Author
Quote:Original post by KRIGSSVIN
Lets assume we have a vector N(x;y;z). Then its projection onto SH basis for first two bands is:c.x = 0.5 / sqrt(pi);c.y = -N.y * 0.5 / sqrt(pi) * sqrt(3);c.z = N.z * 0.5 / sqrt(pi) * sqrt(3);c.w = -N.x * 0.5 / sqrt(pi) * sqrt(3);
This is constant for all implementations, thus coordinate system doesn't matter. You use N.yzx, pay attention to your offsets multiplier (-1; 1; -1) and look at my equation again.
Question to you: do you scale your point light injection coefficients (0.282; 0; 0; 0) by some normalization factor, not counting light intensity? All coefficients - point light, hemispherical light injection, normal - all must be normalized to work correctly and this seems to be the place I'm quite stuck with atm.
Oh yes! My coords are left-handed (right, up, forward). I didn't see into the Polynomials for the first four coeffs. So it seems (-Nrm.y, Nrm.z, -Nrm.x) is just the right one.
I used the following to inject point lights:
void ps_InjectPointLight( g2p_PosColorSlice Input, out float4 redCoeff : SV_Target0, out float4 greenCoeff : SV_Target1, out float4 blueCoeff : SV_Target2){ const float band1SHFuncVal = Poly_00((float3)0); redCoeff = float4( Input.vColor.r * band1SHFuncVal, 0, 0, 0); greenCoeff = float4( Input.vColor.g * band1SHFuncVal, 0, 0, 0); blueCoeff = float4( Input.vColor.b * band1SHFuncVal, 0, 0, 0);}where Poly_00() constantly returns 0.282. and for hemispherical lights, coeffs are calculated by SHProjectCone() from cry's doc.
Directly multiply coeffs and color really has problem. Since the size of propagation volume cell changes, e.g. from 1 units to 2 units, the amount of calculated radiance would be 2^3 times more with the same light... Maybe it has no problem with Injecting Reflective Shadow Map's hemispherical lights, since the count of lights changed too with a bigger cell. So I think there may be a multiplier related to the cell size for non-virtual point/hemispherical lights, which makes radiance a constant with the same light in the same spatial scale. I'm trying to work on it :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement