So when a polygon is concave, you clear the stencil buffer and you draw twice as much. And you don't expect this to go any slower? Generally, doing work will always be slower than not doing work.

Since you are only using one stencil bit, you might try amortizing the cost of clearing the stencil buffer: keep a running stencil ref value and increment it for each polygon, and REPLACE instead of INVERT. Then you only need to clear the stencil buffer every 256 polygons.

But, you should probably describe at a higher level what you're really trying to do, perhaps there is a better, completely different algorithm.

Quote:So when a polygon is concave, you clear the stencil buffer and you draw twice as much. And you don't expect this to go any slower? Generally, doing work will always be slower than not doing work.

yes i expected slower. but i was not sure if slowing to this degree is expected. if i had a major flaw i wanted someone to expose it before trying a completely different algorithm.

Quote:REPLACE instead of INVERT

i need invert because i am using this method of drawing concave polygons

1. Reduce the #of draw calls. Right now I am using one draw call per poly.

2. Use polygon triangulation on concave polygons ad avoid the stencil buffer altogether. The problem here is that realtime triangulation might not be fast enough. Triangulating BEFORE might lead to files (I load frame data from files on disk into memory) that are too large.

The trade-off is CPU triangulation vs draw-time stencil buffer masking. Only you can decide which is better, based on what you are trying to draw.

If your mesh is animated so the triangulation constantly changes, then you should carefully measure the cost of CPU triangulation; for some number of vertices it is likely better to triangulate on the CPU.

If your mesh is static, it's probably always better to triangulate as a pre-processing step (fix the data, and keep the algorithm simple.)