I've searched on google and I haven't found any useful information yet :(.

Is there any one who knows something about this?

there have been tons of different implementaions, I'm surprised you haven't found any.

most recent is the ati mech demo, not sorting just triangles, but sorting individual fragments:

http://developer.amd.com/resources/documentation-articles/samples-demos/gpu-demos/ati-radeon-hd-5000-series-graphics-real-time-demos/

-you can determine correct order using "depth peeling"

-you can use the "painter algorithm" and sorting by the nearest or most far or center point of triangles

-you can do sorting by using BSP trees

-you can use six-side pre indexed meshes, means, you preprocess your mesh to have 6 indexbuffer, in every of those you sort by one axis direction (+x,-x,+y,-y,+z,-z) and during rendering you pick the closest one

-you can dump all visible transparent triangles into some buffer and use compute shader, opencl or cuda to do sorting

-you can do the previous point but with tiles, e.g. 128x128 pixel, that way sorting might be more accurate

-you could use a scanline rasteriser with an s-buffer http://www.flipcode.com/archives/The_Coverage_Buffer_C-Buffer.shtml it's like a realtime per line BSP tree you construct and then evaluate per pixel

-you can use an A-buffer to route pixels and with a custom resolve get a proper sorting up to some limited depth complexity http://www.humus.name/index.php?page=3D&ID=76 (I think there is an extension to this called k-buffer)

Thank you.

You mentioned that triangles can be sorted on gpu, through compute shader, openCl, or cuda. Could you talk more on this? Could you post more information on this? I can't find anyting useful on this topic through search engine.

Last year at Siggraph Asia there was a cool paper on presorted triangle lists: http://w3.impa.br/~diego/publications/ChenEtAl12.pdf I haven't tried to implement it but it looks cool. It uses some prepossessing to make a special triangle list with the triangles in a special order that can be rendered in any view. Of course this order does not always exist so what they do is duplicate some triangles.Then they use a simple test in the one of the shader stages to skip some of the duplicated triangles. The test can be done in either the geometry, vertex or fragment stage in the paper they explain the pro and cons of each stage.

Last year at Siggraph Asia there was a cool paper on presorted triangle lists: http://w3.impa.br/~diego/publications/ChenEtAl12.pdf I haven't tried to implement it but it looks cool. It uses some prepossessing to make a special triangle list with the triangles in a special order that can be rendered in any view. Of course this order does not always exist so what they do is duplicate some triangles.Then they use a simple test in the one of the shader stages to skip some of the duplicated triangles. The test can be done in either the geometry, vertex or fragment stage in the paper they explain the pro and cons of each stage.

Thanks.

The article is insteresting. And it also contains many reference articles in the end. But this method works only for static meshes. And its preprocessing is so slow.

Any other idea?

This paper on Dual Depth Peeling also presents an alternative approach to order independent transparency they refer to as "Weighted Average" (hidden away on page 8). It sounds too good to be true, it's just one pass over the geometry, and then a full-screen blending pass. The results are an approximation, but from the pictures in the paper, the results are indistinguishable from doing it the correct way.

It uses MRT with 16-bit 4 channel target to accumulate RGBA values, and a second target to count the layers of transparency at each pixel. Then the fullscreen pass divides the accumulated RGBA by the layer count and blends the result to the main framebuffer. Super simple.

I haven't tried it myself, but it sounds great for particles. Anyone try it?

This paper on Dual Depth Peeling also presents an alternative approach to order independent transparency they refer to as "Weighted Average" (hidden away on page 8). It sounds too good to be true, it's just one pass over the geometry, and then a full-screen blending pass. The results are an approximation, but from the pictures in the paper, the results are indistinguishable from doing it the correct way.

It uses MRT with 16-bit 4 channel target to accumulate RGBA values, and a second target to count the layers of transparency at each pixel. Then the fullscreen pass divides the accumulated RGBA by the layer count and blends the result to the main framebuffer. Super simple.

I haven't tried it myself, but it sounds great for particles. Anyone try it?

I thought it looked too good to be true at first as well. Unfortunately, trying it out confirmed this. The inaccuracies quickly become quite noticeable if there's a significant difference between the brightness of overlapping fragments. The main issue is that the transparent fragments don't look ordered at all, so a bright fragment in front of a dull one looks identical to a dull one in front of a bright one. In my view, this looks quite glaringly wrong.

I now use per-pixel linked lists to do OIT. It's obviously more expensive than the weighted average approach, but it produces 100% accurate results, and I think it's worth the tradeoff.

I still use weighted average as a fallback, though. It remains preferable to no OIT at all, and might be okay if you're only using it for fast-moving particles or something. I'd recommend giving it a shot, anyway, as it's pretty trivial to implement.

What's your particular situation? Do you have extremely complex transparent objects that need to be rendered perfectly, or do you just need a solution that's on par with current-gen games?

I previously encountered a problem of transparent dresses and hair rendering. I didn't figure out a perfect solution at that time.

Later I have an idea of sorting triangles. My idea is to divide view frustum into many small view frustums, and put centers of triangles of a mesh into those small frustums, and then do sorting on triangles in each small frustum. Because nearer frunstums occlude further ones, we can fill the indices buffer in the order from further frunstums to nearer ones. So that triangles will be rendered from further to nearer.

I wonder whether there is someone who has already implemented such an idea.

What's your particular situation? Do you have extremely complex transparent objects that need to be rendered perfectly, or do you just need a solution that's on par with current-gen games?

I previously encountered a problem of transparent dresses and hair rendering. I didn't figure out a perfect solution at that time.

You probably want k-buffers for that. Much like the OIT method of A-Buffers but limited and designed to handles hundreds of transparencies like you would encounter with hair. Here's a paper.