Reasons why one added polygon kills the framerate of a scene? (pictures inside)

OpenGL Development JOGL Development
#1

Greetings (again). My last attempt at a topic was a bit too nebulous to provide the information necessary to give worthy opinions, so here’s version 2.0. ^^

I’m new to OpenGL and Jogl so please bear with me, I’ve read the “better read these first” topics but I haven’t found an answer to my problem.

I’m working on a scene representing an ancient Greek theatre, the Epidaurus one. If you don’t know what it looks like and have the Quicktime plugin, go here: http://www.ub.es/telemac/qtvr/grk/epidauro.htm for a 360 look.

Onto the problem. I have most of the structure done. I’ve made it entirely of quads and none of them show clipping or anything. The scene is rendered on top of the Nicholas Campbell Jogl version of NeHe’s “Moving around a 3d world” tutorial. It amounts to, more or less, 5000 quads, and 1 scene unit has been taken as though it were 1 meter of length. There’s also one ambient light and one directional light, and mipmap filtering enabled for textures, though enabling it or disabling it doesn’t seem to do much or any difference at all. The coordinates for the scene are calculated once and then stored in multidimensional arrays for access through gvertex etc.

The problem is that I’m at the point where the theatre looks a bit ugly unless I cover the sides of the ‘staircases’ with ‘walls’. These walls have to be “thick”, so they’re actually solid objects (or mostly that, they lack some faces, ie groundwards etc). I can manage wtih 3 polygons to make a ‘wall’. Up to 2 walls done and placed, everything’s fine. As soon as I place one more polygon to start building the next wall though, the whole scene goes sluggish and the framerate drops. You can tell that because the basic movement provided in this tutorial is not time-based and so the viewer position is updated along with the display() cycles.

Here’s pictures of the scene:

this is the left side of the theatre, there’s a ‘wall’ on the lower level and everything’s fine so far.

http://immano.altervista.org/forum/Capture_17.jpg

This is the same side with a wall added to the upper level: framerate drops dramatically.

http://immano.altervista.org/forum/Capture_18.jpg

Closeup of the area with no wall:

http://immano.altervista.org/forum/Capture_19.jpg

Same as above but with the wall: as you can see, it’s made of 3 polygons: the ‘top’ of the wall, the side adjacent to the stairs, which is as tall as the stairs, and the taller quad parallel to it.

http://immano.altervista.org/forum/Capture_20.jpg

Mind that it doesn’t take that huge polygon to screw up the scene, the thin ‘top’ polygon is sufficient to that effect.
You may have noticed that the textures are monotone…yes, it’s the same texture everywhere, it’s stretched to have different looks depending where it is applied, but the shape is always regular, no inversions or anything like that.
The lower side walls were made first. They seemed to perform much worse with heavy tiling though, so since they even looked better with less, I just had the texture repeated once on them. It’s a standard 256x256 bmp, taken from here: http://www.noctua-graphics.de/english/Tex/stone_01.htm (it’s stone 08).

The machine I’m using is a 2800+ AthlonXP with 1Gb ram and a Radeon 9700, and another thing I think is worth noting is that changing resolution to the scene seems to change nothing. It stutters just as bad at 640x480 as it doest at 1280x1024. Just as it worked as fine in the same range of resolution until I added that one polygon.

So the question becomes: what could be the cause for the sudden decrease? It’s not the size of the polygon. It’s not the position either, I think, cause I’ve taken out the lower walls and put the upper ones in the scene and once again the scene becomes fluid. The polygon’s aren’t clipping with each other or adjacent ones, and there’s no change if I reasonably increase or decrease the tiles of texturing in them…one tile stretched over the whole polygon works the same as four of them on the same surface. At least, I think. A few weeks ago any OpenGL/DirectX client I’d open, be it Jogl or a videogame (Half-Life2, Metal Gear Solid 2, whatever) would display an uncalled for framecounter on the top-right angle of the screen, and now that I’d need that it’s nowhere to be seen. >:(

What I haven’t tried yet is adding a polygon in a completely different region of the scene, and I’m going to try that now, but still, I wouldn’t know what to make of any results it gave. There must be some stupid reason why a 5000-quad scene is fluid and a 5001 one is not, and it can’t be that the whole thing is fed up with me.

Any help would be greatly appreciated. Thanks in advance.

#2

Unusual problem. ???

[quote] A few weeks ago any OpenGL/DirectX client I’d open, be it Jogl or a videogame (Half-Life2, Metal Gear Solid 2, whatever) would display an uncalled for framecounter on the top-right angle of the screen, and now that I’d need that it’s nowhere to be seen.
[/quote]
Fraps perhaps?

Is this all in one (or a few) vertex array calls? Vertex arrays can sometimes have arbitrary limits on how large they can be (such as only allowing 16bit indices). Larger than this may cause some kind of software fallback. Other than that I’d suggest trying without texturing and/or depth testing, or even glColorMask(false, false, false, false) to try and narrow down which bit of your pipeline it could be.

#3

I guess so.

No, but I’ll try that for kicks, too. Thanks.

Like I said, I’m essentially green. I think this is described as “immediate mode”. I just have a (java) array of vertexes, and I feed them to glvertex3fv calls in a bunch of for cycles inside a glbegin-glend section in display(). I do all the calculations to fill said arrays in init(), so display only does simple opengl stuff.
Like this:

gl.glBindTexture(gl.GL_TEXTURE_2D, textures[9+filtering]);
gl.glBegin(GL.GL_QUADS);

for (int rotfactor = 0; rotfactor < numStaircases; rotfactor++)
{
for (int step = 0; step < numSteps; step++)
{
gl.glNormal3fv(vstaircasesN[rotfactor][step]);
gl.glTexCoord2f(stepTex[0], stepTex[1]); gl.glVertex3fv(vstaircases[rotfactor][step][0]);
gl.glTexCoord2f(stepTex[2], stepTex[3]); gl.glVertex3fv(vstaircases[rotfactor][step][1]);
gl.glTexCoord2f(stepTex[4], stepTex[5]); gl.glVertex3fv(vstaircases[rotfactor][step][2]);
gl.glTexCoord2f(stepTex[6], stepTex[7]); gl.glVertex3fv(vstaircases[rotfactor][step][3]);

  gl.glNormal3fv(hstaircasesN[rotfactor][step]);
  gl.glTexCoord2f(stepTex[0], stepTex[1]); gl.glVertex3fv(hstaircases[rotfactor][step][0]);
  gl.glTexCoord2f(stepTex[2], stepTex[3]); gl.glVertex3fv(hstaircases[rotfactor][step][1]);
  gl.glTexCoord2f(stepTex[4], stepTex[5]); gl.glVertex3fv(hstaircases[rotfactor][step][2]);
  gl.glTexCoord2f(stepTex[6], stepTex[7]); gl.glVertex3fv(hstaircases[rotfactor][step][3]);

}
}
[more of the same…]
gl.glEnd();

I simply don’t know how to do any better and, in theory, this wasn’t supposed to get this huge, but since it was working fine…

Thanks, I will try these as well.

#4

Three things you said:

[quote]and mipmap filtering enabled for textures, though enabling it or disabling it doesn’t seem to do much or any difference at all.
[/quote]

I am guessing that your mipmap code is incorrect - Try it again with mipmaps, but don’t set the texture parameters (filter) at all, just take what glu gives you. I am betting that you are setting the glTextureParameter incorrectly and thus invalidating the mipmaps which forces back to non-mipmap, which will eat fillrate when wrapping the textures, especially if the value you invalidated it with was GL_LINEAR.

If I am right, your solution should just be use mipmaps and rem out the glTextureParamter calls (or use mipmap friendly values).

#5

(stupid pc crashed)

(and then I remembered I hadn’t thanked Vorax and Orangy Tang for their replies)

The, uh, the mipmap code I use is in a jar file linked as the jogl version for this tutorial at the bottom of this page: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=10
I did not modify it, I just put it to use. One thing I did not say explicitly is that while there is no change of performance with whatever filter I use (none, linear and mipmap just like in that tutorial I linked), the textures do look better or worse depending on which is being used. At the risk of sounding boldfaced and demanding, could you look it up and see if it does anything wrong? It’s the loagGLTextures and makeTexture methods.

Also, some more insights. After Orangy Tang’s reply, I downloaded Fraps (and the counter looks remarkably like the one I got until a few weeks ago but I hadn’t installed this util until now, so who knows where it came from). In the next 2 pictures, you can see that I added a bit more of wall below. It’s a tall quad with two smaller quads to provide the thickness of the wall. I had the texture look different to point out which one it is. As you can see from the framecounter, at 800x600 this seems to leave performance undaunted, so it can’t be the number of polygons, it must have something to do with either the shape or the position. At 1280x1024, it is stable at a pleasant 60fps.

http://immano.altervista.org/forum/Capture_21.jpg

http://immano.altervista.org/forum/Capture_22.jpg

Now, if I add back the wall that caused trouble, you can see how much the performance drops.

http://immano.altervista.org/forum/Capture_23.jpg

Interestingly enough, that’s the same value I get with 1280x1024 resolution. It doesn’t drop any further, it’s not proportional/directly tied to the rate it has when the wall isn’t there. But it still looks choppy as hell.

As for the mipmapped vs unfiltered textures, here’s a comparison:

http://immano.altervista.org/forum/Capture_24.jpg

http://immano.altervista.org/forum/Capture_25.jpg

This shows that the mipmapping code works. I don’t know if it works well, but it shows.

#6

Have you tried installing a DebugGL pipeline in your init() method? Does it report any errors? Drastic slowdowns can occasionally be caused by OpenGL state machine errors being reported, but as it is necessary to poll for these errors, they can go unnoticed at the application level.

#7

Should it look anything like this?

public void init(GLDrawable gLDrawable)
{
    GLU glu = gLDrawable.getGLU();
    GL gl = gLDrawable.getGL();
    gLDrawable.setGL( new DebugGL(gLDrawable.getGL()));

[rest of init…]

If so, it’s already there. Should I do something with it?

Also, disabling depth test does not do any good to it.

Here’s something else. I’m not adding more pictures right now because I wouldn’t want anyone('s bandwidth) to kill me, but I just tried adding something again. In the first picture of my last post, I showed the ‘vertical’ portion of a wall I added to the lower level of the theatre, and I pointed out that that didn’t slow things down. Therefore, I tried putting a similar one on the upper level, right beside where the one causing problems should go (I have removed that for the time being). Well, putting that one up there once again slows things up. So it seems it is the position and not the shape or size, because once again I’ve tried putting the ‘top’ polygon of that wall only, the small horizontal one, and even that measly quad is sufficient to cause the slowdown. I wonder if it’s a matter of distance from the center of the scene (which is the center of the ‘circle’ the theatre is drawn around), or what else. It can’t be seen in the pictures I’ve posted so far, but at the top of the theatre the whole perimeter is girded with a similar wall and yet it causes no decrease in performance. It just ends at the very angle this new wall I’ve put right now touches on the back side, but is obviously perpendicular to it.

#8

I’d be very surprised if it was the actual position that was causing the slowdown, likely you’ve got some kind of dodgy GL state which is causing a software fallback. Since resolution and mipmapping doesn’t seem to affect it, then you’re probably not having fillrate problems - but disable texturing and check you still get it just to make sure.

It could be that you’re passing in far too huge texture coords, so maybe try with some dummy values around zero or one. Again I doubt thats the problem but it’s worth a go.

#9

Your setup of the DebugGL pipeline is fine, so if it isn’t causing any exceptions to be thrown there’s nothing technically incorrect with your use of OpenGL.

I don’t have any helpful suggestions at this point. I’d try Orangy Tang’s suggestion. Have you tested on other hardware (in particular, NVidia hardware)?

#10

I’ve tried disabling texturing (and boy does it look worse!), but the framerate does not increase back to nominal. It stays at 45fps.

http://immano.altervista.org/forum/Capture_26.jpg

http://immano.altervista.org/forum/Capture_27.jpg

Now, when you say “huge texture coords”, do you mean the values I pass to “gl.glTexCoord**”? Most of the polygons have the standard (0,0) (1,0) (1,1) (0,1) set of coordinates (clockwise and starting from bottom-left). A couple may have that multiplied by 4, notably the two large walls at the bottom. You might be on to something though: I’ve done the code for all the walls, there’s four slopes (2 for each side) and four vertical walls, as it should be visible below:

http://immano.altervista.org/forum/Capture_28.jpg

Ok, so it’s very small, but you can see the slopes now have each a horizontal addendum on the top. Having all the walls drops to 45fps and no further. Now, if let’s remove the walls one by one, starting from the “safe ones”, the ones that didn’t seem to cause trouble.
When we’re left with three walls only, things go back to working ok.

http://immano.altervista.org/forum/Capture_29.jpg

Fiddling with which polygons I leave on, it seems there’s a dependance on the size as well as the number. If the larger polygons ones are already in place, then there’s room for adding very few left. The largest slopes only allow 2-3 very small polygons before the thing slows down. The smaller polygons bundle up better. Considering the rest of the structure is huge but the polygons composing it are not, and this problem begins to show when there are very huge ones at work, I’m guessing the polygon surface has something to do with the problem.

In your (all of you, mind you) opinion, would making the walls out of smaller polygons increase or decrease the performance?

Oh, and I haven’t had the chance to try the thing on different hardware.

Thanks again to everybody for bearing with me so far.

#11

We have actually experienced a similar behavior when debugging AgentFX. When we wrote our portal system we added a dirty debug that used immediate mode to render the actual portals. Strangely enough we experienced a radical drop in performance when rendering just one extra debug portal but if we added a couple of more portals then the drop in frame rate disappeared. We couldn’t find any real solution to why this happened, it just did. My take where that either we had some very hard to find bug or the drivers tried to optimize the immediate gl calls and batch them up and send them to the GPU in larger batches.

So my suggestions are:

  1. Try to add a couple of more polys to see what happens
  2. Try to do a glFlush()

BTW: The drop in performance only appeared on GF3/4 hardware

#12

Well, the glFlush did not do much. I also split the glbegin-end into a handful of them and interleaved glflush calls between them, but no luck that way either. Besides, I’ve read that you shouldn’t have too many glBegin-glEnd couples because they have a cost themselves.

As for adding polygons…the theatre is parametric to a certain extent. I have a parameter which determines the number of stairs and seats of both the upper and lower halves. Right now, the lower half has 72 steps (=36 seats as they’re half that) repeated in 13 staircases (12 groups of seat rows), and the top one has 46 (=23 seats of which 3 are concealed) repeated in 23 staircases (22 groups of seat rows). Well, I’ve removed all the walls and changed the value of the upper level to 100 steps, and still the scene did not loose its framerate (well, it budged down to 57 instead of a full 60…at 1280x1024 though!). It took me bringing it to 150 steps to have it drop to 45fps, which means tripling the number of polygons in the scene and their sizes. Which means that the that more small polygons work better than a few large ones. So I’m going to try and break the walls down into quads and triangles and hope for the best.

Will keep you posted.

#13

SInce you are dropping from 90 to 45 fps, do you have vertical sync enabled? Adding that extra polygon might be causing your program to wait for the next cycle.

#14

Er, I don’t know. Are you referring to settings available on the OS video controls, or is it something more Jogl-related?

#15

It is a driver setting. There should be an OpenGL menu somewhere in ATI’s driver software that will let you disable vertical sync.

#16

It’s set on the default setting of “off by default”.

#17

Some more news. I had decided to go with quads for those huge walls because I thought keeping it all to the same kind of polygon would’ve improved performance.
Out of frustration though, before breaking down the walls into smaller quads I decided to try and make them triangles. That leaves some bits exposed but, on the other hand, seems to be a little more efficient. When I say “a little” I mean that I can draw the four slopey walls with their ‘top’ (or “handrail” if you will) and the internal side, the one parallel to the adjacent staircase, and the framerate stays ok. Unfortunately, adding at this point even the smaller quads which form the horizontal parts of the wall cause the framerate to drop again. So this tells me that the polygon surface is important but, apparently, so is the number of vertices. While the surface is a little smaller with the triangle because there’s that bottom bit missing, I doubt that the point is a reduction of the area, and it’s rather that the system doesn’t like quads that are irregular and have one very short side. Or maybe not. But tomorrow I’ll try and break the rest of the polygons I need to add into triangles and see what that does. If it doesn’t work, it’ll be back to the more-smaller-quads plan.

#18

Is there an always off setting? nVidia drivers used to have a default off setting but vsync always seemed to be on for me anyway.

#19

I see no such setting. I will probably have to update my video drivers as well. But in the meantime, I’ll break down the wall in smaller polygons. Unfortunately this day went wasted as I was robbed of my means of transportation.

#20

Hello everybody again. Thanks again for the replies given so far. I haven’t solved the issue but I think I now have some sort of breakthrough on the reasons for my problem.

Some things you should know:
1) The scene I’m drawing is rendered in Immediate Mode, that is, with glVertex calls inside display(). The reason I’m doing this is essentially that I’m entirely green about Display Lists and Vertex Arrays, not because I don’t want to use them. I’d rather go for it if I knew it could be helpful.

2) The “model” is done mathematically, it’s built through a series of functions which then store all the coordinates in multi-dimensional arrays.

3) These arrays are then cycled through during display() and used to provide vertex, texture and normal coordinates so that the scene may be built.

And in point (3) lies the breakthrough.
So far, I have been trying to render the walls at the side of the theatre with smaller polygons. I’ve made them out of triangles and rectangles. However, this approach has only delayed the point in which the performance of the scene drops down. When I put in the code for the “handrail” in the right lower wall, after having done it for the left one without performance loss, the framerate dropped.

Short version of the story
It seems there are too many for-cycles in the display() method, or perhaps too many things to do in the for cycles. If I insert a for cycle that does nothing (for i=0; i<0; i++, a cycle that isn’t executed even once) in the code that has the proper framerate, it causes a performance drop even though it paints nothing. If I comment that out the framerate climbs back up. Now, if this is enough for you, please skip to the bottom line.

Long version of the story
Before deciding to do a format-reinstall and see if it was a system-wide issue, I decided to test just how many polygons in the handrail I could fit in the scene before the performance dropped. Now, the thing works like this: the walls are read through two nested for-cycles, the inner side (“WallintFirst") of the wall and the handrail ("WallHRailFirst”) are read in the outer cycle, as are the triangles for the external wall (“Wallext*First”). The rectangles are read in the inner cycle as there’s many of them for each triangle (think of it as a triangular matrix).

for (int levels = 0; levels < numFirstWallQuads; levels++)
{
gl.glNormal3fv(WallintLeftFirstN);
gl.glTexCoord2f(WallintLeftFirstTex[0], WallintLeftFirstTex[1]); gl.glVertex3fv(WallintLeftFirst[levels][0]);
gl.glTexCoord2f(WallintLeftFirstTex[2], WallintLeftFirstTex[3]); gl.glVertex3fv(WallintLeftFirst[levels][1]);
gl.glTexCoord2f(WallintLeftFirstTex[4], WallintLeftFirstTex[5]); gl.glVertex3fv(WallintLeftFirst[levels][2]);
gl.glTexCoord2f(WallintLeftFirstTex[6], WallintLeftFirstTex[7]); gl.glVertex3fv(WallintLeftFirst[levels][3]);

gl.glNormal3fv(WallHRailLeftFirstN);
gl.glTexCoord2f(WallHRailLeftFirstTex[0], WallHRailLeftFirstTex[1]); gl.glVertex3fv(WallHRailLeftFirst[levels][0]);
gl.glTexCoord2f(WallHRailLeftFirstTex[2], WallHRailLeftFirstTex[3]); gl.glVertex3fv(WallHRailLeftFirst[levels][1]);
gl.glTexCoord2f(WallHRailLeftFirstTex[4], WallHRailLeftFirstTex[5]); gl.glVertex3fv(WallHRailLeftFirst[levels][2]);
gl.glTexCoord2f(WallHRailLeftFirstTex[6], WallHRailLeftFirstTex[7]); gl.glVertex3fv(WallHRailLeftFirst[levels][3]); 

gl.glNormal3fv(WallintRightFirstN);
gl.glTexCoord2f(WallintRightFirstTex[0], WallintRightFirstTex[1]); gl.glVertex3fv(WallintRightFirst[levels][0]);
gl.glTexCoord2f(WallintRightFirstTex[2], WallintRightFirstTex[3]); gl.glVertex3fv(WallintRightFirst[levels][1]);
gl.glTexCoord2f(WallintRightFirstTex[4], WallintRightFirstTex[5]); gl.glVertex3fv(WallintRightFirst[levels][2]);
gl.glTexCoord2f(WallintRightFirstTex[6], WallintRightFirstTex[7]); gl.glVertex3fv(WallintRightFirst[levels][3]);  

gl.glNormal3fv(WallHRailRightFirstN);
gl.glTexCoord2f(WallHRailRightFirstTex[0], WallHRailRightFirstTex[1]); gl.glVertex3fv(WallHRailRightFirst[levels][0]);
gl.glTexCoord2f(WallHRailRightFirstTex[2], WallHRailRightFirstTex[3]); gl.glVertex3fv(WallHRailRightFirst[levels][1]);
gl.glTexCoord2f(WallHRailRightFirstTex[4], WallHRailRightFirstTex[5]); gl.glVertex3fv(WallHRailRightFirst[levels][2]);
gl.glTexCoord2f(WallHRailRightFirstTex[6], WallHRailRightFirstTex[7]); gl.glVertex3fv(WallHRailRightFirst[levels][3]); 

for (int columns = levels; columns < numFirstWallQuads; columns++)
{
  	  gl.glNormal3fv(WallextLeftFirstN);
	  gl.glTexCoord2f(WallextRectLeftFirstTex[0], WallextRectLeftFirstTex[1]); gl.glVertex3fv(WallextRectLeftFirst[levels][columns][0]);
	  gl.glTexCoord2f(WallextRectLeftFirstTex[2], WallextRectLeftFirstTex[3]); gl.glVertex3fv(WallextRectLeftFirst[levels][columns][1]);
	  gl.glTexCoord2f(WallextRectLeftFirstTex[4], WallextRectLeftFirstTex[5]); gl.glVertex3fv(WallextRectLeftFirst[levels][columns][2]);
	  gl.glTexCoord2f(WallextRectLeftFirstTex[6], WallextRectLeftFirstTex[7]); gl.glVertex3fv(WallextRectLeftFirst[levels][columns][3]);

  	  gl.glNormal3fv(WallextRightFirstN);
	  gl.glTexCoord2f(WallextRectRightFirstTex[0], WallextRectRightFirstTex[1]); gl.glVertex3fv(WallextRectRightFirst[levels][columns][0]);
	  gl.glTexCoord2f(WallextRectRightFirstTex[2], WallextRectRightFirstTex[3]); gl.glVertex3fv(WallextRectRightFirst[levels][columns][1]);
	  gl.glTexCoord2f(WallextRectRightFirstTex[4], WallextRectRightFirstTex[5]); gl.glVertex3fv(WallextRectRightFirst[levels][columns][2]);
	  gl.glTexCoord2f(WallextRectRightFirstTex[6], WallextRectRightFirstTex[7]); gl.glVertex3fv(WallextRectRightFirst[levels][columns][3]);

}

}

So I commented out the “WallintRightFirst” so that it wouldn’t be painted, and extracted the “WallHRailRightFirst” from that cycle, and put it into one of its own. Then I changed its range into “levels<1;” to have it paint a single polygon.
And the single polygon caused the scene to slow down.
That was dismaying. But then I thought “Well, let’s see if having it paint no polygon returns the framerate to 60fps”, and so I changed the cycle into “levels<0”. However, while there was no polygon being drawn, the scene stayed slown down. I then commented the for cycle entirely out, and lo and behold, the framerate climbed back up again.
So what gives? It seems it’s having too many for cycles that bugs the thing out, not having too many polygons per se. This would be consistent with the fact that I already have 4-5000 polygons in place and it only takes one more to screw the scene up. Or maybe there’s too many things in a single cycle, too many tasks for each cycle, but then the fps dropped with the empty cycle.

So, bottom line, does anybody have suggestions as to how to do without for cycles in display, while still reading the coordinates from the arrays in which they are stored? Would display lists help? Are there any caveats?