Alpha blending & speed...

Started by
4 comments, last by Erzengeldeslichtes 20 years, 3 months ago
I''ve read here and on NVidia''s Courseware that you want to a) reduce state calls, texture setting, etc, and b) render as many triangles as possible at a time. However, to do "proper" alpha blending when every traingle in the engine could concievably have an alpha value or the texture applied to it could have an alpha channel, you have to render traingles back to front. How would I render triangles back to front while following the speed optimizations above? I can''t set a texture and render every triangle that uses it--the texture may have an alpha channel or any number of the triangles could have an alpha value, and the later textures may (and probably will) have triangles behind the earlier textures. Worse yet, most textures will have some triangles both in front and behind triangles of another texture. Is it even possible to use the above optimizations in such an engine?
----Erzengel des Lichtes光の大天使Archangel of LightEverything has a use. You must know that use, and when to properly use the effects.♀≈♂?
Advertisement
"You do what you can." would be the answer, I think.

If you''ve got a lot of translucent triangles, you''ll need to look at what kinds of translucencies you''ve got.

- Does your source/dest setup commute? If "yes", there''s no need to sort the translucent triangles.

- Can you get away with alphatesting (halo uses this for trees and stuff). No need to sort these.

- Do you have a lot of surface area with alpha == 1.0 or 0.0? If yes, there are some alphatest tricks out there, and you don''t need to sort that accurately, since the error is only going to be apparent in the bilinear bleed in the transition.

Don''t sort what you don''t need to sort. Let the z-buffer do its thing for you. If you''ve got a lot of triangles that are opaque, sort them by your favorite statechange and draw them first. They''ll hide sort errors if nothing else.

At the end, there''s only so much you can do; most non-trivial scenes doesn''t even have a "correct" draw order. Get the error down to an acceptable level.

-Morten-
Quick question - can anyone list a lot of the states that are slow to modify?

Say you do all of your rendering using vertex and pixel shaders. other than setting the texture streams, geometry streams, shader technique and shader constants, there''s nothing more you change.
Any break is slow. There are more than streams to change, you''ll need to think about the render states as well. E.g. you''d generally want to turn off alpha blending if you don''t need it. For a list, look up D3DRENDERSTATETYPE.

-Morten-
Sounds good. Leave z-buffering on and render opaque scene in any order and then render transparents in back-to-front order. My current problem lies in alpha-blended textures. Is there a way to tell if a texture has a alpha channel that isn't pure white without going through each pixel and saying "Is your alpha value < 255?" (At which point I can early escape, which means opaque textures would take the longest. At load time, of course, so not a big deal if not)

[edited by - Erzengeldeslichtes on January 7, 2004 10:04:42 AM]
----Erzengel des Lichtes光の大天使Archangel of LightEverything has a use. You must know that use, and when to properly use the effects.♀≈♂?
AFAIK, there is no other way to make sure. You could use 24bpp for all textures without alpha, so there''d be no alpha to look at

-Morten-

This topic is closed to new replies.

Advertisement