PDA

View Full Version : Single primitive culling



smaidai
09-12-2011, 01:47 AM
Hi

I need to render a textured primitive (let's say a QUAD). I have two options, I would like to know if there's any difference in performance and if there are any other problems with them:
1) Render the quad using coordinates, that I know, will always cover the screen. (Let' say -100000 to 100000)
2) Unproject the corners of the screen and calculate the minimum square that would cover the screen completely. (I don't care about the cost of "unprojecting", just the difference in rendering)

To clarify: the quad is drawn on the xy plane, and camera is free to move around, as long as it points to the ground (you can never see the horizon).

Thanks

mhagain
09-12-2011, 02:41 AM
Why not just use glOrtho?

Alternatively you could use a vertex shader and ignore the projection transform completely.

Either way, for rendering a single quad that covers the entire screen, this kind of setup will not be your bottleneck. Your bottleneck will be fillrate or at the fragment stage.

smaidai
09-12-2011, 02:57 AM
Can't use orthogonal projection and since I'm using OpenGLES 1.1 I can't use the shaders either.

Implementation is not a problem, I would just like to know which of these options would be faster?

I vaguely remember reading somewhere, that openGL clips the primitives to the viewing frustum's planes so that it wouldn't need to waste fillrate on rendering unseen geometry. Does that mean that there is no difference in performance between rendering different sized primitives, as long as they both fill the same amount of the screen and have the same amount of vertices?

Alfonse Reinheart
09-12-2011, 03:29 AM
Can't use orthogonal projection

Why not? Are you somehow forbidden from changing the current projection matrix? That's what the matrix stack is for: being able to preserve the old matrix while you do something new to it. Like make a different one out of whole cloth.

smaidai
09-12-2011, 03:52 AM
I fail to see how changing the projection matrix is related to the question? Sure, it'd be easier to calculate the screen bounds, but manipulating the the matrix stack and constructing the orthogonal projection matrix would take it's toll as well.

Anyway as I said: the implementation is not the problem, I just need to know whether or not there is any difference between the two methods.

Alfonse Reinheart
09-12-2011, 04:13 AM
but manipulating the the matrix stack and constructing the orthogonal projection matrix would take it's toll as well.

No, it will not. Do you honestly believe that a simple glPushMatrix/glLoadIdentity/glOrtho/glPopMatrix is going to affect your application's performance in the slightest? Even on an embedded platform only capable of GLES 1.1?


Anyway as I said: the implementation is not the problem, I just need to know whether or not there is any difference between the two methods.

It depends on whether your hardware has to do actual triangle clipping for massive triangles. There is no way to know for certain without knowing what hardware you are using.

However, if you use the glOrtho method as is standard, you will get the fastest rendering performance possible. Other methods might not be slower, but they won't be faster.

mhagain
09-12-2011, 05:33 AM
Like I said, this part of the pipeline is not your bottleneck. Changing the projection matrix once, or even a few times, per frame will not suddenly cause performance to plummet - hell, even bloody Quake did it on 3DFX hardware back in 1996, and I'm willing to bet that your target platform is a lot better than that.

You're worrying over something that is not a problem. Just change the projection matrix.

mbentrup
09-12-2011, 06:29 AM
Hmm, no one really answers the original question: OpenGL will clip the Quad to the view frustum, i.e. it doesn't matter if your quad is much larger than the screen or if it just fits into the screen. OpenGL will only generate fragments for the visible part of your quad, so the performance should be nearly identical.

smaidai
09-12-2011, 09:26 AM
OpenGL will only generate fragments for the visible part of your quad, so the performance should be nearly identical.


So this is not hardware dependent?

As for the orthogonal projection: This would only work if the camera view direction vector was always perpendicular to the xy plane, this however is not the case. The camera is free to move around as long as it doesn't it doesn't see the horizon, this includes changing it's angle relative to the xy plane. And since the quad is textured, you would be able to tell the difference between perspective and orthogonal projection, even if the quad covers the whole screen.