PDA

View Full Version : Speed problem combining raster & polygons



billh
05-03-2001, 07:05 PM
I'm not a programmer, so please be kind...
We develop an industrial simulation application that currently uses s/w
shading. I believe we could benefit from using OpenGL, but have hit a speed problem during our initial investigations. We need to combine a z-buffer raster image with polygonized objects (in several display
lists). We have to update the raster image several times a second whilst moving the display lists around the screen. We're having a serious speed problem using a stencil buffer to blend the z-buffer raster image with the polygons (drawing z values to build the stencil, then drawing the
colors within the stencil). Currently our s/w display is much faster than the OGL display. If we remove the raster image the OGL display is many times faster than the s/w display. Thus it appears the stencil buffer update speed is the bottleneck. Is there any way around this bottleneck? Anyone know of an alternate way to do this?
Also, can anyone recommend a graphics card (for NT platform) with good hardware stencil buffer support?

rIO
05-04-2001, 02:11 PM
Dunno if I can do promotions, just look at the major cards sellers.. I can say nVIDIA...

zed
05-04-2001, 02:32 PM
a lot of cards only have a hardware stencil when they're running in 32bit colours mode.
16 bit colours results in a software stencil buffer.
have u set your desktop to 32bit colour?

harsman
05-06-2001, 05:03 AM
Reading and writing pixels is generally badly accelerated by hardware vendors. If it is accelerated you have to use the right format to get fast copies to hardware. For example, lots of hardware uses and interleaved z/stencil buffer when stenciling, ie 24 bits z and 8 bits stencil.If you use a non-optimal format the driver has to translate it so you'll see a slowdown. However it sounds as if you're using stenciling to integrate OpenGL drawn primitives into an already rendered image (with a z-buffer) by using the stencil. If that's what you're trying to do, (although I didn't quite understand your explanation, so sorry if I'm totally wrong) then it would be faster to just write the depth values directly to the screen (instead of, say calling glClear) and render normally. That way you don't have to translate depth into stencil and you add precision too.