CLIP_VOLUME_HINT

OpenGL OpenGL: Advanced Coding
1

Hello,
I’m designing a portal engine. I’ve come up with two options: either to clip each visible sctor and its detail in software before rendering them, or let opengl do the clipping. The first approach has its advantage over the second one which is it minimizes overdrawing.
However, OpenGL will clip every thing
sent, and this results in clipping twice the same geometry. Note that the clipped geometry by OpenGL is assured to be inside the viewing frustum. Is there any performance hit with the second approach?
How can I disable OpenGL frustum clipping while CLIP_VOLUME_HINT is still EXT, and not supported by each card.
Thanks.

2

Are you running on a software OpenGL implementation? If not it’ll probably be faster to not clip in software (in fact only do gross culling angainst the portals frustum) and draw in front to back order using the z-buffer. If you REALLY want to do it your way, use the clip volume hint extension. If it isn’t supported it isn’t supported, not much you can do about that.

3

Thanks for your suggestion.
But what does front-to-back order mean for portals? I can have more than one portal at the same level that overlap.

4

The clip volume hint is a mere hint. It’s not a big deal for HW accelerated geometry engines anymore.
Gross culling for bounding objects outside the frustum plus letting OpenGL clip things inside the frustum will do.
Drawing in rough zNear to zFar order gives more depth buffer failures == less depth values updated and fewer color buffer overwrites == fill rate burned == faster engine.

5

Originally posted by wis mak:
Thanks for your suggestion.
But what does front-to-back order mean for portals? I can have more than one portal at the same level that overlap.

are you sure, you created your portals properly ? becouse portals shouln’t overlap at the same level…

6

Consider this case of convex sectors:

±-----------------------+
| |
| S3 |
| |
±-- P3 --±-- P1 ------+
| | |
| |
| S2 P2 S1 |
| | |
| | v |
±---------±------------+

Note that sector S3 is viewed through portal p1 and portals p2 and p3.

Now I start from the viewer sector S1. S2 and S3 are at the same level, since they both are the next neighbouring sectors.

If I render sector S2 first, it’s ok (no overwrites); however, if I choose to render sector S3 first then part of S2 rendering will overwrite obscured parts of S3.

Both options are correct. But the first is faster.

7

Sorry. The graph is messed up. Try to shift the second column of chars to the right till you get 3 sectors.