does repeating the same texture slow it down?
Author
I am currently working on a map system for a game engine, and getting a choppy framerate sometimes. This is part of how it works now:
to make a wall, you use our map editor (notepad) to say you are using the wall model (2 triangles forming a square, also made in notepad) and what dimensions you are scaling it to. This means that the texture is repeated several times, by making the texture coordinates greater than 1 in the scaling process.
Does repeating a texture several times over a polygon slow performance?
Would performance be increased by using larger textures/stretching a texture?
Stretching a texture would produce unshafty Quake1-like walls.
Although we have complete overdraw in the map, we think textures might be the problem. We are rendering 324 triangles, and GeForce2MX can do 20 Million/second.
Proceeding on a brutal rampage is the obvious choice.
Here''s what you can do : write a test program, with options to render in a mode or another, and benchmark the different options.
That will answer your question.
As for "20Mtris/s", that entails using the vendor-specific functions that push vertices to the card in an optimized way, not the general GL/DX functions.
That will answer your question.
As for "20Mtris/s", that entails using the vendor-specific functions that push vertices to the card in an optimized way, not the general GL/DX functions.
It shouldn''t slow you down because the main thing that hinders texture performance is memory bandwidth and since you''re using the same texture over and over you won''t see a slow down.
--
http://www.3dcgi.com/
--
http://www.3dcgi.com/
Quick answer: yes, it can slow down if you tile it a lot of times. This is simply due to cache issues: the more tiling you do, the less chances you have to fit 2 adjacent pixels into the cache.
Y.
Y.
i dont see how cache issues come into play. if you draw the using sepearte polygons using the same texture or repeat the texture using the uv coordinates, the cache wont get effectd since in essence you are drawing the same thing.
you should get better frame rates using less polys (simple because you have less transformations).
rendering 324 triangles? now is that 1944 vertices or only 973 vertics? number of VERTICES affect performance not so much the number of triangles (though dont go crazy with those indexed primitives). it may be more of how you are drawing your polys, you are btaching polys with the same texture right? this would mean drawing about 50-200 polys per call. you are using vertex buffers/vertex arrays? (you really should mention your api). you say you have complete overdraw of the map, which i am guessing is meaning that you draw the entire level every frame with no culling (except what the api does by default). you may just be killing your fillrate, though you dont mention any framerates at all. turn of vsync, that may help. maybe you need it on since your drawing the stuff too fast. is your movemnet based on time and is it working properly?
i highly suggest you add framerate display to your game engine and do waht fruny suggests.
you should get better frame rates using less polys (simple because you have less transformations).
rendering 324 triangles? now is that 1944 vertices or only 973 vertics? number of VERTICES affect performance not so much the number of triangles (though dont go crazy with those indexed primitives). it may be more of how you are drawing your polys, you are btaching polys with the same texture right? this would mean drawing about 50-200 polys per call. you are using vertex buffers/vertex arrays? (you really should mention your api). you say you have complete overdraw of the map, which i am guessing is meaning that you draw the entire level every frame with no culling (except what the api does by default). you may just be killing your fillrate, though you dont mention any framerates at all. turn of vsync, that may help. maybe you need it on since your drawing the stuff too fast. is your movemnet based on time and is it working properly?
i highly suggest you add framerate display to your game engine and do waht fruny suggests.
> the cache wont get effectd since in essence you are drawing the same thing.
It''s like saying: if i have a 100 Mb vertex buffer, and it''s the only vertex buffer i render from, all the vertex accesses will fit into the cache.
The video cache has a limited size. Textures use memory. As long as there is coherency when you''re referencing the texels of a texture, fine. If you are accessing them randomly, as with a high resolution texture or high UV tiling factors, the cache becomes less efficient. This is why mipmapping improves performance on high-res textures.
Y.
It''s like saying: if i have a 100 Mb vertex buffer, and it''s the only vertex buffer i render from, all the vertex accesses will fit into the cache.
The video cache has a limited size. Textures use memory. As long as there is coherency when you''re referencing the texels of a texture, fine. If you are accessing them randomly, as with a high resolution texture or high UV tiling factors, the cache becomes less efficient. This is why mipmapping improves performance on high-res textures.
Y.
I had a little terrain engine with a simple "grass" texture tiled on it. Slooooow. Enable mip-maps. Fast again! Try it.
so your syaing if i render multiple polys instead of tiling the texture i will get better performance?
if you had one 100Mb vertex buffer wont fit into the video cards cache. you would have to draw them in order (ie not use an index buffered vertex array) for it to even matter. now as long as you DRAW sequentially, then sure you get your cache coherency with using a single vertex buffer, but you wont get that cache coherency UNLESS you draw sequential. i highly doubt anyone draws all there objects sequentially on how they are allocated from the buffer due to organizing via texture and such. though i guess the objects could still be in squential order.
while you have a point with mipmapping (though in many cases mip mapping is used to reduce aliasing and moire) and STILL dont see how tiling the texture via the uv coordinates vs draw the SAME thing using multiple polys will give better performence. granted in the mulitple poly scenario would draw the complete texture once and then draw the texture again. in the tiling via uuv coordinates you would be getting BETTER cahe coherence due to the fact that you would be staying in the same area of teh texture longer. now i am not sure how big the cache lines are most video cards. woudl someone like to do some testing to see which is truly faster (tiling a texture using uv coordinates vs tiling the SAME texture using multiple polygons).
i still believe his problem is more of a texture switching/fillrate/vsync/state change/something else problem. i dont think that switching how the texture is tiled will make a difference with so few triangles. please someone prove me wrong with source to a d3d8 app that draws in both methods (reason for source is to check to make sure that the code aint cheating). i may attempt this if i have time, because i really think that it depends on how much you are tiling/transforming the vertices before it matters. (ie if you tile really long sections you could be drawing sections that are not on the screen (hidden by other parts of the level or somthing) thus killing yoru fillrate since you dont have the granularity for the culling algo to be efficent)
if you had one 100Mb vertex buffer wont fit into the video cards cache. you would have to draw them in order (ie not use an index buffered vertex array) for it to even matter. now as long as you DRAW sequentially, then sure you get your cache coherency with using a single vertex buffer, but you wont get that cache coherency UNLESS you draw sequential. i highly doubt anyone draws all there objects sequentially on how they are allocated from the buffer due to organizing via texture and such. though i guess the objects could still be in squential order.
while you have a point with mipmapping (though in many cases mip mapping is used to reduce aliasing and moire) and STILL dont see how tiling the texture via the uv coordinates vs draw the SAME thing using multiple polys will give better performence. granted in the mulitple poly scenario would draw the complete texture once and then draw the texture again. in the tiling via uuv coordinates you would be getting BETTER cahe coherence due to the fact that you would be staying in the same area of teh texture longer. now i am not sure how big the cache lines are most video cards. woudl someone like to do some testing to see which is truly faster (tiling a texture using uv coordinates vs tiling the SAME texture using multiple polygons).
i still believe his problem is more of a texture switching/fillrate/vsync/state change/something else problem. i dont think that switching how the texture is tiled will make a difference with so few triangles. please someone prove me wrong with source to a d3d8 app that draws in both methods (reason for source is to check to make sure that the code aint cheating). i may attempt this if i have time, because i really think that it depends on how much you are tiling/transforming the vertices before it matters. (ie if you tile really long sections you could be drawing sections that are not on the screen (hidden by other parts of the level or somthing) thus killing yoru fillrate since you dont have the granularity for the culling algo to be efficent)
quote:Original post by Meduzza
I had a little terrain engine with a simple "grass" texture tiled on it. Slooooow. Enable mip-maps. Fast again! Try it.
Indeed, mipmapping gives you a great SPEED ADVANTAGE at this point... because actually it just gets a lot of detail out from the textures which are drawn at a big distance. You could say, that makes my graphics look less better doesn''t it? Well actually not
details may look very bad from a distance (you really see pixels. Mipmapping smooths them together)Indeed, just try it. You''ll be amazed...
> in the tiling via uuv coordinates you would be getting BETTER cahe coherence due to the fact that you would be staying in the same area of teh texture longer.
Don''t you think it will be the contrary ? Think about it. When you have a 1:1 ratio pixel/texel, it''s like there is no mipmapping. Fine. Now, increase the tiling through UVs, and repeat, say, 10 times the texture over the same polygon. What will the pixel/texel ratio be now ? 1:10. That means, for each pixel, you will have the choice between 10 texels (or 100 in 2D). Increase the ratio, or increase the texture size, and you''ll quickly see that the performance will drop, due to cache misses. Now, if you reduce the ratio to 10:1 (10 pixels reference the same texel), in that case you''ll be staying in the same area of the texture longer.
Btw i''m not saying anything about the original problem. I was just commenting about "does repeating a texture several times slow down ?".
Y.
Don''t you think it will be the contrary ? Think about it. When you have a 1:1 ratio pixel/texel, it''s like there is no mipmapping. Fine. Now, increase the tiling through UVs, and repeat, say, 10 times the texture over the same polygon. What will the pixel/texel ratio be now ? 1:10. That means, for each pixel, you will have the choice between 10 texels (or 100 in 2D). Increase the ratio, or increase the texture size, and you''ll quickly see that the performance will drop, due to cache misses. Now, if you reduce the ratio to 10:1 (10 pixels reference the same texel), in that case you''ll be staying in the same area of the texture longer.
Btw i''m not saying anything about the original problem. I was just commenting about "does repeating a texture several times slow down ?".
Y.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
