drawprimitive 10000 times
Author
thanks people,
i changed or in english eliminated the loop
i changed to trianglelist & made
g_pd3dDevice->DrawPrimitive(D3DPT_TRIANGLELIST,0, 20000);
it changed to this,i mean i added 2 more vertices for each 2 pairs of tirangles,but i took the chance of making only 1 single draw call,like u guys suggested.thanks :) and read the .pdf s u gave a little and it says every draw call is a cost :)
now my problem with optimization isnt finished,im continuing
now the problem is,i have a map[100][100] for textures of tiles and in compile time i create a vertex buffer that is 6*100*100=60000
and then set textures.and then render and scroll the map.its 100x100 triangles.
and because i call draw for 20000 triangles,then scroll,there is only 1568 triangles seen at each time,but i dont know how can i select those then render from vertexx buffer in a correct order.
i mean,i call draw for 20000 triangles,but i only have 1568 triangles in the tilemap that fits on the screen at a time.
so it clips internaly or what?giving more than i can see is a problem?
yes you are better off sending the whole thing and letting the GPU vertex pipeline handle the clipping or tossing of unused vertices. If you find that you are having a performance problem, you could create patches of index buffers. In your case as it is now brute force is probably the best bet, if its working for ya. If you need to dolots of texture switches for different triangles or quads, use a texture atlas. So for your tilesyou will have one Vertex Buffer, and you will use one texture. anyway those are just my quick thoughts.
If you can divide your map into sections and somehow cull large groups of vertices at a time, you won't have to pass as much data to the GPU, which is good.
This slideset says that you only get 10,000 - 40,000 batches per second. So, your performance is definetly going to be terrible [wink]. Take a look at that slideset for some more good info on batching.
Author
yeah,i made 1 picture for 2 textures,i map, via texels.
with tiles,
i made a so big array for scrolling,and holding vertice data,but all the shapes of the tiles are same,they are <> this,i mean diamonds,made of 2 triangles each,but the reason i create so many vertices is,to hold different texture data for different tiles,i mean one is grass,one is dirt.
but also ,i want to give heights to some tiles,i mean i will distort y components of quads and make the illusion of hills,
so do i need to only hold the vertice data that is for rendering 1 screen,
and then at real time lock that and add height and texture data from another array that holds only these two?
Quote:Original post by blue-ice2002
yeah,i made 1 picture for 2 textures,i map, via texels.
with tiles,
i made a so big array for scrolling,and holding vertice data,but all the shapes of the tiles are same,they are <> this,i mean diamonds,made of 2 triangles each,but the reason i create so many vertices is,to hold different texture data for different tiles,i mean one is grass,one is dirt.
but also ,i want to give heights to some tiles,i mean i will distort y components of quads and make the illusion of hills,
so do i need to only hold the vertice data that is for rendering 1 screen,
and then at real time lock that and add height and texture data from another array that holds only these two?
The vertices in your Vertex Buffer should have your texture cords already pre-set based off of your texture atlas of terrain (grass, dirt, etc.). Your Y axis should also be preset to whatever the heightmap requires for that tile. Because you are using a vertex buffer, you would only want to use one VB for the map. If you are using a top-down view (tiles) then you should look into using a quadtree and Index Buffer patches to maximize the efficiency of what actually gets passed to the piepline.
Remember the GPU uses virtually no overhead for discarding vertices, its sending them to the pipeline that requires lots of time.
Hope I understand what you are trying to do.
Quote:Original post by KrazeIke
If you can divide your map into sections and somehow cull large groups of vertices at a time, you won't have to pass as much data to the GPU, which is good.
As KrazeIke says, its all about culling large groups of vertices.
Theres an emphasis on being able to eliminate large groups as you can (in theory) remove 1000's of triangles with one "cull" - a potentially more precise method of checking every single triangle for culling goes full circle and still gives you a nasty fine-grain loop again [smile].
You might well want to have a look into the "Quadtree" algorithm - its quite well suited to efficiently culling large, regular, tile-like grids. This article from this very site is a pretty good introduction to the topic.
hth
Jack
blue-ice2002, You might want to consider using Dynamic vertex buffers for your problem. Or buffer you data and then drawing the data/buffer as needed
Author
Quote:Original post by blue-ice2002
hello ,
my tilemap is this.
its 200*200 quads.
i want to render&scroll it efficiently,but as u said i should draw only the one that are on screen,not the whole map.
but how? the quadtree is a good example,thanks.but mine has no camera,no z component.
its top-down & uses orthogonal projection.
Like I said the best thing for you to do is to use one Vertex Buffer, do'nt use a dynamic vertex buffer, because the vertex information does not and should not change. Now using the quadtree algorithm you can divide the vertex buffer into smaller chunks (smallest being the size of the screen). These smallest patches will be Pre-Computed Index buffers. So using quadtree algorithm it will tell you what index buffer patches to render. So you need:
1) One giant Vertex Buffer (for terrain - tiles)
2) One giant Texture - will all types of terrain in small patches
3) Quadtree algorithm breaking down into smallest size (# verts on screen)
4) Index Buffer's make up small chunks on screen
With this only 4 possible Index buffer Chunks can be renderedon the screen at once, using multiple patches of terrain texture. Hope this helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
