Alignment of ribbons?

I’m in search for good techniques & inspiration for how to deal with the alignment of the polygons in ribbons. You often see them self-intersect or otherwise look “bad” where the ribbon is bending and if using alpha/additive blending you can notice the unwanted overdraw. I’m especially interested in techniques addressing camera aligned ribbons. Preferably a generic solution so that all sorts of textures and tiling are supported.

Does anyone know of some techniques, papers or game/engines which handles this well? (Either by addressing the alignment directly or reducing the artifacts in other ways)

Unless you are rigidly axis aligning ribbons, in most cases usually they try to align to the camera by rotating around the “spline” of the ribbon string. That makes them prone to twisting. The cheap, least fucktarded way to hide that problem that I can think of right now would be to dot the normal with the view to detect if the segment is gonna be close to parallel to the view (seeing the slice side). Then use that to alpha fade it.
It’s just like fresnel effects. If you range it good enough, it will hide most of the issues.

Thanks for the reply! I do something a bit similar already actually. The ribbon gets faded out with the fresnel angle, but I also have a cross sprite (dynamically generated texture based on the regular texture, in pixel shader so it also deals with variations from tiling) and fade in when the normal ribbon fades out. The polygons are dynamically generated in shaders (geometry shader) so the performance seems ok. Essentially the idea is to divide the visuals into 2 “opposite” cases and blend between them to produce an overall pleasant look. It’s all artists controlled and I do have something which can improve the visuals a whole lot. However there are still some minor artifacts and the current technique put a bit of restrictions on what textures that “works” and which don’t.

Also another related question: Does anyone know of some offline/cgi renderer which handles ribbons well? (i.e. not necessarily real-time)