As far as I know, getting partial transparency is a little hard in OpenGL, because you need to make sure you render from back-to-front to make sure the depth buffer doesn’t stop the rendering of objects that are behind transparent things.
So how does this affect the rendering of glow/aura effects? It seems like rendering something like this would be difficult to organize:
[ATTACH=CONFIG]826[/ATTACH]
Thanks!
Correct conclusion, wrong reason. You need to render translucent objects after opaque objects, because translucent objects can’t simply use the depth buffer to cause fragments which are behind them to be discarded.
So you render the opaque geometry first, then render translucent geometry afterwards, testing against the depth buffer but not modifying it.
Translucent objects may need to be rendered in a specific order (either back to front, or front to back with an alpha channel in the framebuffer) so that blending works correctly. Whether or not they do depends upon whether the blending operation is commutative. If it is, the order doesn’t matter.
Glow can often be implemented using additive blending, which is commutative.
For blending operations which aren’t commutative, you can depth-sort objects them relative to each other. Or you can use depth peeling.
Glow/aura effects can often be implemented as billboards, in which case depth-sorting is simply a matter of sorting by eye-space Z. Or it may consist of a simple convex “shell”, in which case you only need to sort complete objects against each other; the front faces of a convex shape cannot overlap.
[QUOTE=GClements;1262930]Correct conclusion, wrong reason. You need to render translucent objects after opaque objects, because translucent objects can’t simply use the depth buffer to cause fragments which are behind them to be discarded.
So you render the opaque geometry first, then render translucent geometry afterwards, testing against the depth buffer but not modifying it.
Translucent objects may need to be rendered in a specific order (either back to front, or front to back with an alpha channel in the framebuffer) so that blending works correctly. Whether or not they do depends upon whether the blending operation is commutative. If it is, the order doesn’t matter.[/QUOTE]
Cool! Thanks for the clarification. That makes things at least a little easier.
[QUOTE=GClements;1262930]
Glow can often be implemented using additive blending, which is commutative.
For blending operations which aren’t commutative, you can depth-sort objects them relative to each other. Or you can use depth peeling.
Glow/aura effects can often be implemented as billboards, in which case depth-sorting is simply a matter of sorting by eye-space Z. Or it may consist of a simple convex “shell”, in which case you only need to sort complete objects against each other; the front faces of a convex shape cannot overlap.[/QUOTE]
Ah, that makes sense. Re-ordering renders according to eye-space Z makes me a little sad, since it makes things a lot more sequential, and means I need to be keeping special track of translucent objects, but it sounds doable.
Thanks!