PDA

View Full Version : Rendering lots of polygons slows down FPS too much.



Klick
09-10-2007, 11:38 AM
Sorry for the crappy title, but I didn't know how else to say it.

I am in the middle of making a RTS type game, and my current issue is I do all rendering via the glBegin/end calls.
This is for both the terrain, units, shadows & particle effects.
I tried displaylists, and it didn't help get me any speed gains. It pretty much is the same when I get lots of units on the screen.

I was reading around, and it seems the best thing will be to change those into glDrawElements.

I am mainly rendering quads, quad strips, triangle strips, and some triangle fans.
Would this help out the issue, or should I try something else to speed up rendering lots of units on screen at once?

zed
09-10-2007, 01:12 PM
switching over the vertex arrays should help though
>> am mainly rendering quads, quad strips, triangle strips, and some triangle fans.
but u will need to use a seperate draw call for each strip, which aint good.
its usually much better to dump strips + just use plain GL_TRIANGLES + draw the whole mesh with a single draw call

Klick
09-10-2007, 01:44 PM
Originally posted by zed:
switching over the vertex arrays should help though
>> am mainly rendering quads, quad strips, triangle strips, and some triangle fans.
but u will need to use a seperate draw call for each strip, which aint good.
its usually much better to dump strips + just use plain GL_TRIANGLES + draw the whole mesh with a single draw call I am using allot of texture changes in the terrain tiles I am using. I don't think I can render the whole mesh with just 1 draw call, since that would only use 1 texture correct?
The max # of different textures is around 30, and I do presort them.

Thanks for your help.

zeoverlord
09-10-2007, 03:01 PM
Originally posted by Klick:
I am using allot of texture changes in the terrain tiles I am using. I don't think I can render the whole mesh with just 1 draw call, since that would only use 1 texture correct?
The max # of different textures is around 30, and I do presort them.I am pretty sure you can put most of those textures in one or just a few textures.
As for terrain textures, try doing it though megatexturing.

satan
09-10-2007, 06:13 PM
Originally posted by zeoverlord:
As for terrain textures, try doing it though megatexturing. Do you have any links that provide some details and that do not only talk about how great Quake Wars and Rage will look.

Klick
09-10-2007, 06:17 PM
Originally posted by satan:

Originally posted by zeoverlord:
As for terrain textures, try doing it though megatexturing. Do you have any links that provide some details and that do not only talk about how great Quake Wars and Rage will look. I was just about to post the same thing.
Example code would be nice, I looked around for 'megatexturing' and didn't find any code really. Just lots of speculation on how it is done.

ZbuffeR
09-11-2007, 01:07 AM
The wikipedia page on megatexture is a good starting point.

For the theory, SGI had it with "clipmaps", here is the paper :
http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Texturing/Clipmap.pdf

If you happen to have one of the D3 engine games, one of Doom 3/Quake 4/Prey, you can play with early megatexture prototype :
http://www.doom3world.org/phpbb2/viewtopic.php?f=55&t=19865&st=0&sk=t&sd=a
You can see texture detail popping up when you approach new terrain.

For the implementation, basically you have to do the mipmapping "by hand" because the hardware can not virtualize texture memory (for a given texture, all mipmap levels must be stored in card memory, even if you only see one texel of it).
Contary to classic mipmaps, most MT mipmap levels have the same size, only the smallest ones are reduced by 2.
When camera is moving, you stream newly visible texture parts, replacing parts that become invisible, in 2D texture space, and for (almost) all virtual mipmaps levels.

Please ask if you need more info.

EDIT: and megatexture is used by Id for texture only. ET:QW uses a static mesh for the whole terrain, and not sure about Rage, but it looks like it still have no geometry LOD for terrain.

dorbie
09-11-2007, 11:48 AM
The central concept is to clip per fragment for residence in addition to the LOD test, and of course you want to blend approaching edge of texture residency.

Load ballancing and scheduling of the texture paging subloads to a hidden buffer zone around the resident clip regions is vital to managing performance for a consistent frame rate.

pudman
09-11-2007, 03:57 PM
Originally posted by zeoverlord:
As for terrain textures, try doing it though megatexturing. Before the conversation diverges into theories on how to implement megatexturing, what is the more conventional method to terrain texturing? I assume that's what Klick is trying to do... Simply speed up his current implementation, rather than experiment with megatexturing.

Klick
09-11-2007, 08:37 PM
Originally posted by pudman:

Originally posted by zeoverlord:
As for terrain textures, try doing it though megatexturing. Before the conversation diverges into theories on how to implement megatexturing, what is the more conventional method to terrain texturing? I assume that's what Klick is trying to do... Simply speed up his current implementation, rather than experiment with megatexturing. The main thing that I was interested in was if changing my glBegin/End calls to glDrawElements would help to speed up rendering. I am still not sure if it will, since instead of having 100 glBegin/End calls, I have 100 glDrawElements calls.

For the terrain, yeah, I got lots of reading to do with that megatexturing/clipmaps, it looks interesting, and I just got ET:QW demo to see what it was like. Looks nice. :)
But pudman is correct, I was trying to find the best way to render the terrain instead of using glBegin/End calls.

Again, thanks for the help all!


I should add that most units in this game are under 200 polygons. The average is around 100 polygons for right now.
And when say 60 units come on the screen everything starts to slow way down. This is on a 7600GT gfx card.

Heady
09-12-2007, 06:04 AM
You have 100 glBegin/glEnd calls removed by 100 glDrawElements, thats ok, BUT

1) drawing 100 Triangles per glBegin/glEnd you need at least >100 calls of glVertex3fv (copying >100 times small amount of data from system to graphic, "VERY BAD")

2) drawing 100 Polys per glDrawElements you need only ~1 call to glVertexPointer (copying 1!!! time all data from system to graphic, "NICE")

You see, its a big difference beetween glBegin/glEnd and using VAs:
- number API-Calls (~100:1) in my example
- copying data (many small data / one block data)
so you will have a performance increase (ok, the increase depends on driver, memsubsystem and so on ...).