Calculating the scissor-rect of a poly

[Jan]

Hi

I´d like to speed-up my protal-engine a bit by restricting the drawing to only were a portal is placed. That means i´d like to calculate the bounding-rect of the portal-poly, set it as the scissor-rect and let the GPU do the rest.
The problem is, that i don´t know, how i could calculate that rect in screen-space. Does anyone know of a paper, or something, were it gets explained? I couldn´t find something, maybe i searched for the wrong words.

Anyway, during my searching i had another idea:
I could simply render the portal to the stencil-buffer and restrict the rendering to that.
However, although this will restrict the rendering pixel-precise, i am very sure, the gfx-card can´t optimize for that situation very well, can it?
I think, that when i use a scissor-rect it should be possible for the card, to not even rasterizing a hell of o lot of triangles (or parts of triangles), because it should be easy to check if a part of a triangle is inside the scissor rect.
However, when i use the stencil-buffer, then every triangle has to get rasterized completely and then every single pixel gets checked.
This would make the stencil-approach a very inefficient "optimization".

Am i right here, or did i get something wrong?

Bye then,
Jan.

[Catman]

I think you should project the vertices of the poly (using gluProject, or the modelview and projection matrix), and then determine the max and min x and y coordinates...

[ScottManDeath]

best would be to transform all portal vertices to screen space following the "default" way by multiplying the vertex with the modelviewprojectionmatrix, doing perspective divide by w, doing the viewport transformation by scaling and biasing the coordinates. then just find min/max x/y and voila --> glScissor

[Cyranose]

If you're not doing much culling or sorting of your cells, scissoring might save some fill time over stencil. But the real trick (if you're not doing it) is to progrssively cut the view frustum _before_ rendering to cull out detail (or just whole cells) that can't be seen. As you traverse into each cell, cut the frustum to fit the portal you passed through. This would allow you to trivially reject geometry by world-space bbox, for example, and avoid unnecessary CPU transforms (though there aren't too many of those if your # of portals is low). The more you do thst (and if you render front to back), the less the stencil trick buys you.

Avi

[Jan]

Yeah, i know view-frustum culling will be a heavy speed-up. I do it, but not yet with restricting the frustum by a portal.
Anyway, i want to do both as an optimization, because the view-frustum will only reject polys that are completely invisible, whereas the scissor can reject big parts of polys that are partly visible.

Hm, have to try to project the stuff. You mean:
(projection * (modelview * vertex)) / DistanceToViewer ?

Thanks,
Jan.

[ScottManDeath]

nearly as you said, for further details check the spec




v = vertex position, usually with w = 1.0

v' = ( projection *( modelview * v))

[ v'.x / v'.w ]
vn = [ v'.y / v'.w ]
[ v'.y / v'.w ]

then just scale and bias to match viewport dimension/position

[inet]

If your problem is fillrate bound.
you could render those polygons in a small P-buffer and set stencil value to 1 where a pixel is touched(of course, color and depth buffer writings should be disabled to save costs). Then read this stencil buffer back and calculate min/max x,y. Finally do a scale to match x,y to the actual drawing window size.