Ok, so I''ve been going over OpenGL for about a week now, and my frustrations with blending and NeHe''s awesome tutorials have led me to understand that transparent objects must be rendered after opaque objects, and also rendered from farthest to nearest. But no matter what, you will always be able to rotate the camera in a direction where the transparent objects will be rendered in the opposite order. So my question is, how can I code my program so that the order of transparent objects being rendered is always in the _correct_ order no matter the position of the camera? I know one way is to average the distance of the vertices to each and every single transparent objects. But in a more complex scene where there may be hundreds of transparent glass windows, this isn''t the best approach. Is there a better way to do it? If not, could you show me your method of determining the closest and farthest vertices, or give me a site/tutorial? ~Dimple

if you have a scene with hundreds of transparent surfaces, chances are you have some pretty fancy geometry. If this is so, youll probably be using a BSP tree of some sort, which by its very nature will take care of depth sorting for you. Otherwise, using the average distance to the camera should be an adequate method of drawing, since the order of the transparent surfaces isnt likely to change from one frame to the next, meaning you wont have to extensively check each surface every frame.

just remember that you only need to order renderering of transparent surfaces when that transparecy function modifys the existing pixel... for example, additive doesn''t do this, as it only adds. but alpha blend will, because it scales both the existing fragment and surface being drawn, before adding them.

so, sometimes, it simply may be easier to change your blending methods than to create an over complex algorythm to cope with this problem.

so, in otherwords, always use GL_*, GL_ONE...

not sure, but would it help when u disable depthtesting?

glnefugio, it wont help. disabling depth testing will only cause the transparent polygons to overwrite whatever is on the screen without regard to their position - if theyre behind existing objects for example.

you can disable depth writing. this will stop the error you are thinking about.
you should always disable depth writing when using transparency.

glDepthMask(0);
glDepthMask(1);

Usually, translucent scene is drawn that way :

draw_opaque_objects();
glDepthMask(GL_FALSE); // don''t write to depth buffer, but still read it
glEnable(GL_BLEND);
draw_translucent_objects();
glDisable(GL_BLEND);
glDepthMask(GL_TRUE); // enable depth writing again


You still need to sort your translucent objects by depth, though.


One thing I''d like to add is that if you only need to draw objects that are either 100% or 0% opaque (never 50% for instance), you may not sort you objects at all, and just use alpha testing. But the problem is that you can''t/musn''t filter linearly the translucent textures for this to work properly, and you can''t/musn''t use mipmaps for translucent textures.

i take it by blending u mean src_alpha, one minus src alpha. if u use one, one theres no need to sort.

bsps are a possible way but if the transparent stuff is moving eg some fancy billboarded effect.
loop through all the particles doing

dist = squaredlengthofvector( vector( effectpos - camerapos ) )

and then sort the dist''s this should tae next to no time even with 1000 particles

http://uk.geocities.com/sloppyturds/gotterdammerung.html