Request: Please expose mipmap filtering (with example)

Last night I asked Ashley on twitter if it was possible to expose mipmap-filtering in addition to linear and nearest neighbor ("point") to users. He encouraged me to ask this publicly, so here it is. I also felt it belonged in here and not the Effects-subforum.

I'm in the process of writing a bloom-shader. Many indies rely on relatively cheap assets (boxes, stick figures etc.) combined with fancy schmancy glows and effects. As of now, C2 is lacking one, which is kind of a sore spot.

[Disclaimer: technical babble ahead]

What you normally do to write a post glow is to take the cheapest blur filter you can get (typically a 9-sample boxblur, 3*3), and put it ontop of the thing you want to make glow, using the screen-blend formula. The trick to get this good looking is to not just sample the texture, but use a rather large mipmap bias in your texture2D lookup. By that you don't sample the crisp texture but rather a mushy version of it, due to the filter - that's super cheap, computation wise. If you were only to use the regular linear filtering, a 9-sample boxblur looks like c***.

Here's a little example.. first is the GLSL-fragment shader for the bloom implemented in Shadertoy, using a 3*3 boxblur and mipmap filtering on the texture:

Simple, el cheapo and good looking.

Now the same thing, with linear texture filtering:

You clearly see the jaggies from the filter, the wider the blur the more noticable it is, of course.

I then implemented this for C2, hoping that mipmap-filtering was enabled by default, which it isn't, obviously. This is the running C2 version of the shader:

(it looks a bit more jaggy than the shadertoy-version in this shot, but that's only because it was resized, it basically looks identical).

Now there are of course some workarounds to get this done even with just linear filtering, you can use more samples, and typically you also

mush together several passes of them with varying sample numbers and radii - still, it is *far* more expensive to compute and does not look as good, especially on clean shapes like quads or lines, which is the No.1 use case for indies.

Would this be a lot of work to expose? Or is there a way to do it already? I would really like to use this and I think others might, too.

As long as "downscaling quality" is not "low", Construct 2 creates mipmaps and enables tri-linear filtering (linear sampling between the nearest 2 mipmaps, linear-sampled). The "point" and "linear" project settings in this mode correspond to whether the mipmaps are linear or point sampled. So if you're accessing a mipmap from the shader... it should be there already?

That's what I thought after reading your release notes for r160.

But as you can see above: it does not work.

I tested "medium" (the default) and "high" downsampling modes. It always comes out like this, the mipmap bias on the texture2D lookup has no effect.

What you normally do to write a post glow is to take the cheapest blur filter you can get (typically a 9-sample boxblur, 3*3), and put it ontop of the thing you want to make glow, using the screen-blend formula. The trick to get this good looking is to not just sample the texture, but use a rather large mipmap bias in your texture2D lookup. By that you don't sample the crisp texture but rather a mushy version of it, due to the filter - that's super cheap, computation wise. If you were only to use the regular linear filtering, a 9-sample boxblur looks like c***..

I'm trying to reproduce what you or doing here to help me understand better..

when you say 9-sample boxblur.. so do you mean just a 3x3 sprite of solid color and stretched? can't get it working..

when you say 9-sample boxblur.. so do you mean just a 3x3 sprite of solid color and stretched? can't get it working..

No, it's what happens inside the WebGL shader code.

Are you sure you're calculating the bias correctly? Maybe it's thrown off by spritesheeting? I am pretty sure the mipmaps are all there.