few large polys vs many small polys

Started by
14 comments, last by chibitotoro0_0 13 years, 11 months ago
Hi everyone,

I've been doing some OpenGL 1.1 tests lately and I've come across the problem of getting low frame rates when I fill the viewport with only a few (~16) polys. However, If I shrunk these polys and added like 50 or so using the same orthographic view, it stays at 60 fps. I'm not using blending or anything and textures haven't been enabled yet. But it seems to me that if more pixels of the viewport need to have its color calculated the slower it goes. Is there anyway to speed this up? I'm thinking in terms of other older 2D platform games, where they overlay many layers of backgrounds without taking a big performance hit even with alphas.

Thanks
Advertisement
In approximate terms, the cost of processing a vertex is simmilar to the cost of processing a pixel. If you increase the number of pixels or vertices that need to be processed, you're going to pay for it.

What kind of graphics hardware are you using / targetting?
Thanks for the reply,

Right now I'm porting my own OpenGL 1.1 engine, that I made from scratch while making an iPhone 3G app, over to iPad.

I know it's possible to use openGL 2.0 on the A4 chip there but I've got more R&D to do with GLSL shaders before i can fully port everything over to 2.0. Seeing how I'm not using anything in 3d for this upcoming app, I don't find a need to upgrade to 2.0 just yet.


Right now if I just render a full screen poly (1029x768) to the iPad simulator it drops from 60fps to 30fps.

That's using only 2 triangles to form this rectangular polygon.

The frame rates go down as I add more smaller polygons to the scene.
Quote:Original post by chibitotoro0_0
The frame rates go down as I add more smaller polygons to the scene.


are you doing any Z testing? I'm sure openGL has support for this right? If you just piling more and more triangles on top of each other you're making the renderer process pixels multiple times.

example if you have one quad that gets drawn with a size of 10 x 10, that means there's 100 pixels that need to be processed. now if you draw 10 textures the same size in the same space, that adds up to 1,000 pixels that need to be processed. If you have Zbuffer testing on and sort your triangles from front to back, then that same situation will only have to process 100 pixels, because all the other 9 textures will fail the z test.

[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
I tried enabling and disabling GL_DEPTH_TEST. Both yielded same results.

I also tried both and stacking a bunch of polys on top of each other and likewise same results.

Thanks for the suggestion, but it seems there's something else that's missing from this problem or is this the limitation of 1.1?
Quote:Original post by chibitotoro0_0
I tried enabling and disabling GL_DEPTH_TEST. Both yielded same results.

I also tried both and stacking a bunch of polys on top of each other and likewise same results.

Thanks for the suggestion, but it seems there's something else that's missing from this problem or is this the limitation of 1.1?


is that all it takes? I never used OGL, but in directx you have to tell it to setup a Z or W buffer and tell it to actually write to the buffer aswell as do depth testing.

maybe it's not writing to the buffer?

[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
I think I've narrowed it down to something...

I disabled textures and it went back to 60fps.
I'm using texparams GL_NEAREST right now. That was faster than GL_LINEAR in my previous app.
Are you using mipmaps? The only reason I could understand the increase in performance simply by switching from GL_LINEAR to GL_NEAREST would be if you're not using mipmaps.
no i am not using mipmaps
Might I suggest you start using them? When Open GL's looking up what colours to use in the texture, it's a lot faster when the texture's a lot smaller (mipmapping enables this to happen by using smaller versions of the texture on objects further away). You'll find it'll look better (since you can keep using linear interpolation), and render faster.

This topic is closed to new replies.

Advertisement