Hi guys. I tried to find out why mipmaps isn’t exist and got dead frost, at all. May be I something missing? First of all I try making my image size is power of two, but nothing happened. Next, I inherit ImageSource class and find out that all textures has only one mipmap and can’t generate it manually. By the way texture format is missing as well and return Format.Unknown. This is a bug or not functional? Thanks!
We don’t generate mipmaps. The reason is that we cannot guarantee mip-map support on non-power-of-two textures on all devices, so we’ve opted to deprecate
ResampleMode=Mipmap to reduce confusion. Mipmap haven’t really worked at any point, it has acted like Linear. The deprecation has already been done, but hasn’t shipped yet.
The preferred way of doing resolution-independent graphics, is to use
Thanks for the answer, Erik. I agree, generating mipmaps by gpu (I mean glGenerateMipmap) not supported by all devices, but how about generating this on cpu for all levels and set each via glTexImage2D? It’s approach uses a lot of 2d and 3d engines. Mipmaps very useful in 3d space and other important cases.
If you don’t want generate mip-maps in any case, may be you provide some public methods for set special mipmap level from Buffer for example?
Actually, it’s not just glGenerateMipmap that is not supported on all GPUs, it’s also using mipmapping, even when generated on the GPU.
The OpenGL ES 2.0 specification section 3.8.2 says, under the “Texture Access” subsection, lists the
• A two-dimensional sampler is called, the corresponding texture image is a non-power-of-two image (as described in the Mipmapping discussion of section 3.7.7), and either the texture wrap mode is not CLAMP_TO_EDGE, or the minification filter is neither NEAREST nor LINEAR.
requirement as a reason for returning
(R, G, B, A) = (0, 0, 0, 1) from the texture sampling function. Since most images are not power-of-twos, we cannot rely on this feature for general-purpose image filtering.
You are right! I forgot about this issue. And last question, why you don’t want make non-POT textures to POT? Is it memory overhead reason?
Yeah, memory-usage is indeed the reason. We have an item on our roadmap to provide a better image-scaler that does on-demand scaling of images and caches the result, and we believe this will provide both better looking results and less memory usage than trying to use mip-maps opportunistically an falling back to padding to power-of-two if there’s no hardware support. But until the better, brighter future is here,
MultiDensityImageSource is the best way to combat image-alisasing.
Cool! It is very interesting that you can come up with this limitation.