Jump to content
  • Advertisement
Sign in to follow this  
Nathan Drake

Injection Step of VPLs into 3D Grid

This topic is 979 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 Guys,

I'm currently trying to implement light propagation volumes in DirectX 11 and I've already done the RSM part which contains position, normal, depth and flux map generation. but for Injecting Virtual point lights into light propagation volumes, we have to inject lights into an x*y*z grid for which each element consists of 3 vectors for each of red, green and blue channels and each vector consists of four coefficients of  a two-band spherical harmonics.

 

by definition, it means just make a injection shader that gets 4 RSM render targets and apply those thing that i've written above, but for output from pixel shader I'm totally confused because it seems like we only multiply flux with Spherical Harmonics coefficients and return its value for each red, green and blue channel. is that correct ? so how we are going to use other maps in this step ?

 

and also it's unclear for me that how this result can bind with 3D grid.

 

 

 

Regards

Edited by Nathan Drake

Share this post


Link to post
Share on other sites
Advertisement

You mean you're only using the flux? How do you decide in which cell of the 3d grid you're going to write (so basically your SV_Position and SV_RenderTargetArrayIndex ) if you don't use the position from the RSM? You can get it from the depth or from the position texture, you don't need both of them. Also you need the normal to create the cosine lobe, you're probably using zonal harmonics coefficients, but you need to rotate the cosine lobe so that it faces towards your normal.

Share this post


Link to post
Share on other sites
struct VS_INJECTION_INPUT {
	uint posIndex : SV_VertexID;
};

struct VS_INJECTION_OUTPUT {
	float4 cellIndex : SV_POSITION;
	float3 normal : WORLD_NORMAL;
	float3 flux : LIGHT_FLUX;
};

struct GS_INJECTION_OUTPUT {
	uint depthIndex : SV_RenderTargetArrayIndex;
	float4 screenPos : SV_Position;
	
	float3 normal : WORLD_NORMAL;
	float3 flux : LIGHT_FLUX;
};

struct PS_INJECTION_OUTPUT {
	float4 redSH : SV_Target0;
	float4 greenSH : SV_Target1;
	float4 blueSH : SV_Target2;
};

// helper function
float4 SH_evaluateCosineLobe( float3 direction ) {
    direction = normalize( direction );
    
    return float4( SH_cosLobe_c0, -SH_cosLobe_c1 * direction.y, SH_cosLobe_c1 * direction.z, -SH_cosLobe_c1 * direction.x );
}

VS_INJECTION_OUTPUT VS_gpuInjection( VS_INJECTION_INPUT input ) {
	int2 RSMsize;
	worldPosition.GetDimensions( RSMsize.x, RSMsize.y );
	int3 rsmCoords = int3( input.posIndex % RSMsize.x, input.posIndex / RSMsize.x, 0 );
	
	float3 posWorld = worldPosition.Load( rsmCoords );
	float3 normalWorld = worldNormal.Load( rsmCoords );
	float3 flux = lightFlux.Load( rsmCoords );
	
	VS_INJECTION_OUTPUT output;
	output.cellIndex = float4( int3( (posWorld - lpv_minCorner) / lpv_cellSize + 0.5 * normalWorld ), 1.0 );
	
	output.normal = normalWorld;
	output.flux = flux;
	
	return output;
}

[maxvertexcount(1)]
void GS_gpuInjection( point VS_INJECTION_OUTPUT input[1], inout PointStream<GS_INJECTION_OUTPUT> OutputStream ) {
	GS_INJECTION_OUTPUT output;
	
	output.depthIndex = input[0].cellIndex.z;
	output.screenPos.xy = (float2(input[0].cellIndex.xy) + 0.5) / lpv_size.xy * 2.0 - 1.0;
	// invert y direction because y points downwards in the viewport?
	output.screenPos.y = -output.screenPos.y;
	output.screenPos.zw = float2( 0, 1 );

	output.normal = input[0].normal;
	output.flux = input[0].flux;
	
	OutputStream.Append( output );
}

PS_INJECTION_OUTPUT PS_gpuInjection( GS_INJECTION_OUTPUT input ) {
	PS_INJECTION_OUTPUT output;
	
	if( length( input.normal ) < 0.01 ) {
		discard;
	}
	
	
#if 0
	// this is what the paper says
	float4 SHcoeffs = SH_evaluateCosineLobe( input.normal );
	
	output.redSH = SHcoeffs * input.flux.r;
	output.greenSH = SHcoeffs * input.flux.g;
	output.blueSH = SHcoeffs * input.flux.b;
#else
	// the SHcoeffs model an intensity function
	// thus the integral over all intensities (over the sphere) should be the original flux
	// and that integral = Pi * totalFlux, so divide by Pi
	float4 SHcoeffs = SH_evaluateCosineLobe( input.normal ) / Pi;
	
	output.redSH = SHcoeffs * input.flux.r;
	output.greenSH = SHcoeffs * input.flux.g;
	output.blueSH = SHcoeffs * input.flux.b;
#endif
	
	return output;
}

this is his code for injection part, and he just multiplied flux with SHcoeffs(that obtained by normals) for PS injection output.

Edited by Nathan Drake

Share this post


Link to post
Share on other sites

finally i understood that i have to make 3 dimensional texture array of which each slice of array is slice of grid. and each cell is a point of virtual point lights.

 

but as you see for VS_INPUT, he used VertexID (or position in some codes)

struct VS_INJECTION_INPUT {
	uint posIndex : SV_VertexID;
};

now my question is how long each slices have a distance with each other ? am i have to make an array of points from 3D texture array and insert it into a vertex buffer ?

how can i obtain this VertexID from CPU side and pass it to the vertex buffer ?

Edited by Nathan Drake

Share this post


Link to post
Share on other sites

I understood what SV_VertexID is and how it can be used when we want to render without any buffer and tell us the index of a vertex.

in his VS code, he calculated cellIndex in this way:

output.cellIndex = float4( int3( (posWorld - lpv_minCorner) / lpv_cellSize + 0.5 * normalWorld ), 1.0 );

what is that lpv_minCorner ? i saw that he used that minCorner during loading models, can someone guide me what is it and how can i generate it from CPU or GPU side ?

Edited by Nathan Drake

Share this post


Link to post
Share on other sites

The 3D texture in LPV represents an actual AABB in world space, in your example it's represented with min/max corners and you're trying to calculate the cell you need to write in (i.e. the cell where the VPL is located), the 0.5 * normal shift might be confusing, it's a bias to reduce bleeding. You can find most the information you need here

Share this post


Link to post
Share on other sites

So far, i've made a grid that covers all of the environment with 3 textures that each of them used for red, green and blue SH, compute all those Injection codes and write on these textures.

 

now I wanna do the propagation part. this step was quite hard to understand at first, but hopefully with many other articles and references, i can have a overall snapshot of what i have to do theoretically.

 

the propagation is used to make sure every that we not have any zero valued grid element in our environment. so each grid element will propagate into sixth directions and each of those directions has 5 cosine lab projections, so at the end, we have 30 projections for each grid element.

 

for implementation, based on other articles (because i didn't understand a way that described in original LPV paper), we must have two rendering pass. first one is our previous injection rendering result ( i guess), samples neighboring cells and then render into different texture.  since i have 3 textures from injection part, i also have to make another 3 textures to write my computations output from previous textures. is that right ? do you have any suggestion for implementation of this part ?

Edited by Nathan Drake

Share this post


Link to post
Share on other sites

Two passes won't accomplish much, each pass a cell will propagate to its neighbors, that's too local to call it global illumination. You will need a bunch of passes (depending on the 3D texture resolution), and to do so you can use the sets of 3d textures you described, using ping pong buffering (first pass you read from A and write to B, then read from B and write to A and so on).

 

This is quite an expensive procedure, and to reduce the iterations the crytek paper introduces cascaded LPV.

Edited by tuccio

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!