How to resize the framebuffer in the Bloom shader?

[Beherith]

So i've been staring at the old Bloom shader made by kloot, trying to make the brighttextures only half the size of the of the screentexture, to save some frames per second, and to do some wider bloom (7x7 just doesnt cut it, and making it 13x13 is just way too expensive).

Can anyone point me to the right way of doing this? Do I have to pass a level paramter to glCopyToTexture to get its first mip level?
I tried halfing the texture sizes in the glCreateTexture calls, but that just makes the calls fail.

The shader is attached below.

EDIT:
Halfing the texture does sizes does work, but then I only get that part of the screen bloomed.

Also, it seems that

Code: Select all

glCopyToTexture(screenTexture, 0, 0, 0, 0, vsx, vsy, nil,1)

Where the miplevel param is not 0 results in the call only copying the framebuffer once. Each next call returns the first buffer, so the image is static. Am I misinterpreting the function here, or is this a bug?

[Kloot]

trying to make the brighttextures only half the size of the of the screentexture

Won't work, FBO texture attachments all need to have the same size.

[Beherith]

Woohoo, it seems to have worked, using the code from the depth of field shader!

And some more tweaks later and goddamn it looks amazing!

Thank you Kloot, and thank you jK!

Now if only I could render the normals to a target as well...

EDIT:

The shader seemed to 'lag behind' visually when panning the camera, looking like this at high speed:

I tried synchronizing with 'glFinish' and glFlush, but that did nothing.

And I previously noticed that the brighttextures do not like being fed large values (they were format = GL_RGB16F_ARB), so I changed them to normal GL.RGBA types. This fixed the motion lag.

I was hoping that the same error is what causes the distortionFBO in the airjets and distortion spheres and flames to lag like mad when panning. But unfortunately changing the PostDistortion.jitterformat = GL_RGBA32F_ARB to GL.RGBA did not help

EDIT2: Fixed the goddamned distortion flicker :) Turns out that is a feature, not a bug.

[Forboding Angel]

Ummm, I can haz? I lurves me sum bloom.

[dizekat]

In my game (this one) I render in high dynamic range, then I scale it down repeatedly by factor of two (by rendering one texture into the other, halving the res repeatedly. I use multiple FBOs for that), then I scale back up overlaying each lower res image onto the larger image, from the smallest size to the screen size. This way I get cheap large size bloom.

E.g. if the image is 1024x1024, it gets rendered into 512x512 (with filtering using a shader that samples it to use linear interpolation to blur it more), which is then rendered into 256x256, and so on down to say 4x4. Then the small 4x4 image gets rendered onto the 8x8 image, additively (adds to what's there), and 8x8 onto 16x16, and so on all the way up to 1024x1024

[jK]

Wonder if the way back is really more efficient.

I would assume the following is faster:
1. create _1_ texture with mipmaps and bind it to FBO
2. render to it
3. glGenerateMipMaps() (problem might be it doesn't work with floattex on some GPUs)
4. bind texture and render it to onscreen FBO (and use a for-loop in the shader to accumulate all mipmap levels, texture cache should make this very efficient)

[Beherith]

how fast is glGenerateMipMaps? Floattex isnt really needed, current works fine without.
How does one force a texture2d lookup to come from a specific miplevel?

I'm currently using a half-sized intermediate buffer for the blur passes. It seems to perform more than OK, so I'm not really worried.

[jK]

how fast is glGenerateMipMaps? Floattex isnt really needed, current works fine without.

For the basic texture formats it should be hw accel. Still for some textureformats (e.g. floattex) it showed that some drivers sends the data to the CPU and does it in software.
Never the less it is the official way to do so and so is the `fast path` of creating mipmaps.

How does one force a texture2d lookup to come from a specific miplevel?

1. In GLSL1.1 texture2D() supports a 3rd argument "bias", which indicates the mipmap level bias/offset still it is relative to the auto computed level and so you need to trick a bit so this auto computed one is 0.

2. you can use GL_ARB_shader_texture_lod (part of GLSL1.3) + texture2DLod()

[Beherith]

Wow thanks man!

[dizekat]

Wonder if the way back is really more efficient.

I would assume the following is faster:
1. create _1_ texture with mipmaps and bind it to FBO
2. render to it
3. glGenerateMipMaps() (problem might be it doesn't work with floattex on some GPUs)
4. bind texture and render it to onscreen FBO (and use a for-loop in the shader to accumulate all mipmap levels, texture cache should make this very efficient)

That was the first thing i tried, and glGenerateMipmaps was awfully slow, and the quality sucked, and that's just on one graphics card. Then, when you want to upscale all your blooms you definitely want to do it as a sequence of growing sizes (was quite big difference for me). I don't trust anything that is not precisely specified - there will be one vendor that does it wrong.

edit: another advantage of scaling them down yourself is that in your scaling down shader, you can do fairly blurry filtering (e.g. take 4 samples, but take them inbetween pixel coordinates so that bilinear filtering does some blurring for you), which improves how the bloom looks a fair lot.