Jump to content
  • Advertisement
Sign in to follow this  
floyd3

OpenGL FTS drawback in Heightmap

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

I have a 256X256 map (each "tile" consists of 2 triangles) with texture and a pre calculated lightmap. My system barely manages to keep up with a sensible fps rate, unless I put my LOD into action but then I lose terrain details... I am using OPENGL and I do use triangle strips and display lists. Is that reasonable? I have an Athlon XP 1.8, 512RAM and a brand spankin TNT2 ULTRA (32 mb). Please dont tell me its my card cuz I got TombRainder 4 running smoothly. What am I doing wrong?

Share this post


Link to post
Share on other sites
Advertisement
Hi,

If you aren't already, you should try using vertex buffer objects (most cards support them nowdays ..hopefully even tnt2's). This will definately give you a noticable speed increase :D

Regards,
ViLiO

Share this post


Link to post
Share on other sites
Tomb raider probably doesn't display 131072 triangles at once. I'm not that impressed with the tnt2, my friend has one and couldn't run an asteroids game I made. Ran fine on a geforce 2mx, but even without the bump mapping, was terrible on his pc.

Share this post


Link to post
Share on other sites
If I understood you correctly, each pixel in the 256x256 map will be converted into one vertex in your terrain. This creates 255 * 255 * 2 = 130,050 triangles. Without culling, all of them will be sent to the card for rendering every frame.

As a comparison, Quake 3 aimed for a maximum of 15,000 triangles per frame, with the number usually residing at around 10,000. The very latest games (like Battlefield 2) render 100 - 500k per frame.

I'm not sure what your limiting factor is -- whether its fill rate or pushing too many vertices or what. Regardless, 130,050 triangles every frame for some terrain is a ton, especially for an older card like yours. It is really essential that you break up your terrain into small sectors of, for example, 33x33 vertices each (2048 triangles). With some culling, you can limit each frame to drawing only a few sectors at a time.

Share this post


Link to post
Share on other sites
Thanks for all of you.

ViLiO -

But its a scorch - like game, so my map should be visible at all time...
How do they manage to make such huge maps...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
TNT2? That was 1999. Or in graphics years, about a million years ago. The latest NVIDIA card is roughly 100x faster on tris/secs.

Share this post


Link to post
Share on other sites
While TNT2 is very much slower than modern cards, that doesn't change the fact it is a very powerful card. Quake and Quake2 would run in software, this was as the first 3D accelerators came in and made everyone gasp at the increse in detail possible (especially the Voodoo 1). The the Voodoo 2 made everyone gasp again. I think TNT and Voodoo3 were the same generation, then TNT2 came next. It is pretty fast but it can't draw 100K+ triangles at once. If you can do it on a GF2 then you are doing lots of lighting which is donw in hardware on the GF but not the TNT2. You could try precalcualting lighting; otherwise you have too many polygons. You don't need that much detail - if the whole map is on screen at once viewed from above then you can get away with only 2-4K polys with good results. Is the colouring coming from the verrtices or a texture stretched over the map?

Share this post


Link to post
Share on other sites
Hi again,

Bare in mind that if you are rendering a grid of 256x256 tiles and each tile is made of 2 triangles ...that is over 130000 triangles. I doubt you will find a single instance in tomb raider 4 that has that many polys on screen at the same time (I could of course be wrong but it does look very low poly). So don't be too disappointed that your tnt2 can't handle that many polys.

You can squeeze some performance out and get it running at a higher fps i'm sure if you use vertex buffers or at the very least indexed vertex arrays but brute forcing that size of map shouldn't be necessary. Using a level of detail algorithm is a must :D

If you could give some more details on what opengl calls you are using to render your map then I'm sure we can help you optimise it more and push your tnt2 to its limits :D

Regards,
ViLiO

Share this post


Link to post
Share on other sites
Thanks alot everyone -

First of all, I am using LOD.
I apply each vertex with a unique color, and I also combine a stretched texture over the map.
I'm also using lightmap so GL dont have to calculate the shadows and normals by itself (although I didn't see any fps drawback when the options is off).

I am using a display list as for now.

I dont know if my card supports vertex buffers.
What are the common GL procedures for using them?
I dont know if my data structure is compatible.
a 3d vector struct ,which all the vertex, normals and colors are stored in, is something like that:
struct VECTOR3D
{
float x,y,z;
...
};

is that good?
do I need to change (x,y,z) for a "float[3]" type?

Share this post


Link to post
Share on other sites
To create and fill up the buffer:

GLuint vbuffer=0;
glBindBufferARB(GL_ARRAY_BUFFER_ARB,&vbuffer); glBufferDataARB(GL_ARRAY_BUFFER_ARB,(size of data),(pointer to first vertex),GL_STATIC_DRAW_ARB); //STATIC_DRAW because you probably wont change your heightmap dynamically.

Then drawing with the buffer is exactly like normal vertex arrays, except before you start you do:
glBindBufferARB(GL_ARRAY_BUFFER_ARB,&vbuffer);
and instead of pointers to your vertices you use offsets from the beginning of the vertex buffer.

OpenGL is very flexible with the vertex formats it will take. You won't need to change anything in your structure.

You should also use indexed drawing (DrawElements instead of DrawArrays ) to cut the number of vertices in half

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!