I'm currently building a fragment shader which is using several textures to render the final pixel color.

The textures are not really textures, they are in fact "input data" to be used in the formula to generate the final color.

The problem I've got is that the texture are getting bi-linear-filtered, and therefore the input data as well. This results in many unwanted side-effects, especially when final rendered texture is "zoomed" compared to original resolution.

Removing the side effect is a complex task, and only result in "average" rendering. I was thinking : well, all my problems seems to come from the "default" bi-linear filtering on these input data. I can't move to GL_NEAREST either, since it would create "blocky" rendering. So i guess the better way to proceed is to be fully in charge of the interpolation.

For this to work, i would need the input data at their "natural" resolution (so that means 4 samples), and a relative position between the sampled points. Is that possible, and if yes, how ?

[EDIT] Since i started this question, i found this internet entry, which seems to (mostly) answer my needs. http://www.gamerendering.com/2008/10/05/bilinear-interpolation/

One aspect of the solution worry me though : the dimensions of the texture must be provided in an argument. It seems there is no way to "find this information transparently". Adding an argument into the rendering pipeline is unwelcomed though, since it's not under my responsibility, and translates into adding complexity for others.


the dimensions of the texture must be provided in an argument. It seems there is no way to "find this information transparently".

What, are you stuck in GL 2.1 land? We've had textureSize in GLSL for years now.

| improve this answer | |
  • \$\begingroup\$ The link you provide also give information on texelFetch(), which is exactly what i was looking for. Many Thanks. My very last small issue to solve is how to deal with "border of textures", which appear black. I guess it must be a matter of wrapping detection and policy. \$\endgroup\$ – Cyan Nov 17 '12 at 1:34
  • \$\begingroup\$ @Cyan: Note that you may also be interested in textureGather. It's a 4.x feature, but available on a limited set of AMD's 3.x cards (HD 4xxx's). \$\endgroup\$ – Nicol Bolas Nov 17 '12 at 1:56
  • \$\begingroup\$ Thanks, it's even more straightforward : a single function call which does all the job. Nice. Unfortunately, I fear i cannot program for GLv4+ only at this stage, but that's nonetheless very useful to know. \$\endgroup\$ – Cyan Nov 17 '12 at 2:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.