🔒 Locked

Design Question...

Started by NotTaxes Apr 17, 2002 at 3:36 PM 0 replies 200+ views

Original Post

Apr 17, 2002 at 3:36 PM

I''m creating a height-mapped landscape rendering program using DX8 and it''s going along pretty well. I''m getting around 60fps and that''s quite fine for what I''m doing, but I would now like to start really optimising the program as much as I can just because you never can tell when you''ll need those extra fps''. What I am doing at the moment goes something like this: 1: I store the geometry for the map in an array of vertex buffers. Each VB entry in the array desribes a square bit of terrain. The array is 2-dimensional so that I can quickly reference a particular longitude/latitude''s VB. 2: In the render code, I am performing culling by just running a loop that draws all vb''s in the array that are within 10 units of the POV''s direction of view. This means that I do get some ''tiles'' drawn that aren''t visible, but the percentage is quite low. 3: Just before I draw the vb I set its texture This all runs well, but it seems to me that I could really simplify the whole process if I stored the entire map in a single vertex buffer and then just rendered stripes of that VB. Effectively this would reduce the render code to a single drawprimitive statement instead of a loop, which has got to be faster. My problem with doing that is that I don''t know how I can paint individual textures on each part of the map because the VB doesn''t store any texture info other than the offset. I could use a very large bitmap with all the required textures arranged in a grid pattern, so that the tiles would reference different ''cells'' of the texture, but the DX tuts all say that your limit on a texture is 256x256 so... I don''t see how that really helps. The other smaller problem is that I''m using TRISTRIPS for the VB, but if I''m rendering subsets of the the VB, how can I stop the winding order getting all snafu''d? On the first quad, the winding order is fine, but I can''t lead onto the second quad without either overwriting some of the vertices or reversing the winding order. I could use a trilist instead, but that''s already slower. Any opinions?

Dooster

Apr 17, 2002 at 4:53 PM

One possibility when storing all the vertices in a single buffer and you want to use multiple textures (I''m working figuratively here, I haven''t tested this), would be to assign each quad within the mesh appropriate texture coordinates (bottom left, top left, top right, bottom right, of each sub quad in the buffer). You''ll still need multiple DrawPrimitive calls while setting the latest texture and then rendering the next sub-quad in the buffer.

// BIGBUFFER bb;
// TEXTURE tex1;
// TEXTURE tex2;
//
// Set texture
// Draw first quad in bb
// Set texture
// Draw second quad in bb

In my terrain engine I don''t have them all in a single buffer, but thats a design issue due to the way it works. I don''t think multiple vertex buffers are bad if you don''t have ridiculous numbers of them, I think its more important/efficient to use SetTexture functions efficiently as per recommended in optimizations section of the SDK documentation. Ie:

// Set texture
// Draw all quads on terrain that uses it
// Set other texture
// Draw all quads that use that
// ...

After all, if you have one big buffer and only need to update a small portion of it, any actions that influence the buffer influence the lot. Thats one aspect that put me off shoving the whole landscape (dynamic) into 1 buffer. Whereas with individual buffers within reasonable numbers, you can optimize its manipulation of various areas further, based on my own work anyway.

How much functionality your engine has may also affect your decision. If its created once (ala no realtime LOD handling) then a single buffer may be attractive, but if its changing a lot that may be another story, also based on just how big your landscape is.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.