Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

147 Neutral

About RichPressence

  • Rank
  1. RichPressence

    pixel offset after rendering to fbo?

    Thanks for the replys guys. Seems I was doing a number of things poorly, one being how I was dividing my fbos down from my target res, im dividing and rounding now instead of div and flooring, they stay pretty square now at lower mips. The other problem was with the fbo getting offset by 1 pixel towards the top right corner even if the res matched the main buffer. Using this for the coords in my fbo frags when upsampling/downsampling stopped them getting offset. uniform ivec2 buffer_res; ivec2 intCoord = ivec2(gl_FragCoord.xy); vec2 texCoord = vec2(intCoord + 0.5) / buffer_res; Wouldn't surprise me its not completely bang on still need todo more checking I think.   Well I was doing this for a bloom shader and im heart set on making use of the linearly sampled gaussian blur trick to get some free taps which requires the use of gl_linear. But yeah for a straight full res copy I think gl_nearest would be best.   @Hodgman Yeah I originally thought the half pixel offset thing was the battle I was fighting till I found its a d3d9 thing.   before and now
  2. Hey, when I render the screen to an offscreen buffer for downsampling or storage for later it gets offset. I noticed it when I was writing a wide radius bloom shader as the offset increased after every downsample and blur making it more and more noticeable.   im using opengl and have GL_LINEAR enabled for the offscreen buffer and the viewport size is 1024x1024 with the offscreen buffer matching that. Shouldnt the offscreen buffer match the main exactly pixel for pixel if its not being resized or is this a side effect of using gl_linear?.   Heres the frag but it just passes through the color which gets sent to the next pass as an input. uniform sampler2D ColorTexture; uniform vec2 buffer_res; vec2 texel = 1.0 / buffer_res; vec2 texCoord = gl_TexCoord[0].xy; void main() { // with this the offset pushes out from the center rather than off to the top right corner     // but is still getting offset texCoord += vec2(0.5, 0.5) * texel; gl_FragColor.rgb = textureLod(bgl_RenderedTexture, texCoord, 0).rgb; } The images are crops from 1024x1024
  3. Are you doing your additve blending back into your main color only once in a final blend pass? so the three intermediate blur passes not additively blended then combine them in your final additive combine shader, so I guess (Blurpass1 > Blurpass2 > Blurpass3 > combinePass) I guess it needs the same treatment as to how multipass bloom is done.
  4. Yeah mines just the pure radial blur without gpu gems physically based additions, Weird, well only other thing is my setup does look undersampled and close to yours if I don't divde the sample distance of the blur in half after each pass. Maybe try it with the same distance on each of the three passes.   All three 8x8x8 passes with a density of 0.8 [attachment=25628:noOffset.png]
  5. Correct, you use the previously blured texture for the next blur pass with the sample distance divided always in half every next pass, the code from the example is below in glsl. Im not additively blending the samples together but should make no difference if blended correctly. Your result should look much smoother, looks like your still downsampling, maybe this method doesn't play nicely with it never tried.   I was shocked myself when I first tried cryteks method of doing most types of blurs, with how smooth it was with so few samples and just multiple passes. Crytek said they used the same method for their motion blur in that paper to. uniform sampler2D inputTexture; vec2 texCoord = gl_TexCoord[0].xy; uniform float x; uniform float y; vec2 lightPos = vec2(x, y); uniform float density = 1.0; // next pass 0.5 then 0.25 and so on const int SAMPLES = 8; vec4 radialBlur(vec2 texCoord) {          vec2 deltaTexCoord = gl_TexCoord[0].st - lightPos;     deltaTexCoord *= 1.0 / SAMPLES * density;          vec4 color;          for(int i = 0; i < SAMPLES; i++)     {         texCoord -= deltaTexCoord;                  color += texture2D(inputTexture, texCoord);              }     color /= SAMPLES;          return color; } void main(void) {     vec4 color = radialBlur(texCoord);     gl_FragColor = color; }
  6. Cryteks approach is really good quailty performance wise if you dont want to downsample, though you really need the 8x8x8, 4 samples per pass doesn't really cut it for a sun scatter. You just have to divide your sample dist by half after every blur. They dont say do so in their paper, but I assume they mean to, looks no good other wise.  I quickly set up 3 radial blurs as an example for you.   one pass 128 Samples [attachment=25602:Full128Samples.png]   one pass 512 Samples [attachment=25603:Full512Samples.png]   three pass 8x8x8 samples effectively 512 [attachment=25604:3Pass8x8x8Samples.png]
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!