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
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.
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.
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.
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.
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.
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.