Offt: texture filtering state

OpenGL OpenGL: Advanced Coding
1

I would to ask a slightly offtopic question, as I really value the input of you all.
This is about a API research I currently do. The question is - what would you personally prefere and why:
1. The filtering state should be a property of the texture object(as in OpenGL currently)
or
2. The filtering state should be a property of the texture unit(sampler) object

The first option is somehow more logical, but the second one gives possibly more control and is a more centralized option

Would like to hear your thoughts!

2

For me the second option sounds more logical.

The texture object encapsulates the texture data. The filtering state doesn’t have anything to do with the data itself, but defines how a texture should be sampled/filtered.
I think this state should belong to a texture unit/GLSL sampler variable. Doing so makes it possible to bind the same texture to different texture units and have different filtering for each (otherwise you would have to make a copy of the texture). Though, such a case is so rare that it does not make any difference.

3

If i remember correctly, D3D9 uses the second option.

I am not so sure, what i like best, because it is very nice to decide at load time, which filtering should be done on a texture, instead of deciding it every time you bind the texture. That is, because the decision might be based on several criterias.

On the other hand, when you decide this at load-time, it becomes very humble to change the filtering mode at runtime, for example when the user wants to play with those options to check for quality and speed.

In the end, i would go for option 2. Not only for texturing, but also for clamp/repeat mode and stuff. Actually my engine does it that way anyway, by automatically setting those states at every texture-switch, because one and the same texture can be used with different filtering/clamping behaviour and thus i need to make sure to set the correct values anyway.

In my opinion OpenGL encapsulates states in texture-objects that should not be stored at such a low-level.

Jan.

4

Both, would be nice, it’s good to have a filtering state attached to the texture itsef since this rarely change, but #2 gives more flexibility at the cost of having to state the sampling method all the time.

Having the option of overiding #1 with #2 at will would be geat, but i guess it’s not an option.
Then 2 for me if you concider future developments in realtime 3D graphics.

5

option 2, because that’s where the hardware references it, and being close to what the hardware actually does is best.

6

Ok, thats exacly the way i feel :slight_smile:

So my API will have the second option

The draft is almost ready, I only have to write the more-or-less complete specs and implement it :smiley:

7

Of the two choices presented, 2 feels like the better one.

But does the filtering mode have to be part of the state?
The shader could pick the right filtering function based on its needs.

filteredTexel = tex2Dbilinear(…); // builtin function
filteredTexel = mytex2dbicubic(…); // user specified function

But this doesn’t let you easily switch between different filtering functions. So we can have something like function pointers:

uniforms:
SamplerFunc2D  colorSampler;
SamplerFunc2D  normalMapSampler = myNormalMapSampler();

const int filteringQuality;


main()
{
   if(filteringQuality==0)
   {
      colorSampler = tex2Dbilinear;
   }
   else
   {
      colorSampler = tex2Dbicubic;
   }
   
   vec4 diffColor = colorSampler(...);
   vec4 unitNormal = normalMapSampler(...);   
   //...
}

To me this feels like the right way to use a filtering mode, but doing it the way I showed might not be the best method.

8

Maybe you are right, but it would be very difficualt to implement such functionality via opengl (as it is today). Also, I am not shure if one really needs it. The way to go are without doubt the programmable texture samplers (textures ar arrays access) but it will be in the future.

9

i cant see why ppl pick #2, number 1 makes more sense.
ok perhaps #2 is how the hardware does it but i assume zengar is talking about starting from a clean sheet of paper.

10

number 1 is something I expect to be managed at the application level, so the application has a chance at better sorting than the driver due to its intimate knowledge of what’s coming next.
Any ‘object’ in GL should just be a proxy of a similar data structure in most hardware, and I don’t think filter and wrap modes are stored in the hardware next to the texture data - I imagine the driver itself associates these parameters with the hardware texture object and does the mode switching when its used.