This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

compression to PKM

Irfan Ziaulla over 11 years ago

Parents

Irfan Ziaulla over 11 years ago

Note: This was originally posted on 26th March 2013 at http://forums.arm.com

Hey Pete, well I'm currently undergoing the second option in which I need to utilize mipmaps, but it may take some time to see the result of using them as I have to apply them to 5 different environments each with their own texture patterns as you may imagine. However, I had a question in regards to the first option in which I have to utilize the filters because I don't see why you need to use them in the first place. The reason why I'm puzzled is because if you utilize power of two textures for both dimensions that you actually don't need them as far as I can understand. I did some calculations trying to understand why using power of twos are very important. The calculations that I did are as follows:
Target Device Specs:
1) Resolution: 1280 * 800
2) Screen Size: 9.4 inches
3) aspect ratio: 16:9

Texture Size
1) POT: 128 * 128, the size that I used for all my actual textures
2) NPOT: 135 * 128, just for calculation and comparison purposes

With this information I calculated pixels/in like this:
Thanks to Wikipedia, I was able to find out the formula to relate screen size to width and height of a triangle of the screen (I don't have the capabilities to show the calculations of width and height of the screen here because it involves square root) so you have to believe me that
height of the screen = 4.6 inches
width of the screen = 8.2 inches

Assuming this is correct and we only look at the width, I calculated the pixels/in of the screen as:

pixels/in of screen = 1280 pixels / 8.2 inches = 156.1 pixels / in.

The texture's width pixel/in calculations = 128 pixels / 8.2 inches = 15.61 pixels / inch (POT)
The texture's width pixel/in calculations = 135 pixels / 8.2 inches = 16.46 pixels / inch (NPOT)

Assuming we look at 1 inch of the screen,

Number of screen pixels = 156.1 pixels
Number of POT pixels = 15.61 pixels
Number of NPOT pixels = 16.46 pixels

Finally I did a ratio comparison between texture pixels to screen pixels and found:

POT

156.1 pixels / 15.61 pixels = 10 / 1

NPOT

156.1 pixels / 16.46 pixels = 9.48 / 1

After doing these calculations, I've come to a conclusion that if you use POT textures there is no need to incorporate such filters because the number of pixels evens out (10/1). The opposite is true for using NPOT because you end up with uneven number of pixels (9.48/1), and thus having to use filters such as:

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_NEAREST);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_NEAREST);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_S, GLES20.GL_CLAMP_TO_EDGE);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_T, GLES20.GL_CLAMP_TO_EDGE);

Actually in the NPOT situation, it looks like I would only have to utilize the magnification filter, and the wrap filters.

Then again, when I tried doing this without compression, I had POT textures (.png 128 x 128) and all four filters and although the cube and the textures were drawn out I still had the problem that the texture did not line up correctly in the cube faces. The textures appeared like they were stretched out. In that situation I had all three dimensions as:

x-range : -3.0(left) to 3.0(right)
y-range: -3.0(bottom) to 3.0(top)
z-range: -3.0 (left)to 3.0 (right)

Hi,

sounds like good progress! If the rest of the code is running without errors but you aren't seeing textures then my next guess is that OpenGL ES does not believe the texture is "complete". For instance, OpenGL ES defaults to using a minifying texture filtering mode using mipmaps. If you upload only the original base level of the texture, OpenGL ES will believe the other levels are missing, and refuse to render anything.

There are 2 ways to solve this. The quickest and easiest is probably to change the filtering mode so OpenGL ES does not expect to find mipmap levels:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

though you should note that if you display many of your textures on geometry smaller than the original texture size this will mean less efficient usage of the texture cache and may be sub optimal.

The alternative (which makes better use of the texture cache) is to ask the Mali Texture Compression Tool to generate compressed textures for each mipmap level (e.g. 8x8, 4x4, 2x2 and 1x1) and load each one into the appropriate mipmap level:

glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_ETC1_RGB8_OES, 8, 8, 0, 32, pMipmapLevel0); glCompressedTexImage2D(GL_TEXTURE_2D, 1, GL_ETC1_RGB8_OES, 4, 4, 0, 8, pMipmapLevel1); glCompressedTexImage2D(GL_TEXTURE_2D, 2, GL_ETC1_RGB8_OES, 2, 2, 0, 2, pMipmapLevel2); glCompressedTexImage2D(GL_TEXTURE_2D, 3, GL_ETC1_RGB8_OES, 1, 1, 0, 1, pMipmapLevel3);

Then OpenGL ES will select the most appropriate mipmap level for the size of the textured triangle on screen, and not waste space in the texture cache loading lots of texel data that will never be sampled.

HTH, Pete
Cancel
Up 0 Down

Cancel

Reply

Irfan Ziaulla over 11 years ago

Note: This was originally posted on 26th March 2013 at http://forums.arm.com

Hey Pete, well I'm currently undergoing the second option in which I need to utilize mipmaps, but it may take some time to see the result of using them as I have to apply them to 5 different environments each with their own texture patterns as you may imagine. However, I had a question in regards to the first option in which I have to utilize the filters because I don't see why you need to use them in the first place. The reason why I'm puzzled is because if you utilize power of two textures for both dimensions that you actually don't need them as far as I can understand. I did some calculations trying to understand why using power of twos are very important. The calculations that I did are as follows:
Target Device Specs:
1) Resolution: 1280 * 800
2) Screen Size: 9.4 inches
3) aspect ratio: 16:9

Texture Size
1) POT: 128 * 128, the size that I used for all my actual textures
2) NPOT: 135 * 128, just for calculation and comparison purposes

With this information I calculated pixels/in like this:
Thanks to Wikipedia, I was able to find out the formula to relate screen size to width and height of a triangle of the screen (I don't have the capabilities to show the calculations of width and height of the screen here because it involves square root) so you have to believe me that
height of the screen = 4.6 inches
width of the screen = 8.2 inches

Assuming this is correct and we only look at the width, I calculated the pixels/in of the screen as:

pixels/in of screen = 1280 pixels / 8.2 inches = 156.1 pixels / in.

The texture's width pixel/in calculations = 128 pixels / 8.2 inches = 15.61 pixels / inch (POT)
The texture's width pixel/in calculations = 135 pixels / 8.2 inches = 16.46 pixels / inch (NPOT)

Assuming we look at 1 inch of the screen,

Number of screen pixels = 156.1 pixels
Number of POT pixels = 15.61 pixels
Number of NPOT pixels = 16.46 pixels

Finally I did a ratio comparison between texture pixels to screen pixels and found:

POT

156.1 pixels / 15.61 pixels = 10 / 1

NPOT

156.1 pixels / 16.46 pixels = 9.48 / 1

After doing these calculations, I've come to a conclusion that if you use POT textures there is no need to incorporate such filters because the number of pixels evens out (10/1). The opposite is true for using NPOT because you end up with uneven number of pixels (9.48/1), and thus having to use filters such as:

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_NEAREST);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_NEAREST);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_S, GLES20.GL_CLAMP_TO_EDGE);
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_T, GLES20.GL_CLAMP_TO_EDGE);

Actually in the NPOT situation, it looks like I would only have to utilize the magnification filter, and the wrap filters.

Then again, when I tried doing this without compression, I had POT textures (.png 128 x 128) and all four filters and although the cube and the textures were drawn out I still had the problem that the texture did not line up correctly in the cube faces. The textures appeared like they were stretched out. In that situation I had all three dimensions as:

x-range : -3.0(left) to 3.0(right)
y-range: -3.0(bottom) to 3.0(top)
z-range: -3.0 (left)to 3.0 (right)

Hi,

sounds like good progress! If the rest of the code is running without errors but you aren't seeing textures then my next guess is that OpenGL ES does not believe the texture is "complete". For instance, OpenGL ES defaults to using a minifying texture filtering mode using mipmaps. If you upload only the original base level of the texture, OpenGL ES will believe the other levels are missing, and refuse to render anything.

There are 2 ways to solve this. The quickest and easiest is probably to change the filtering mode so OpenGL ES does not expect to find mipmap levels:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

though you should note that if you display many of your textures on geometry smaller than the original texture size this will mean less efficient usage of the texture cache and may be sub optimal.

The alternative (which makes better use of the texture cache) is to ask the Mali Texture Compression Tool to generate compressed textures for each mipmap level (e.g. 8x8, 4x4, 2x2 and 1x1) and load each one into the appropriate mipmap level:

glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_ETC1_RGB8_OES, 8, 8, 0, 32, pMipmapLevel0); glCompressedTexImage2D(GL_TEXTURE_2D, 1, GL_ETC1_RGB8_OES, 4, 4, 0, 8, pMipmapLevel1); glCompressedTexImage2D(GL_TEXTURE_2D, 2, GL_ETC1_RGB8_OES, 2, 2, 0, 2, pMipmapLevel2); glCompressedTexImage2D(GL_TEXTURE_2D, 3, GL_ETC1_RGB8_OES, 1, 1, 0, 1, pMipmapLevel3);

Then OpenGL ES will select the most appropriate mipmap level for the size of the textured triangle on screen, and not waste space in the texture cache loading lots of texel data that will never be sampled.

HTH, Pete
Cancel
Up 0 Down

Cancel

Children

No data