Unraveling texture magnification, empowering the user
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Mac OS X, Unix/Linux, Windows.</i>
In a recent beta release a new cvar was added; "rend-tex-filter-mag" to enable the user to control whether textures are bilinear filtered.
Now, we also have "rend-tex-filter-sprite" and "rend-tex-filter-raw" which afford control of bilinear filtering on those specific classes of resource.
My question is, what is Doomsday's strategy with regard to tex mag, to the options and how they are intended to be used.
I would like to see separate tex mag filter controls for each "texture use" (i.e. world, sprite, UI. Note, these don't relate 1:1 to the established resource classes in the texture manager) in order to give users complete control. Currently there are name/use convention issues here and I'd like to resolve them before development progresses.
In a recent beta release a new cvar was added; "rend-tex-filter-mag" to enable the user to control whether textures are bilinear filtered.
Now, we also have "rend-tex-filter-sprite" and "rend-tex-filter-raw" which afford control of bilinear filtering on those specific classes of resource.
My question is, what is Doomsday's strategy with regard to tex mag, to the options and how they are intended to be used.
I would like to see separate tex mag filter controls for each "texture use" (i.e. world, sprite, UI. Note, these don't relate 1:1 to the established resource classes in the texture manager) in order to give users complete control. Currently there are name/use convention issues here and I'd like to resolve them before development progresses.
Comments
Maybe we could convert <tt>filter-mag</tt> in a bitfield, with a bit for each type of texture whose magnification filtering needs to be toggleable, and get rid fo the old <tt>filter-sprite</tt> and <tt>filter-raw</tt>. Then we can have nice check boxes in the Control Panel for choosing what the mag filter, or mag filter all/nothing by setting the cvar to 0xffffffff or zero.
So, which bits to have? Textures, flats, sprites, UI graphics/fonts, UI backgrounds, skies, 3D model skins, particles?
The good thing is that the mag setting can be set just before something is drawn without incurring any performance penalty, so we can just use whichever mag filter mode is specified in each use case when the actual drawing is done.
As to what bits, I think you've covered everything. However, I think it might be better to separate controls based on surface/context rather than resource type (i.e. world, sky, object, ui) so that we can cleanly deal with "any texture in any context".
I think its only in the Doomsday Control Panel, the console and other engine presentation graphics which should always enable the mag filtering.
What about things like shinemaps, lightmaps etc. Is it logical that these should inherit the mag filter setting depending on their parent? For example, shinemaps on a flat/texture would use the bit for world surfaces.
BTW: How is the work going on the deferred texture uploading?