Archived

This topic is now archived and is closed to further replies.

Alpha blending & speed...

This topic is 5090 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
"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-

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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-

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites