-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Lyke schrieb: > Christian Mayer writes: > >>Really? I can't think of a reason why modern OpenGL accellerators take >>longer to display transparnet textures than solid ones (except of a >>harmless hardware optimized blending function). > > > ? Transparency require a frame buffer read, a multiply, and a frame > buffer write. Opacity requires a frame buffer write. I've only done > software renderers, but I know a little bit about some of the issues > involved and there's quite a bit of cache contention that happens when > you start doing read/modify/write cycles, beyond the fact that you > have to do the read in the first place.
You allways need a z-buffer read. Then modern cards are doing an early z-buffer test. So the performance hit only happens on those pixels where the fence will end up. As the GPUs have internal caches it's reasonable to belive that the cache strategy can take z-buffer reads into account and keep the color data for the pixels where a recent z-buffer read has happened. As modern programms (esp. the ego shooter gamens used for benchmarks) use(d) multipass rendering and lots of effects with transparent textures it is reasonable to assume that the harware and drivers are optimized for it. In the end only the real measured nubers count. So this debate is very academic and not really relevant. > I don't know whether FlightGear is doing any of this stuff but back on > the main processor transparency also means that there's a whole level > of occlusion culling that can't occur. PLIB sorts the scenegraph to draw transparent objects last. CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDnJVtlhWtxOxWNFcRAvc4AJwJh5csyTgak4hFzpDmrb5Z25vn7ACfckCn N5Qy0fCsHUn8yIVK32+DF7o= =BY59 -----END PGP SIGNATURE----- _______________________________________________ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
