Strange striations in my bloom effect?

Started by
8 comments, last by JackOfAllTrades 12 years, 8 months ago
[attachment=4912:Bloom.jpg]

The separate bloom texture does not appear to have this problem but it only happens when I mix the two textures using this shader:



struct FS_INPUT
{
float4 pos : POSITION;
float2 tex : TEXCOORD0;
};

struct FS_OUTPUT
{
float4 color : COLOR;
};

uniform sampler2D txDiffuse1;
uniform sampler2D txDiffuse2;

FS_OUTPUT FS( FS_INPUT In)
{
FS_OUTPUT Out;
Out.color = tex2D(txDiffuse1, In.tex);
Out.color += tex2D(txDiffuse2, In.tex);
Out.color.w = 1.0;
return Out;
}


Any ideas why this may be happening?
Advertisement
What issue did you mean? The less bloom or the over-brighten textures.

if issue is over-bright and txDiffuse2 is the bloom sampler try this:


Out.color = tex2D(txDiffuse1, In.tex);
Out.color.rgb += tex2D(txDiffuse2, In.tex).rgb * ( 1.0f - Out.color).rgb;
Can you explain what you mean by the strange striations and/or post a close-up picture of a problem area without JPEG compression artefacts?

Can you explain what you mean by the strange striations and/or post a close-up picture of a problem area without JPEG compression artefacts?


[attachment=4931:Untitled.png]


Ignore the blockiness that is just due to too few samples. Pay attention to the horizontal lines. What you saw before was not JPEG compression artifacts but the actual problem I speak of. That is how it looks in my game...

Can you explain what you mean by the strange striations and/or post a close-up picture of a problem area without JPEG compression artefacts?


Actually after boosting the brightness and doubling the samples it appears to be my blur shader that is causing the problem.



struct FS_INPUT
{
float4 pos : POSITION;
float2 tex : TEXCOORD0;
};

struct FS_OUTPUT
{
float4 color : COLOR;
};

float PixelKernel[27] =
{
-13,
-12,
-11,
-10,
-9,
-8,
-7,
-6,
-5,
-4,
-3,
-2,
-1,
0,
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
};

static const float BlurWeights[27] =
{
0.0005540,
0.0011080,
0.0027450,
0.0043820,
0.0089395,
0.0134975,
0.0229385,
0.0323795,
0.0464360,
0.0604925,
0.0742545,
0.0880165,
0.0938760,
0.0997355,
0.0938760,
0.0880165,
0.0742545,
0.0604925,
0.0464360,
0.0323795,
0.0229385,
0.0134975,
0.0089395,
0.0043820,
0.0027450,
0.0011080,
0.0005540,
};

float2 direction;

uniform sampler2D txDiffuse;

FS_OUTPUT FS( FS_INPUT In)
{
FS_OUTPUT Out;
float2 samp = In.tex;
for (int i = 0; i < 27; i++)
{
samp = In.tex + (direction * PixelKernel);
Out.color += tex2D(txDiffuse, samp) * BlurWeights;
}
return Out;
}



Any idea what I can do to fix it?
It could be that the direction variable is not set correctly. If this is larger than (1.5/width,1.5/height) then you'll skip pixels during the blurring step.

It could be that the direction variable is not set correctly. If this is larger than (1.5/width,1.5/height) then you'll skip pixels during the blurring step.


Actually I've found that doing more passes and less samples fixes the problem. Here is what I did:



for( float i = 0; i < (OvglPi*2); i = i + (OvglPi/4))
{
float x = sin(i) * 0.005f;
float y = cos(i) * 0.005f;
cgGLSetParameter2f( CgDirection2, x, y );
glBegin(GL_QUADS);
glTexCoord2f( 0.0f, 0.0f );
glVertex3f(-1.0f,-1.0f, -1.0f);
glTexCoord2f( 1.0f, 0.0f );
glVertex3f(1.0f,-1.0f, -1.0f);
glTexCoord2f( 1.0f, 1.0f );
glVertex3f(1.0f, 1.0f, -1.0f);
glTexCoord2f( 0.0f, 1.0f );
glVertex3f(-1.0f, 1.0f, -1.0f);
glEnd();
}



Works great though it's a bit slower than I was hoping for.
Is the value of the direction variable in any way related to the resolution of the input texture?

Is the value of the direction variable in any way related to the resolution of the input texture?


Nope... why?
Fixed! The problem was kinda obvious. I was writing into the same texture I was reading from. I'm now flip-flopping between two different textures for each pass and it works perfect!

This topic is closed to new replies.

Advertisement