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.
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.
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.
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.
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.
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