Sign in to follow this  
lipsryme

DX11 Single big shader buffer for hardware instancing

Recommended Posts

lipsryme    1522

I saw this part from the battlefield3 presentation (http://dice.se/wp-content/uploads/GDC11_DX11inBF3_Public.pdf) on page 30 where they show how they transfer transformations of each instance to the shader using a single big buffer and a const buffer with indices to index this buffer at the right position using the SV_InstanceID semantic. Can someone tell me what exactly this buffer is ? 

This part here: 

Buffer<float4> instanceVectorBuffer : register(t0);

 

I'm not too familiar with buffers in directx11 beyond constant buffers...

Isn't register(t0) for texture slots ?  Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

And last how would I set such a buffer in the DX11 API ?

Share this post


Link to post
Share on other sites
Hodgman    51229

The MSDN documentation is very lacking in explaining these concepts...

IIRC:

The t registers are similar to the c registers, but they're designed for random memory access patterns (like texture lookups) rather than constant memory access patterns (e.g. it's assumed that every pixel will read the same constants, but may read different texels). You can bind both textures and DX11 buffer objects to the t registers and then load values from them in the shader.

 

You bind values to the t registers using *SSetShaderResources, which takes "shader resource views". You can create a view of a texture, which is the common case, but you can also create a view of a buffer.

 

As mentioned above, you should prefer this method of binding buffers to t registers when you're going to be performing random lookups into the buffer. If every pixel/vertex/etc is going to read the same values from the buffer, then you should bind it to a c register using the usual method.

Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

No, in a regular transformation matrix that's been constructed from a traslation + rotation + scale, the 4th row/column (depending on your conventions) will always be [0,0,0,1] so you can hard-code that value in the shader to save some space in the buffer.

 

I'm still not as experienced with DX11 as I am with DX9, so I hope that's correct cool.png

Edited by Hodgman

Share this post


Link to post
Share on other sites
lipsryme    1522

Yes I meant 3 x float4 (sorry for the confusing syntax smile.png  )

Alright thanks for the info.

 

EDIT: By the way this buffer then should be dynamic, correct? Since I need to put in or remove elements during rendering.

Edited by lipsryme

Share this post


Link to post
Share on other sites
kauna    2922

The advantage of a buffer over cbuffer is the size (128mb vs 64kb, although in typical scenario 2-4mb should be enough) which allows you to store a frame worth of data to the buffer, also it allows you to fill the buffer once so you'll minimize buffer updates to minimum. The minor inconvenience is that you'll be able to store only float data (probably you can get around this with some bit manipulation method). 

 

The buffer is pratically a texture and you'd bind it as vertex shader resource.

 

 

[source]
float4x4 GetInstanceMatrix(uint InstID,uint Offset)
{
uint BufferOffset = InstID * ElementsPerInstance + StartIndex + Offset;
 
// InstID = InstanceID
// ElementsPerInstance, how many float4's there are per drawn instance (typically 3 for a single mesh if 4x3 matrices are used)
// StartIndex = location of the first float4 inside the buffer for the first instance
// Offset (used to retrieve bone matrices)
 
float4 r0 = InstanceData.Load(BufferOffset + 0);
float4 r1 = InstanceData.Load(BufferOffset + 1);
float4 r2 = InstanceData.Load(BufferOffset + 2);
float4 r3 = float4(0.0f,0.0f,0.0f,1.0f);
 
return float4x4(r0,r1,r2,r3);
}
 
[/source]
 
Inside the vertex shader you may use the above code to retrieve the transform matrix for each vertex. 
 
Cheers!

Share this post


Link to post
Share on other sites
Matias Goldberg    9576

The advantage of a buffer over cbuffer is the size (128mb vs 64kb, although in typical scenario 2-4mb should be enough)

Another important advantage from a tbuffer over a cbuffer is that cbuffer suffer from constant waterfalling, which make them a horrible fit for scalable hw accelerated vertex skinning (indexing the constant buffer with a different index in each vertex).

When you're not suffering constant waterfalling, cbuffers can be faster though, for well.... constant data.

Share this post


Link to post
Share on other sites
Sock5    162

Ok this may sound stupid, but what about just using regular instancing?Has this method been benchmarked against regular instancing with a second vertex buffer?

Share this post


Link to post
Share on other sites
kauna    2922

Ok this may sound stupid, but what about just using regular instancing?Has this method been benchmarked against regular instancing with a second vertex buffer?

 

If you mean that regular instancing means using a second vertex buffer, I remember reading some years ago that one of the big companies wrote that shaders using a second vertex stream will take a performance hit. It had something to do with the fact that the vertex declaration structure gets pretty big. 

 

I think that the problem with classic instancing is also, that you'll need to define a vertex declaration for each different vertex shader type where the parameters are different. Normally of course you would just have a transform matrix as instance data for the vertex shader, but what if you need also some other per instance parameters, such as color, inverse world matrix or some other parameter which makes your instance different from the others. When using second vertex stream you'll need a different vertex declaration for each case.

 

In the case of the generic buffer, you'll need just one vertex declaration since the vertex data won't change. After it is the job of the vertex shader to extract the desired data from the generic buffer. Of course you'll need to make sure that the buffer contains the expected data. Also, since the buffer can be pretty big you'll be updating data much less often to the graphic card, which reduces API calls. Also, the program side logic get simpler when you don't need to worry so much about "will the data fit to the buffer or not, do I have to make several draw calls instead of one".

 

Of course, under D3D11 the instancing just another parameter that you can access in the vertex shader (InstanceID) and after that you may read or generate the instancing data in the best way you can imagine, though vertex streams can't be randomly accessed. 

 

Cheers!

Share this post


Link to post
Share on other sites
lipsryme    1522

So..I've created the buffer like this:

	D3D11_BUFFER_DESC instanceBufferDesc = {};
	
	instanceBufferDesc.Usage = D3D11_USAGE_DYNAMIC;
	instanceBufferDesc.BindFlags = D3D11_BIND_SHADER_RESOURCE;
	instanceBufferDesc.ByteWidth = sizeof(XMFLOAT4);
	instanceBufferDesc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
	instanceBufferDesc.MiscFlags = 0;
	instanceBufferDesc.StructureByteStride = 0;

	hr = this->device->CreateBuffer(&instanceBufferDesc, NULL, &this->instanceTransformBuffer);

 

is that correct so far ?

 

 
Now I'm a little clueless on how to create the shader resource view from this.
Any ideas ? Do I set the shader resource view description to NULL ?
 
This seems to work without errors:
	D3D11_SHADER_RESOURCE_VIEW_DESC shaderResourceDesc;
	shaderResourceDesc.Format = DXGI_FORMAT_R32_FLOAT;
	shaderResourceDesc.ViewDimension = D3D11_SRV_DIMENSION_BUFFER;
	shaderResourceDesc.Buffer.FirstElement = 0;
	shaderResourceDesc.Buffer.ElementWidth = 4;
	shaderResourceDesc.Buffer.ElementOffset = 0;

	hr = this->device->CreateShaderResourceView(this->instanceTransformBuffer, &shaderResourceDesc, &this->instanceTransformBuffer_SRV);

 

 

Now if the above is correct, how can I basically push float4's onto the buffer ?

Edited by lipsryme

Share this post


Link to post
Share on other sites
kauna    2922

Use DeviceContext->Map(...) with D3D11_MAP_WRITE_DISCARD to get a pointer to an empty the buffer.

 

Fill the data (with memcpy for example) and the call Unmap. Don't write outside of the buffer! It will cause memory corruption and may even hang your computer.

 

It doesn't really make sense to use the buffer for one float, but I assume it to be a test. I used DXGI_FORMAT_R32G32B32A32_FLOAT as the buffer format since handling things as float4 makes maybe a bit more sense. You'll need at least 3x4 floats to store a typical matrix, but of course probably you'll want to allocate some megabytes of storage (within reason of course).

 

Cheers!

Edited by kauna

Share this post


Link to post
Share on other sites
lipsryme    1522

Got it working perfectly thanks !

So the only way is to define a constant max size for this buffer inside the code...?

Worst case would be 3 x numInstances which could add up to quite a lot.

 

By the way I'm currently assigning each instance the 3 float4's inside a loop. I assume it would be more efficient to add them inside a structure which I then copy once using memcopy or is that neglectable?

 

I'm only doing map / unmap once, but I'm filling the data like this:

// Update buffer
XMMATRIX worldTransform = XMMatrixTranspose(XMLoadFloat4x4(&scenePrimitive->worldTransform));			
for(int u = 0; u < 3; u++)
{	
XMStoreFloat4(&pInstanceData[(numInstances * 3) + u], worldTransform.r[u]);
				}

basically in the loop that goes through every instance and counts them to do the instanced draw call at the end.

 

Also am I correct in thinking that I am restricted to one specific material (texture and properties from const buffer) for every unique instance group ?

update: Just read about putting them inside a Texture2DArray...so for specific material properties would it make sense to also store them inside a buffer like I did with the transforms ? Might be overkill for e.g. booleans but still...

Edited by lipsryme

Share this post


Link to post
Share on other sites
mrheisenberg    362

Got it working perfectly thanks !

So the only way is to define a constant max size for this buffer inside the code...?

Worst case would be 3 x numInstances which could add up to quite a lot.

 

By the way I'm currently assigning each instance the 3 float4's inside a loop. I assume it would be more efficient to add them inside a structure which I then copy once using memcopy or is that neglectable?

 

I'm only doing map / unmap once, but I'm filling the data like this:

// Update buffer
XMMATRIX worldTransform = XMMatrixTranspose(XMLoadFloat4x4(&scenePrimitive->worldTransform));			
for(int u = 0; u < 3; u++)
{	
XMStoreFloat4(&pInstanceData[(numInstances * 3) + u], worldTransform.r[u]);
				}

basically in the loop that goes through every instance and counts them to do the instanced draw call at the end.

 

Also am I correct in thinking that I am restricted to one specific material (texture and properties from const buffer) for every unique instance group ?

update: Just read about putting them inside a Texture2DArray...so for specific material properties would it make sense to also store them inside a buffer like I did with the transforms ? Might be overkill for e.g. booleans but still...

Wait, can I ask something - how does your draw call look like?I mean, do you call DrawIndexedInstanced with only 1 buffer?Or with 1 vertex buffer and 1 empty instance buffer/or having the ID inside the instance buffer data?

Share this post


Link to post
Share on other sites
lipsryme    1522

I only use a vertex buffer yes, not using instance buffer at all but giving it per instance transformations via a float4 buffer that holds these.
They're then accessed inside the shader using the instanceID.

Edited by lipsryme

Share this post


Link to post
Share on other sites
mrheisenberg    362

I only use a vertex buffer yes, not using instance buffer at all but giving it per instance transformations via a float4 buffer that holds these.
They're then accessed inside the shader using the instanceID.

Hm I tried to do the same as you to see how it compares to normal instancing, however nothing leaves the vertex shader.The Shader Debugger detects that the sphere goes in:
87adedad25e8a33b.pngHowever nothing gets rasterized.It can't be the view matrix, since it works on normal rendering, so it has to be something to do with the large buffer object.Did you ever experience such an issue?

Share this post


Link to post
Share on other sites
lipsryme    1522

Hmm I do remember having some issues that no pixel shader was being executed....can't remember exactly what it was though...

Have you made sure that your InputLayout is correctly set ?

 

Should look something like this:

	D3D11_INPUT_ELEMENT_DESC lo[] = 
	{
		{"POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 },
		{"TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 1, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0},
		{"NORMAL",   0, DXGI_FORMAT_R32G32B32_FLOAT, 2, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0},
		{"TANGENT",  0, DXGI_FORMAT_R32G32B32_FLOAT, 3, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0},
	};

 

fourth parameter is important here as this is the vertex buffer slot...

 

Also try to make sure the float4s are combined in the correct order.

I've had a lot of problems with this. In the end I had to transpose the matrix first and then pass them to the cbuffer because otherwise you'd loose the 4th row because

if you pass your 3 rows something like:

cbufferData.data[i] = worldMatrix.r[i];

 

you're passing only 3 vectors of this matrix and you will loose important data if you pass the rows instead of the columns.

That's why I changed it over to columns and it worked:

float4x4 GetInstanceTransform(uint instID, uint offset)
{
	uint BufferOffset = instID * elementsPerInstance + startIndex + offset;

	float4 c0 = InstanceDataBuffer.Load(BufferOffset + 0);
	float4 c1 = InstanceDataBuffer.Load(BufferOffset + 1);
	float4 c2 = InstanceDataBuffer.Load(BufferOffset + 2);
	float4 c3 = float4(0.0f, 0.0f, 0.0f, 1.0f);

	float4x4 _World = { c0.x, c1.x, c2.x, c3.x,
						c0.y, c1.y, c2.y, c3.y,
						c0.z, c1.z, c2.z, c3.z,
						c0.w, c1.w, c2.w, c3.w };


	return _World;
}

I don't see a way around that...but maybe someone does ?

Edited by lipsryme

Share this post


Link to post
Share on other sites
lipsryme    1522

Yes but that only applies to float4x4 values coming from the cbuffer. It doesn't apply to what you use inside the vertex shader and also not for float4's.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By isu diss
       I'm trying to code Rayleigh part of Nishita's model (Display Method of the Sky Color Taking into Account Multiple Scattering). I get black screen no colors. Can anyone find the issue for me?
       
      #define InnerRadius 6320000 #define OutterRadius 6420000 #define PI 3.141592653 #define Isteps 20 #define Ksteps 10 static float3 RayleighCoeffs = float3(6.55e-6, 1.73e-5, 2.30e-5); RWTexture2D<float4> SkyColors : register (u0); cbuffer CSCONSTANTBUF : register( b0 ) { float fHeight; float3 vSunDir; } float Density(float Height) { return exp(-Height/8340); } float RaySphereIntersection(float3 RayOrigin, float3 RayDirection, float3 SphereOrigin, float Radius) { float t1, t0; float3 L = SphereOrigin - RayOrigin; float tCA = dot(L, RayDirection); if (tCA < 0) return -1; float lenL = length(L); float D2 = (lenL*lenL) - (tCA*tCA); float Radius2 = (Radius*Radius); if (D2<=Radius2) { float tHC = sqrt(Radius2 - D2); t0 = tCA-tHC; t1 = tCA+tHC; } else return -1; return t1; } float RayleighPhaseFunction(float cosTheta) { return ((3/(16*PI))*(1+cosTheta*cosTheta)); } float OpticalDepth(float3 StartPosition, float3 EndPosition) { float3 Direction = normalize(EndPosition - StartPosition); float RayLength = RaySphereIntersection(StartPosition, Direction, float3(0, 0, 0), OutterRadius); float SampleLength = RayLength / Isteps; float3 tmpPos = StartPosition + 0.5 * SampleLength * Direction; float tmp; for (int i=0; i<Isteps; i++) { tmp += Density(length(tmpPos)-InnerRadius); tmpPos += SampleLength * Direction; } return tmp*SampleLength; } static float fExposure = -2; float3 HDR( float3 LDR) { return 1.0f - exp( fExposure * LDR ); } [numthreads(32, 32, 1)] //disptach 8, 8, 1 it's 256 by 256 image void ComputeSky(uint3 DTID : SV_DispatchThreadID) { float X = ((2 * DTID.x) / 255) - 1; float Y = 1 - ((2 * DTID.y) / 255); float r = sqrt(((X*X)+(Y*Y))); float Theta = r * (PI); float Phi = atan2(Y, X); static float3 Eye = float3(0, 10, 0); float ViewOD = 0, SunOD = 0, tmpDensity = 0; float3 Attenuation = 0, tmp = 0, Irgb = 0; //if (r<=1) { float3 ViewDir = normalize(float3(sin(Theta)*cos(Phi), cos(Theta),sin(Theta)*sin(Phi) )); float ViewRayLength = RaySphereIntersection(Eye, ViewDir, float3(0, 0, 0), OutterRadius); float SampleLength = ViewRayLength / Ksteps; //vSunDir = normalize(vSunDir); float cosTheta = dot(normalize(vSunDir), ViewDir); float3 tmpPos = Eye + 0.5 * SampleLength * ViewDir; for(int k=0; k<Ksteps; k++) { float SunRayLength = RaySphereIntersection(tmpPos, vSunDir, float3(0, 0, 0), OutterRadius); float3 TopAtmosphere = tmpPos + SunRayLength*vSunDir; ViewOD = OpticalDepth(Eye, tmpPos); SunOD = OpticalDepth(tmpPos, TopAtmosphere); tmpDensity = Density(length(tmpPos)-InnerRadius); Attenuation = exp(-RayleighCoeffs*(ViewOD+SunOD)); tmp += tmpDensity*Attenuation; tmpPos += SampleLength * ViewDir; } Irgb = RayleighCoeffs*RayleighPhaseFunction(cosTheta)*tmp*SampleLength; SkyColors[DTID.xy] = float4(Irgb, 1); } }  
    • By Endurion
      I have a gaming framework with an renderer interface. Those support DX8, DX9 and latest, DX11. Both DX8 and DX9 use fixed function pipeline, while DX11 obviously uses shaders. I've got most of the parts working fine, as in I can switch renderers and notice almost no difference. The most advanced features are 2 directional lights with a single texture  
      My last problem is lighting; albeit there's documentation on the D3D lighting model I still can't get the behaviour right. My mistake shows most prominently in the dark side opposite the lights. I'm pretty sure the ambient calculation is off, but that one's supposed to be the most simple one and should be hard to get wrong.
      Interestingly I've been searching high and low, and have yet to find a resource that shows how to build a HLSL shader where diffuse, ambient and specular are used together with material properties. I've got various shaders for all the variations I'm supporting. I stepped through the shader with the graphics debugger, but the calculation seems to do what I want. I'm just not sure the formula is correct.
      This one should suffice though, it's doing two directional lights, texture modulated with vertex color and a normal. Maybe someone can spot one (or more mistakes). And yes, this is in the vertex shader and I'm aware lighting will be as "bad" as in fixed function; that's my goal currently.
      // A constant buffer that stores the three basic column-major matrices for composing geometry. cbuffer ModelViewProjectionConstantBuffer : register(b0) { matrix model; matrix view; matrix projection; matrix ortho2d; }; struct DirectionLight { float3 Direction; float PaddingL1; float4 Ambient; float4 Diffuse; float4 Specular; }; cbuffer LightsConstantBuffer : register( b1 ) { float4 Ambient; float3 EyePos; float PaddingLC1; DirectionLight Light[8]; }; struct Material { float4 MaterialEmissive; float4 MaterialAmbient; float4 MaterialDiffuse; float4 MaterialSpecular; float MaterialSpecularPower; float3 MaterialPadding; }; cbuffer MaterialConstantBuffer : register( b2 ) { Material _Material; }; // Per-vertex data used as input to the vertex shader. struct VertexShaderInput { float3 pos : POSITION; float3 normal : NORMAL; float4 color : COLOR0; float2 tex : TEXCOORD0; }; // Per-pixel color data passed through the pixel shader. struct PixelShaderInput { float4 pos : SV_POSITION; float2 tex : TEXCOORD0; float4 color : COLOR0; }; // Simple shader to do vertex processing on the GPU. PixelShaderInput main(VertexShaderInput input) { PixelShaderInput output; float4 pos = float4( input.pos, 1.0f ); // Transform the vertex position into projected space. pos = mul(pos, model); pos = mul(pos, view); pos = mul(pos, projection); output.pos = pos; // pass texture coords output.tex = input.tex; // Calculate the normal vector against the world matrix only. //set required lighting vectors for interpolation float3 normal = mul( input.normal, ( float3x3 )model ); normal = normalize( normal ); float4 ambientEffect = Ambient; float4 diffuseEffect = float4( 0, 0, 0, 0 ); float4 specularEffect = float4( 0, 0, 0, 0 ); for ( int i = 0; i < 2; ++i ) { // Invert the light direction for calculations. float3 lightDir = -Light[i].Direction; float lightFactor = max( dot( lightDir, input.normal ), 0 ); ambientEffect += Light[i].Ambient * _Material.MaterialAmbient; diffuseEffect += saturate( Light[i].Diffuse * dot( normal, lightDir ) );// * _Material.MaterialDiffuse; //specularEffect += Light[i].Specular * dot( normal, halfangletolight ) * _Material.MaterialSpecularPower; } specularEffect *= _Material.MaterialSpecular; //ambientEffect.w = 1.0; ambientEffect = normalize( ambientEffect ); /* Ambient effect: (L1.ambient + L2.ambient) * object ambient color Diffuse effect: (L1.diffuse * Dot(VertexNormal, Light1.Direction) + L2.diffuse * Dot(VertexNormal, Light2.Direction)) * object diffuse color Specular effect: (L1.specular * Dot(VertexNormal, HalfAngleToLight1) * Object specular reflection power + L2.specular * Dot(VertexNormal, HalfAngleToLight2) * Object specular reflection power ) * object specular color Resulting color = Ambient effect + diffuse effect + specular effect*/ float4 totalFactor = ambientEffect + diffuseEffect + specularEffect; totalFactor.w = 1.0; output.color = input.color * totalFactor; return output; }   Edit: This message editor is driving me nuts (Arrrr!) - I don't write code in Word.
    • By Mercesa
      Hey folks. So I'm having this problem in which if my camera is close to a surface, the SSAO pass suddenly spikes up to around taking 16 milliseconds.
      When still looking towards the same surface, but less close. The framerate resolves itself and becomes regular again.
      This happens with ANY surface of my model, I am a bit clueless in regards to what could cause this. Any ideas?
      In attached image: y axis is time in ms, x axis is current frame. The dips in SSAO milliseconds are when I moved away from the surface, the peaks happen when I am very close to the surface.

       
      Edit: So I've done some more in-depth profiling with Nvidia nsight. So these are the facts from my results
      Count of command buffers goes from 4 (far away from surface) to ~20(close to surface).
      The command buffer duration in % goes from around ~30% to ~99%
      Sometimes the CPU duration takes up to 0.03 to 0.016 milliseconds per frame while comparatively usually it takes around 0.002 milliseconds.
      I am using a vertex shader which generates my full-screen quad and afterwards I do my SSAO calculations in my pixel shader, could this be a GPU driver bug? I'm a bit lost myself. It seems there could be a CPU/GPU resource stall. But why would the amount of command buffers be variable depending on distance from a surface?
       
       
      Edit n2: Any resolution above 720p starts to have this issue, and I am fairly certain my SSAO is not that performance heavy it would crap itself at a bit higher resolutions.
       
    • By turanszkij
      In DirectX 11 we have a 24 bit integer depth + 8bit stencil format for depth-stencil resources ( DXGI_FORMAT_D24_UNORM_S8_UINT ). However, in an AMD GPU documentation for consoles I have seen they mentioned, that internally this format is implemented as a 64 bit resource with 32 bits for depth (but just truncated for 24 bits) and 32 bits for stencil (truncated to 8 bits). AMD recommends using a 32 bit floating point depth buffer instead with 8 bit stencil which is this format: DXGI_FORMAT_D32_FLOAT_S8X24_UINT.
      Does anyone know why this is? What is the usual way of doing this, just follow the recommendation and use a 64 bit depthstencil? Are there performance considerations or is it just recommended to not waste memory? What about Nvidia and Intel, is using a 24 bit depthbuffer relevant on their hardware?
      Cheers!
       
    • By gsc
      Hi! I am trying to implement simple SSAO postprocess. The main source of my knowledge on this topic is that awesome tutorial.
      But unfortunately something doesn't work... And after a few long hours I need some help. Here is my hlsl shader:
      float3 randVec = _noise * 2.0f - 1.0f; // noise: vec: {[0;1], [0;1], 0} float3 tangent = normalize(randVec - normalVS * dot(randVec, normalVS)); float3 bitangent = cross(tangent, normalVS); float3x3 TBN = float3x3(tangent, bitangent, normalVS); float occlusion = 0.0; for (int i = 0; i < kernelSize; ++i) { float3 samplePos = samples[i].xyz; // samples: {[-1;1], [-1;1], [0;1]} samplePos = mul(samplePos, TBN); samplePos = positionVS.xyz + samplePos * ssaoRadius; float4 offset = float4(samplePos, 1.0f); offset = mul(offset, projectionMatrix); offset.xy /= offset.w; offset.y = -offset.y; offset.xy = offset.xy * 0.5f + 0.5f; float sampleDepth = tex_4.Sample(textureSampler, offset.xy).a; sampleDepth = vsPosFromDepth(sampleDepth, offset.xy).z; const float threshold = 0.025f; float rangeCheck = abs(positionVS.z - sampleDepth) < ssaoRadius ? 1.0 : 0.0; occlusion += (sampleDepth <= samplePos.z + threshold ? 1.0 : 0.0) * rangeCheck; } occlusion = saturate(1 - (occlusion / kernelSize)); And current result: http://imgur.com/UX2X1fc
      I will really appreciate for any advice!
  • Popular Now