How can I directly stop drawing a pixel?

How can I directly stop drawing a pixel?

• hunb

  My main intention was avoiding the write of the the z-depth locally when ZWRITEENABLE=TRUE for the pass.

  (I could ask too: can the ZWRITEENABLE variable be set to false inside the pixel shader in some way ).

  Thanks to the answers of my previous question i can do that just modifying locally the z-depth and setting the pixel depth far enought to avoid pixel render and z-depth modification, but i was looking for a faster solution.

  If I set the alpha value to 0 so the pixel is "not rendered", I don't avoid writing the z-depth even if alphablend is enabled, do I

   

  Thanks again ^^

  
  

• Ti

  Ah, TexKill.
  
  Out of interest, does that also stop rendering the pixel to the depth buffer I'd imagine it would, but you never know with these things.........

  N

  
  
  

• Aamer

  Thanks very much to all of you.

  And thedo... be sure that i'll take a look and try your examples in a future, but now i'm starting some exams and don't know when i'll be able to give that a nice look. I'll notice you ^^

  
  

• Wee Bubba

  Dont think theres a way to do this directly. The pixel shader is called for every pixel and always must return a value - which will be your color. You could always set the alpha in this when you dont want to render and enable alpha blending, although this could leave you with artifacts if your objects arent rendered fromt he back to the front. What is the result you are after (ie description of what your trying to ultimately achieve)

  N

  
  
  

• Paul Fedory

  Sorry about answering so much, but i can't try it directly right now.

  So... when TexKill statement is executed inside the pixel shader, it "breaks" and coninues with the next one

  
  

• ravichandratbv

  there is an HLSL function called clip that "kills" the current pixel. Not sure what the performance impact is.
  
  
  

• Rainadaman

  OK. Ive not tried this at all, so this is just off the top of my head ;)

  OK, so if you are followinf the example in my previous post, we are rendering the output to the x component of our depth texture. Now if we change the texture to a format that supports more channels (You'll have to excuse me as I'm at work atm, with very little access to documentation - Vector2 texture maybe ), we could always store some more interesting values in the y,z, or w parts of the texture. So say for example we are rendering our depth texture using this pixel shader -

  struct PS_OUTPUT
  {
  float4 color : COLOR0;
  float4 depth : COLOR1;
  };
  

  PS_OUTPUT PixelShader(float2 textureCoordinate1 : TEXCOORD0, float2 depth : TEXCOORD1 ) : COLOR
  {
  PS_OUTPUT Out = (PS_OUTPUT)0;
  
  Out.color = tex2D(textureSampler1, textureCoordinate1).rgba;
  Out.depth.x = depth.x;
  return (Out);
  }

  we could put something into the out.depth.y which is say a 1 or a 0. Then in our screen rendering effect, in the pixel shader you could try something like

  #define XFILTER 0.002f
  #define YFILTER 0.002f

  float4 PixelShader(float2 textureCoordinate1 : TEXCOORD0) : COLOR0
  {
  float depth = (tex2D(depthSampler, textureCoordinate1).r)*(tex2D(depthSampler, textureCoordinate1).g)*0.0015f;
  
  float4 tex1 = tex2D(textureSampler, textureCoordinate1).rgba;
  float2 offset1=float2(XFILTER*depth,YFILTER*depth);
  float4 tex2 = tex2D(textureSampler, textureCoordinate1+offset1).rgba;
  float2 offset2=float2(XFILTER*depth,-YFILTER*depth);
  float4 tex3 = tex2D(textureSampler, textureCoordinate1+offset2).rgba;
  float2 offset3=float2(-XFILTER*depth,-YFILTER*depth);
  float4 tex4 = tex2D(textureSampler, textureCoordinate1+offset3).rgba;
  float2 offset4=float2(-XFILTER*depth,YFILTER*depth);
  float4 tex5 = tex2D(textureSampler, textureCoordinate1+offset4).rgba;
  
  float4 final = (tex1+tex2+tex3+tex4+tex5)/5;
  
  return (final);
  }

  The result in that case would be that no Depth of field was applied if the y (g) component of the 1st pixel shader was 0 (as anything mu;tiplied by zero is zero). Obviously this might not fit your case, but the theory is the same - write the data that says yes or no to another channel in the object rendering pass. Then use that value in the screen rectangle rendering pass.
  
  Hope this is of some use to you. I'd be interested if it works !
  
  N
  

  
  
  

• R Raghu

  Effectively, yes.
  
  

• oswaldorb

  The HLSL clip function will discard a pixel if any component of its input is less than zero. This maps to the texkill instruction.
  
  Yes, texkill prevents all updates to the render target, and to the depth and stencil buffers. Note that the rest of the pixel shader still executes (except, maybe, on ps_3_0 targets where you have true conditional statements - someone will have to look this up though I'm not sure if this is the case); the only change is that its output isn't written to the frame buffer.
  
  

• Carl Janssen

  Clip prevents all rendering of the pixel, including to the depth buffer. There is a performance penalty for using this instruction, though: shaders that include it will run significantly slower than ones that don't, because it prevents the hardware from doing the depth buffer updates in parallel with running the pixel shader like it normally would.
  
  In many cases the hardware will actually carry on running the shader even after you kill the pixel, and just store a flag to discard the eventual result, so if you're using this as an early-out optimisation, it's probably actually faster not to bother.
  
  Another way to prevent depth being updated is outputting a zero alpha from your shader, and using the AlphaTest renderstate (AlphaTest, unlike AlphaBlend, prevents depth being updated). AlphaTest is also not totally free, but I would guess usually a little faster than Clip.
  
  
  
• How can I directly stop drawing a pixel?