terrain too slow?

hi folks

i got a terrain built up of apx. 30.000 triangles. it is implemented in delphi with a dyanmic array. when drawing all points i just get 14 fps on my geforce 2 gts.
now, i am new at 3D and you always read about 25 mio triangles and so per second. anybody an idea what i could do to improve, because if possible i would like to keep all the polygons. i also did a test with a displaylist, but no improvement here.

thanks for your help.
martin

ps: how many triangles do your scenes have at the most - during one rendercycle of course.

Use BSP, octree, PVS for only display the polys that are visible.

Thera are many methods for ameliorate the FPS.

well of course one could do a more complex algorithm. in my opinion 30.000 polys is not many. so why the hell is this thing so slow.
where is the upper limit of polys for a today graphics device - e.g. geforce 2 gts - within on rendercycle to still achieve at least 30 fps.

thanks for your help,
martin

Originally posted by Leyder Dylan:
Thera are many methods for ameliorate the FPS.

well, i assume so. can’t you be more specific?
you have to understand i am new to this topic.
when i got 14 fps and each frame renders 30.000 triangles. makes a total of 420.000 polys in all these frames. which is quite far from 20 mio triangles per second. so with all fault tolerance added, where the “hell” is the rest of my frames.

martin

Ok a quick question. When you draw the landscape do you translate the scene to the start point of the quad/triangle that is to be drawn, then translate back to the start point. If this is the case then get rid of it (This slows the fps down s%^t loads). Draw the quads/triangles using the vertex points. ie.

x[0] = (xsize);
x[1] = (x
size)+size;
y[0] = (ysize);
y[1] = (y
size)+size;

glVertex3f(x[0], y[0], data[(yxsize)+x]);
glVertex3f(x[1], y[0], data[(y
xsize)+(x+1)]);
glVertex3f(x[0], y[1], data[((y+1)*xsize)+x]);

ps. Please take into account that this is for a triangle. The ‘size’ refers to the actual size of each polygon. ie.

±–+
| /
| /
|/
+

±-------+
| /
| /
| /
| /
| /
| /
| /
|/
+

hi there,

using vertex arrays with a primitive of
triangle strip can speed up things
a lot.

hope it helps

Mark

OK here are some ways.
Firstly do frustrum culling.
Secondly do backface culling by calculating the direction the normals are pointing in, technically speaking if the normals are pointed away from the viewers perspective then don’t draw the triangle. BSP for a terrain is not practical, so in my opinion don’t use that. Quad tree’s, and octrees are pretty cool. Have not used octrees yet, but hear that they are cool. You can also try some algorithms, like Real-time Adaptive Optimized Meshes (ROAM) but I believe it’s proccesor intensive. Run a search on Peter Lindstrom, to find ROAM. You can also work with large tiles similar to a portal system where you don’t render certain tiles etc.
I also run a GF2 and I can get the terrain to kill it. Terrain’s can be very slow.

thanks to you all guys

kaos: i agree. no, there was no translation in my function.

redzen: i did simple frustum culling with a simple bounding sphere and it really helps the most. i agree do frustum-culling first.

thanks again to you all,
martin

implementing ROAM or octree doen´t resolve the problem with the low triangle throughout
the only think wich hurts is to use buffer objects -> vertex are in video mem -> no bottleneck RAM , AGP transfer