Archived

This topic is now archived and is closed to further replies.

Performance issues with textures

This topic is 5174 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have huge performance drops when I have only two texture units and have both being tiled I get 128fps on 132k polygons. If I make one unit stretch the texture over the whole terrain I jump to 300+fps??? Why would this be? I have a Radeon 9700Pro

Share this post


Link to post
Share on other sites
Ok, so tiling vs. stretching the texture isn''t going to make a difference in the amount or VRAM that is taken up correct? If the texture is 256x256x32 then tiling or stretching it still takes up 262k right?

How about mipmapping? using gluBuild2DMipmaps() this will take up more than 262k per texture correct due to it will build a texture of 128x128 down to 1x1?

If that is correct on the mipmapping function would not using gluBuild2DMipmaps() and just use one texture size and not build mipmaps save memory? If so what is the side affect from this method?

See I am confused on how a Radeon 9700Pro can be fill rate maxxed on only a 132k polygons? So if I am correct on this each texture unit 0-max is multiplied by 132k to get the total amount of polygons rendered? What if you are tiling vs. stretching the texture? I thought the Radeon 9700Pro had like no problem rendering a few hundred thousand polygons a sec?

Thanks

Share this post


Link to post
Share on other sites
quote:
I thought the Radeon 9700Pro had like no problem rendering a few hundred thousand polygons a sec?
Try several million. Honestly though, what's wrong with 128 fps? 132k polygons a frame multiplied by 128 frames per second is about 17 million triangles a second. Hmm maybe you are right... My Radeon 8500 can get about 15 million a second with unoptimized code. With 300 fps you are rendering almost 40 million triangles a second . I had a similar problem where textures would kill performance. I ruled it down to a bug in the driver with larger batch sizes... I think you are probably texel limted, not fill rate limited. How many times do you tile the textures over the terrain, and what size are they?

[edited by - Raloth on October 9, 2003 11:36:39 PM]

Share this post


Link to post
Share on other sites
this is overkill. I don''t know if you''re drawing the terrain from a birdviewpoint (in which case the entire terrain would be visible) or from down below (in which case you would have massive overdraw).

Image the first situtation. You have a screen resolution of 1280x1024 (or something similar). If you tile a 256x256 texture 256 time, you''d effectively get a texture of 65536x65536 pixels. This is approximately 5000 (!) times as big as your screen area. That is what your card is effectively drawing. Only it''s just referencing to the same part of memory everytime because of the tiling. Either tile less, or use smaller texture. The combination you are using now is overkill.

In the second situation, you are drawing the entire world, but not seeing it on the screen. In this case, the texture resolution and tiling combination might be correct, but there is no way you will see all your 132k polygons. I''m guessing you are overdrawing a lot. In this case the solution would be some kind of visual culling algorithm.

Basically your card can handle that many polygons, but not in combination with the high tiling of your texture. The advertized numbers are only reachable in very special, limited cases.

I''m no expert on this matter, so if I''m making a total dork of myself, please let me know.

Share this post


Link to post
Share on other sites
quote:
Original post by rick_appleton
this is overkill. I don''t know if you''re drawing the terrain from a birdviewpoint (in which case the entire terrain would be visible) or from down below (in which case you would have massive overdraw).

Image the first situtation. You have a screen resolution of 1280x1024 (or something similar). If you tile a 256x256 texture 256 time, you''d effectively get a texture of 65536x65536 pixels. This is approximately 5000 (!) times as big as your screen area. That is what your card is effectively drawing. Only it''s just referencing to the same part of memory everytime because of the tiling. Either tile less, or use smaller texture. The combination you are using now is overkill.

In the second situation, you are drawing the entire world, but not seeing it on the screen. In this case, the texture resolution and tiling combination might be correct, but there is no way you will see all your 132k polygons. I''m guessing you are overdrawing a lot. In this case the solution would be some kind of visual culling algorithm.

Basically your card can handle that many polygons, but not in combination with the high tiling of your texture. The advertized numbers are only reachable in very special, limited cases.

I''m no expert on this matter, so if I''m making a total dork of myself, please let me know.



No rick your not. You hit the nail on the head though with what I am doing. I am rendering my map which is 256x256 with GL_TRIANGLE_STRIP and 5 texture units. I am tiling the textures also.

Reason why?

I would like to be able to have a GOD like view of the terrain so the player can see what is going on at all times and not some cheesey radar screen like most RTS games use. Ugh. But maybe todays hardware still doesn''t have enough power still?

You are suggesting that I use culling then? But isnt'' culling a fill rate problem bandaid? and not a texturing performance bandaid?

Thanks

Share this post


Link to post
Share on other sites
yes you are right about culling being a fillrate problem.

So you have a gods viewpoint of the entire map. And the map is instead of a scanner do I understand? Or can you zoom out. Either way, if you need to tile that texture that often for the result to look good, it is too detailed a texture. Here's another calculation for you.

If you use mipmapping (which you are I believe), the GPU selects a level of mipmap that corresponds to the approximate size on screen.

Assuming all 256x256 tiles are visible, with each tile a 256x256 pixel texture:
So we have your 256x256 texture tiled acros the screen 256 times in two directions. Using the width of your screen 1280 means that each tile takes about 5 pixels on the screenwidth, and for ease of calculation also 5 pixels vertically. So your 256x256 texture is mipmapped to 128, 64, 32, 16, 8. The 5th level of mipmapping is used. To get the exact same visuals, you should be able to replace your 256x256 pixel texture with a 8x8 pixel texture.

I'm not sure if this would also have a large effect on framerate, but I'd be interested in seeing what this does to the framerate.

Could you try this out and post the results here?

If you are zooming in and out, and need the detail when at ground level, maybe you should try to fade out certain texture levels when zooming out. So when zoomed all the way out, you want need the most detailed texture. As you zoom in, gradually fade in that detailed texture, until at some certain viewpoint, you can see it all.

about your other question: why are mipmaps used. If you don't use them, the GPU will have to skrunch up your texture on the fly it the texture is not mapped one-on-one to the screen. Normally this skrunching is not optimal. By using mipmaps you can precalculate the skrunching, and you will have more time to do it (normally). Therefore, better algorithms can be used to generate a nicer result.
You can try it easily your self. Create a checkerboard image, and stick it onto a quad as in this picture (the right quad with perspective): http://www.cmlab.csie.ntu.edu.tw/~robin/JavaGL/Example-app/images/checker.gif . Now check the difference between using mipmaps or not using them (run it twice with different settings, or better make two quads and load the texture twice with different settings). If you make the quad bigger than no this picture, you should clearly see the better visual result of using mipmaps.

[edited by - rick_appleton on October 10, 2003 3:15:14 AM]

Share this post


Link to post
Share on other sites
I am the GOD like view and you can zoom down in on the terrain. I will try and run my textures as 8x8 and save them and post the FPS delta. I will try to do this sunday night.

Share this post


Link to post
Share on other sites
Why would you need to render a 256x256 texture across every ''tile''? I get away with ever four or six, and the new method I am planning on implementing should allow for only every 10 or 12.

Share this post


Link to post
Share on other sites
quote:
Original post by Raloth
Why would you need to render a 256x256 texture across every ''tile''? I get away with ever four or six, and the new method I am planning on implementing should allow for only every 10 or 12.


I only know of two ways to apply textures to a polygon.

1. set texture coords to 0 through X where X is the number of times you want the texture to tile. e.g. 0,1,2,3.. 256

2. however many polygons you have is X / Map_size to stretch the texture over the whole 256x256 map e.g. 0/256 1/256 ect..

I don''t know any other ways to do this? I wouldn''t even know how to tile 20 times over a 256x256 terrain map?

Share this post


Link to post
Share on other sites
quote:
Original post by rick_appleton
yes you are right about culling being a fillrate problem.

So you have a gods viewpoint of the entire map. And the map is instead of a scanner do I understand? Or can you zoom out. Either way, if you need to tile that texture that often for the result to look good, it is too detailed a texture. Here''s another calculation for you.

If you use mipmapping (which you are I believe), the GPU selects a level of mipmap that corresponds to the approximate size on screen.

Assuming all 256x256 tiles are visible, with each tile a 256x256 pixel texture:
So we have your 256x256 texture tiled acros the screen 256 times in two directions. Using the width of your screen 1280 means that each tile takes about 5 pixels on the screenwidth, and for ease of calculation also 5 pixels vertically. So your 256x256 texture is mipmapped to 128, 64, 32, 16, 8. The 5th level of mipmapping is used. To get the exact same visuals, you should be able to replace your 256x256 pixel texture with a 8x8 pixel texture.

I''m not sure if this would also have a large effect on framerate, but I''d be interested in seeing what this does to the framerate.

Could you try this out and post the results here?

If you are zooming in and out, and need the detail when at ground level, maybe you should try to fade out certain texture levels when zooming out. So when zoomed all the way out, you want need the most detailed texture. As you zoom in, gradually fade in that detailed texture, until at some certain viewpoint, you can see it all.

about your other question: why are mipmaps used. If you don''t use them, the GPU will have to skrunch up your texture on the fly it the texture is not mapped one-on-one to the screen. Normally this skrunching is not optimal. By using mipmaps you can precalculate the skrunching, and you will have more time to do it (normally). Therefore, better algorithms can be used to generate a nicer result.
You can try it easily your self. Create a checkerboard image, and stick it onto a quad as in this picture (the right quad with perspective): http://www.cmlab.csie.ntu.edu.tw/~robin/JavaGL/Example-app/images/checker.gif . Now check the difference between using mipmaps or not using them (run it twice with different settings, or better make two quads and load the texture twice with different settings). If you make the quad bigger than no this picture, you should clearly see the better visual result of using mipmaps.

[edited by - rick_appleton on October 10, 2003 3:15:14 AM]



Rick I hope to try that test run to check for performance soon. I just been really busy. I will post them when I get them done.

Share this post


Link to post
Share on other sites
about your question on how to tile less.

You could calculate the texture coordinates for each vertex. Then the texture coordinates would be 0 for the first vertex, 0.5 for the second and 1.0 for the third. Then 1.5, 2.0, 2.5 etc. This stretches the texture over two tiles (in one direction, so actually over 4 tiles). Another option is calculating texture coordinates such that the bottom left of the entire grid has uv (0,0), and the top right of the entire grid is (1.0, 1.0) and then using a scale in texturespace. Not sure how to do that, you could search for it. Basically, that way you could VERY easily tile your texture a certain number of times, by just changing the texturetransform. It might cost a little overhead since the texture coordinates will have to be transformed (should be very small overhead tho, simply a matrix multiplication).

Googled it for you:

glMatrixMode(GL_TEXTURE);
glScalef(0.5, 0.5, 1.0); // dont care about last coordinate?
glMatrixMode(GL_MODELVIEW);

should do the trick I think. This will obviously scale the texture twice.

Share this post


Link to post
Share on other sites