Recommended Posts

Imagine a hilly terrain viewed from a 60 degree angle. Would it be any faster to render such a terrain using a mesh, as opposed to a series of triangle strips and if so, how much faster?
Consider this, I no absolutely nothing about meshes!

Share this post

Link to post

Share on other sites

OK thanks for the response and ill definitely take a look at that, however, here is what i was going to do, perhaps you could give your opinion as far as speed goes.

One of my main concerns was processing power and memory transfer speed when i designed this.

My map is like a grid of 60 degree triangles, therefore my playing tiles are actually hexagons.

The player viewing angle is fixed north from the sky looking down at about a 60 degree angle.

How the engine works is simple, because your view is perpendicular to the y axis, the top and bottom of triangles, run straight across your screen. So when i am rendering, a render from back to front row for row of only the tiles that are visible.

So far my tiles are using gourad shading and each one is renderd seperately with its own part of my texture image (containing all the tilesets eg for grass,water,ect.)

Heres the part that theoretically saves cpu:The map data is a just a series of vertex(3) data for each and every map tile, so instead of processing data from a map file and filling in a vertex structure that you are going to render, you can simply point the renderer to that particular vertex(3) structure in the map file that is already ready to be rendered, no memory transfer, no calculation!

Share this post

Link to post

Share on other sites

each tile has its own render call, is this noticeably expensive?I don't think i can use a trianglestrip, as each tile has its own portion of map tiles texture surface that it must use, any ideas on this?

Share this post

Link to post

Share on other sites

1) Minimal state changes. There should be very few, if any, provided your terrain is relatively simple. Be sure to use up all the texture levels available to you before resorting to multi-pass blending.2) Vertex-cache coherency. Batch the geometry into fairly large patches - probably bigger than you think is optimal (you should profile to find a decent size). Get D3DX to optimise the vertex and index buffer at initialisation-time. Graphics cards don't mind processing mind-blowing quantities of vertices, provided they are arranged in a cache-friendly manner.3) Fill-rate economisation. Most games today are either CPU-limited or fillrate-limited. Find out which one you are and trade the two resources off against one-another. If you have CPU to burn then it may be worth implementing a PVS system or similar, to cull out occluded (but otherwise visible) geometry. 4) CPU-economisation. If you are CPU-limited, there's probably not too much you can do. However, if you CPU is doing nothing much other than submitting batches of geometry to the GPU and is still bottlenecking, then you aren't using your API effectively. Increase batch sizes, texture sizes and so forth, to get a 'free' visual quality improvement.

In light of this, it is often counter-productive to implement quad-tree culling. If you are going to use a quad-tree (say if you have a huge terrain), then the optimal quad size will probably be larger than you expect. Often, you can afford to put a lot more strain on the vertex pipeline and take a little load off the CPU (in frustum-culling quads) for an overall performance boost.

With regard to the list you just posted, your three essential resources are

1. CPU - used for culling and batch submission.2. Vertex throughput - simply the number and complexity of the vertices being processed per frame, and any vertex-shaders you may be using.3. Fillrate - affected by resolution and overdraw.

Everybody uses Gouraud shaded triangles or better these days. Use flat-shading and you'll be on your own. Triangle-strips offer little or no benefit over cache-optimised lists, as described earlier.