5 replies to this topic

[CodeX]

I want to display a mesh with some portions transparent

(defined by the associated texture), so that in some

viewing directions one can "see through" these portions

to some other parts of the scene behind them.

My question is how to implement this in shaders. One

method that I can think of (though I am not sure whether

current architecture could support it) is to carry out a

comparison in the pixel shader: If the current pixel is

a "transparent" pixel, then not only its color output is

killed but also its depth value discarded. So later some

other parts of the scene would be shaded at this pixel.

But this method is based on the following assumptions:

1. one screen-space pixel could be evaluated more than

once in the pixel shader; 2. one could access the depth

buffer in the pixel shader, both of which are in my

knowledge impratical on current graphics architecture.

An alternative approach might be to turn off hardware z

comparison and to perform it manually in pixel shaders.

In this way, the above mentioned assumption 1 is

satified. However, the second one remains not.

So anyone got any ideas? ThanX in advance.

[Nils Pipenbrinck]

My way to deal with such meshes is to do a special passes for transparent geometry.

When I draw stuff I first draw all opaque things, and then the alpha-transparent. Our artists can assign priorities for such meshes/materials, and more than 90% of all cases can be handled that way (e.g. in a city scene transparent windows are *always* drawn after opaque and always before any transparent stuff of the street gets drawed).

For hard cases such as closed objects with transparent faces (a vase of glass, smoke particle systems ect.) we go the old way, and do a per polygon z-sort on the cpu. We'll draw them after opaque and "renderpassed" transparent geometry.

This is not as expensive as it might look like. Usually has already send so much geometery to the gpu, that the time to sort and send the batches overlapps nicely with the rendering.


There are tricks like drawing objects twice with changed backfaces and twiddle with the alphatest, these work great with some kinds where a little error is accepted (e.g. trees). We never felt like implementing them since 90% renders perfect without any sorting).

[CodeX]

Nils Pipenbrinck said:

There are tricks like drawing objects twice with changed backfaces and twiddle with the alphatest, these work great with some kinds where a little error is accepted (e.g. trees). We never felt like implementing them since 90% renders perfect without any sorting).

Thank you. And I am kinda interested in the tricks you mentioned. Can you explain that in more details?

[Nils Pipenbrinck]

I don't know exactly anymore, but I think it was just a two pass render:

1st. Render the object with color-writes disabled, alpha-testing on (choose a compare value to taste) and z-buffer writes enabled.

This will draw the object into the zbuffer according to the alpha testing.

2nd, render the object with color writes on, alpha testing off, and z-compare to equal.

There will still be little rendering errors, but it's usually good enough for anything where the pixels are mostly fully opaque and fully transparent and only little parts such as edges use a bit of inbetween alpha.

[geon]

This is usually achieved with alpha testing. In opengl it is very simple. Just create a texture with an alpha channel, enable alpha testing and set the treshold value.

This works fine with the z-buffer, and can handle interpolated values.

[Reedbeta]

geon said:

This works fine with the z-buffer, and can handle interpolated values.

But it looks rather ugly, because you get jaggies. Even multisample doesn't help with this.