Scissor vs. Stencil...samething really?

[Joe Conti]

I'm reading the "redbook" and I'm curious about the difference
between using glScissor and stencling (if we made a rectangle in
the middle).

In other words, is the glScissor function just a specialized equivalent
to a bunch of calls made to glStencilFunc, glStencilOp etc or is there
something fundamentally different about it.

I'm curious why glScissor() would be faster than a stencling a
rectangle.

Thanks,

Joe

[Steve Baker]

Simple really, stencil is a pixel-by-pixel operation that lets
you cull your rendering around very irregular shapes. The price
is that your poor renderer will be spending a lot of time rasterizing
pixels - only to discover that the stencil masked them out.

The scissors on the other hand can only cut out simple shapes
defined by the scissor planes - but the benefit is that this operation
can be done at the polygon level - so that you only pay a per-polygon
price - and the pixel that get snipped off are never rasterized.

...well, at least that's what should happen in practice - in theory,
I suppose an inefficient OpenGL could implement the scissors using
a stencil-like mechanism.

Quite a few PC_based OpenGL systems don't implement a stencil plane,
but I imagine that pretty much all implementations do good scissoring.

--

Steve Baker 817-619-8776 (Vox/Vox-Mail)
Hughes Training Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBa...@link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBa...@airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1
(personal)

** Beware of Geeks bearing GIF's. **

[Paul Martz]

Joe Conti (jco...@nospam.mit.edu) wrote:
: I'm reading the "redbook" and I'm curious about the difference
: between using glScissor and stencling (if we made a rectangle in
: the middle).

Scissor lets you do simple, rectangle based clipping. That's it!

Stencil allows you to do several other much more complex operations,
including polygon edging, shadows, reflections, clip capping, concave
polygons, and others much too numerous to list here.

If all you need to do is clip to a simple rectangle, use scissor,
that's what it is designed for. Stencil would be overkill.
--
-Paul Hewlett Packard Graphics Products Lab

"Technology can be used for good or evil. Please use only for good."

[Paul Miller]

Steve Baker <sba...@link.com> writes:

>> I'm curious why glScissor() would be faster than a stencling a
>> rectangle.

>The scissors on the other hand can only cut out simple shapes

>defined by the scissor planes - but the benefit is that this operation
>can be done at the polygon level - so that you only pay a per-polygon
>price - and the pixel that get snipped off are never rasterized.

I believe the biggest speed advantage is because glScissor() just
sets up a clipping rectangle in window coordinates, and effectively
adjusts the viewport clipping region. Since a final viewport clip has
to happen anyway, glScissor() just changes this region from the default.

--
Paul T. Miller | pa...@elastic.avid.com
Principal Engineer | Opinions expressed here are my own.
Avid Technology, Inc. Madison - Graphics and Effects Software Group

[John]

I'd really like to know where to get programs like this. Can someone point me
in the right direction.

John Hill
mar...@texas.net

In article <67okg3$m...@handupme.avid.com>, pa...@elastic.avid.com says...

[Mark Kilgard]

In article <67okg3$m...@handupme.avid.com>, pa...@elastic.avid.com (Paul Miller)
writes:

|> Steve Baker <sba...@link.com> writes:
|> >> I'm curious why glScissor() would be faster than a stencling a
|> >> rectangle.
|>
|> >The scissors on the other hand can only cut out simple shapes
|> >defined by the scissor planes - but the benefit is that this operation
|> >can be done at the polygon level - so that you only pay a per-polygon
|> >price - and the pixel that get snipped off are never rasterized.
|>
|> I believe the biggest speed advantage is because glScissor() just
|> sets up a clipping rectangle in window coordinates, and effectively
|> adjusts the viewport clipping region. Since a final viewport clip has
|> to happen anyway, glScissor() just changes this region from the default.

Paul, actually there is no such thing as a "viewport clip" in
OpenGL. The viewport just defines the the _transformation_
between normalized device coordiantes (ie, post-projection
coordinates) into window coordinates. There is no _clipping_
involved in this transformation.

OpenGL _does_ perform geometry and raster position clipping
based on the view frustum. This means that most geometry does
indeed wind up being effectively clipped to the viewport, but
that is not always the case.

For example, you can position the raster position outside the
"view frustum" transformed into screen space by doing relative
moves with glBitmap. Likewise, large images can fall outside
the viewport.

If you want a "viewport clip", you can easily set and enable
the scissor to perform such a clip.

Here's an obscure piece of OpenGL trivia to keep in mind. When
you use wide points, if the point's exact center falls outside
the view frustum the point is clipped. You see view frustum
clipping occurs _before_ wide point rasterization.

What this means (if you are not careful), is that points that
wander of the edge of the window will "pop" away instead of
trailing off. Say you want to draw an 9 pixel wide point:

window
boundary each "x" is a pixel, "O" is the
| center of the wide point
| xxxxxxxxx
| xxxxxxxxx
| xxxxxxxxx
| xxxxxxxxx
| xxxxOxxxx This wide point is fully within the window boundary.
| xxxxxxxxx
| xxxxxxxxx
| xxxxxxxxx
| xxxxxxxxx
|
|xxx
|xxx
|xxx
|xxx
O|xxx This point is "staddling" the window boundary.
|xxx
|xxx
|xxx
|xxx
|

(Remeber that wide points are "square" unless you enable
GL_POINT_SMOOTH and blending or alpha testing to "round" them.)

In the top point, everything is cool. On the bottom straddling
point, if you are not careful, the center of the point falls out
side the view frustum and the point is clipped so that none of
the pixels immediately to the right of the point get updated as
you would expect. Imagine a point "roaming" off the side of the
screen. The wide point would suddenly "pop" away as soon as its
center gets clipped.

Of course, there is a way to avoid this. You just widden your
viewport to be some number of pixels wider than the actual
boundary of the window. Of course, you then also need to
compensate in your projection matrice for this viewport
widening. If you do this, then the wide point doesn't get
clipped by the view frustum so it does get rasterized though
only the pixels actually within the window get updated because
the window ownership test does the proper clipping. If you
want your "view" in a subregion of a window, you'll need to
use the scissor (or stencil) to get the clipping right.

This doesn't just apply to wide points. Wide lines and
smooth polygons, bitmaps, and images can also be affected by
this little gottcha.

With bitmaps and images, you don't need to mess with the
viewport thought. Instead, you can use the glBitmap's
relative move of the current raster positon to displace the
raster position outside the viewport. The view frustum
clipping only operates during glRasterPos, not during
glBitmap or glDrawPixels or glCopyPixels.

If you know what to do, this isn't a problem at all. In
fact, it really seems quite logical.

Moral of the story: The OpenGL viewport is a simple
transformation and does no clipping.

- Mark