[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL NPOT texture support
On Fri, Nov 18, 2011 at 8:03 PM, Chris Marrin <email@example.com> wrote:
It would be useful for authors to chime in about the downside of not having the capability of tiling or mip-mapping npot textures. Why not make any texture you want to tile into a power-of-two? Is it a space savings issue? An image quality issue? What are the cases where mip-mapping an NPOT texture is important?
It is desirable to mipmap an npot texture in case that:
- this texture is being projected onto primitives of varying sizes where the minification filter would kick in
- the texture is desired to be repeated, so using a larger texture is not a viable choice due to interpolation issues
Repeating textures are used often in games because they offer a convenient way to produce apparent detail without dramatically increasing the required data (as such it is a scheme of generative content). It works well because many real world examples of engineering and architecture contain elements that are repeated (such as floor tiles, wall panels, bolts on beams, church decorations and so on). It also works well in non engineered environments because many natural phenomena resemble noise with the property of self-similarity, so the believability gap between an actually varying noise function, and just a repeating one is quite small.
It is necessary to mention that this discussion harks back to a "flaw" in hardware accelerated texturing. If texture coordinates inside a primitive vary too fast (such as is the case when modifying them with fract), any scheme of interpolation or minification will produce visible seams because the wrong neighbors (or levels) are accessed. In order to address this problem, yet still have repeating textures, the flavor implemented in current hardware uses continous texture coordinates inside the primitive beyond the domain of 0...1, hence avoiding the interpolation artifacts. And because the texture has ben set to tiling, any outside 0...1 access will be modulo divided on the hardware.
It turns out however that this requires rebinding textures fairly often since it directly stands in conflict with texture atlasing schemes. Unfortunately this limits both the utility of texture atlases and repeating textures and requires careful consideration when which is used.
When it is required to support both texture repetition and a large variety of tiles, the only solution we have is to subdivide the geometry according to texture coordinates. Depending however on art-direction and multi-texturing requirements, that too can be a choice with inherent conflicts.
What we'd really like was a way to have repeating textures, that can be mipmapped, and can be stuck into an atlas. It is possible to do this as a shader by implementing the required interpolation scheme yourself but if, and only if, the derivatives are accessible and the miplevel to access can be controlled. Of course it comes at a cost that each interpolated lookup would trigger 8 separate non-interpolated lookups. (2x2 for the s and t directions and x2 for the neighboring mip levels). As it is the miplevel cannot be controlled in WebGL but it could be emulated by storing the "levels" all on level 0 and computing scale and offset into them yourself. Unfortunately such schemes tend to be significantly slower then mipmapped/interpolated texture lookups that are built-in (presumably because they've been optimized on the hardware).