CODEWITHSUNDEEP
openglopengl-3
Aristarhys
Aristarhys

Reputation: 2122

OpenGL projection clipping

For example if we have ortho projection:

left = -aspect, right = aspect, top = 1.0, bottom = -1.0, far = 1.0, near = -1.0

And will draw triangle at -2.0, it will be cut of by near clipping plane. Will it really saves some precious rendering time?

Culling determinate if we need to draw something and discards if out of our view (written by programer in vertex shader/in main program). Clipping == cheap auto culling?

Also just in theme of cheap culling - will be

if(dist(cam.pos, sprite.pos) < MAX_RENDER_DIST)
draw_sprite(sprite);

just enough for simple 2d game?

Upvotes: 2

Views: 1961

Answers (2)

Lars Pensj&#246;
Lars Pensj&#246;

Reputation: 542

Default OpenGL clipping space is -1 to +1, for x, y and z.

The conditional test for sprite distance will work. It is kind of not needed, as the far clipping plane will do almost the same thing. Usually it is good enough. There are cases where the test is needed. Objects at the corner inside the clipping planes may come outside the far clipping plane with the camera turns. The reason is that distance from the camera to the corner is longer than the perpendicular distance from the camera to the far clipping plane. This is not a problem if you have a 2D game and do not allow changes of the camera viewing angle.

If you have a simple 2D game, chances are high that you do not need to worry about graphics optimization. If you are drawing sprites outside of the clipping planes, you save time. But how much time you save depends. If a huge amount of the sprites are outside, you may save considerable time. But then, you should probably consider what algorithm you use, and not draw things that are not going to be shown anyway. If only a small percentage of the sprites are outside, then the time saved will be negligible.

Upvotes: 2

KillianDS
KillianDS

Reputation: 17176

The problem with clipping in the GPU is that it happens relatively late in the pipeline, just before rasterization, so a lot of computations could already be done for nothing.

Doing it on the CPU can save these computations from happening and, also very important, reduce the number of actual draw commands (which can also be a bottleneck).

However, you do want to do this fast in the CPU, typically you'll use an octree or similar to represent data so you can discard an entire subtree at once. If you have to go over each polygon or even object separately this can become to expensive.

So in conclusion: the usefulness depends on where your bottleneck lies (cpu, vertex shader, transmission rate, ...).

Upvotes: 2

Related Questions