Jump to content
  • Advertisement
Sign in to follow this  

fastest terrain drawing

This topic is 4126 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

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
I would recommend using something more sophisticated than a simple mesh.

With your own landscape renderer, you could reduce the Level of Detail of distant areas, while keeping closer parts hi detail. Not easy with a mesh.

Personally I use a geoclipmapping terrain engine. This builds a grid of terrain around the viewer at high detail, with progresively less detailed bands moving away into the distance.


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!

Or at least thats my theory anyway.

What do you guys think?

Share this post

Link to post
Share on other sites
You might want to try to minimize state (shader) changes - because they are
relatively expensive... So instead of drawing "patch, object, next patch, ..."
try doing all patches and then all objects.

In our case the shader for the patches was expensive - drawing first
all other stuff, and patches last also brought some performance.

Also try to minimize the # rendercalls

Just my 2ct

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?

What really reduces speed?

Gouarad versus flat (i don't notice a speed difference)
Number of tiles to be processed (definite difference)
Number of tiles to be rendered?
Number of calls to render?
Trianglestrips vs trinaglelist?
Screen resolution (I saw a big difference)
texture resolution (i don't notice a speed difference)

Any opinions?

[Edited by - chosendl on March 4, 2007 5:16:02 AM]

Share this post

Link to post
Share on other sites
The most important considerations on current hardware are

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.


Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!