(2019-07-24, 13:54)Lasse Deleuran Wrote: WebGL only renders transparent triangles correctly when they are drawn before the stuff behind. This is the reason why I am separating transparent and opaque stuff in the code base. Unfortunately I do not know how to fix this issue without either making all transparent geometries not culled, or do some crazy inefficient sorting before rendering.
So what do you guys think? Is this a big enough issue to reduce efficiency by not culling transparent elements, or should it just be left like this?
I've never used WebGL, but for rasterizer-based 3D rendering in general (and OpenGL in specific), you typically need to draw the transparent objects last, not first. That's the only way opaque geometry behind them will be visible through them. Furthermore, you typically want to render the transparent geometry from back to front, not from front to back. Once again, that's so that the transparent stuff in back is visible through the stuff in front. (There is a technique called depth peeling that allows you to render transparent geometry in arbitrary order, but it has a maximum number of overlapping transparent polygons that can be drawn correctly.)
LDView sorts transparent polygons by default (although it does so in multiple threads), and the performance is usually acceptable, since the total number of transparent polygons is usually manageable. Certainly for displaying parts, sorting should be plenty fast. One thing that might improve the results for parts without requiring sorting is to disable Z-buffer writes during transparent polygon drawing. (Leave depth testing enabled, but don't update the depth buffer during transparent drawing.) With non-lit transparent polygons that are the same color, this would (I think) completely fix the problem. If two different colored transparent polygons overlap, the result could be wrong (although it might still be better than what you have now; you'd have to test).