fastest terrain drawing
Author
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!
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.
hth
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.
hth
You might want to check this thread. Which talks about Focus On 3D Terrain Programming, which is a good intro book to terrain rendering techs.
The book examples are OpenGL, but you can get the basic knowledge and understanding of how to apply them.
The book examples are OpenGL, but you can get the basic knowledge and understanding of how to apply them.
Author
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?
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?
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
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
Author
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]
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]
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.
Admiral
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.
Admiral
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
