draw transparent 3d objects for a CAD like environment

I’m trying to draw transparent 3d objects for a CAD like environment, with opaque objects I have been using the glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ); ( not sure if that is what I want ? )
but I have noticed that the order I read the objects in affects how the transparent and opaque objects show up over each other

I also have noticed that if I turn On Depth testing if the transparent object overlaps an opaque object it shows correctly but then I cannot see through the transparent objects back face sides to see opaque objects behind them.
if Depth testing is off, I can see the back side of the transparent objects and opaque objects behind it but if I rotate the screen the transparent object doesn’t show up first if it is first object the eye would see

Drawing the transparent objects last doesn’t work as well because depending on the screen rotation I can see part of the transparent object which should be behind one part of an opaque object but in front of another opaque ( no z depth )???

So what is the easiest proper way to have 3d objects but also shown correctly that the proper eye view shows the correct parts of the picture i.e. opaque and transparent objects together in screen view but also zdepth with 3d environment and proper pieces of each.

[QUOTE=EricMar;1254753]I’m trying to draw transparent 3d objects for a CAD like environment, with opaque objects I have been using the glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ); ( not sure if that is what I want ? )
but I have noticed that the order I read the objects in affects how the transparent and opaque objects show up over each other
[/QUOTE]
Yep. With the above blend function, they need to be drawn from back to front. With any blend function, order matters, as you can’t rely upon depth testing when dealing with translucent surfaces, as depth testing is all-or-nothing.

[QUOTE=EricMar;1254753]
So what is the easiest proper way to have 3d objects but also shown correctly that the proper eye view shows the correct parts of the picture i.e. opaque and transparent objects together in screen view but also zdepth with 3d environment and proper pieces of each.[/QUOTE]
If you want arbitrary transparent surfaces, there isn’t an “easiest” way. You can either

[ol]
[li] Depth-sort the primitives (which in the most general case is very hard to do correctly), or
[/li][li] Use shaders, render-to-texture and depth textures to implement “depth peeling”, which basically sorts the fragments rather than the primitives.
[/li][/ol]
The second option requires either 3.x or the equivalent extensions. It involves rendering translucent surfaces in multiple passes using two depth buffers. On each pass, fragments are only drawn if they are further away than the fragment drawn on the previous pass, and only the nearest such fragment is kept. So the first pass draws the closest translucent fragment, the second pass the next-closest, and so on. Searching for “depth peeling” should produce nVidia’s original paper, as well as various blog posts and tutorials on the subject.

It’s not exactly trivial, but it’s easier than the most general case of depth-sorting primitives, which requires a topological sort and potentially having to split polygons to break cycles. Depth-sorting primitives is more practical for restricted cases, e.g. if your data is in a BSP tree (or is amenable to using one; this is more feasible for e.g. buildings with large surfaces aligned to axes than for more organic models).

I found some links to it, so it looks like I need to make a shader? and then with that I render in multiple passes… Don’t we get a big performance hit because we have to render in multiple passes?

http://developer.download.nvidia.com/SDK/10.5/opengl/samples.html#dual_depth_peeling

( simple case that I might use…)

It depends upon how much you render in each pass. But the alternative (sorting primitives) isn’t exactly cheap, and the algorithms aren’t particularly GPU-friendly.

If you don’t need correctness, you can just sort translucent polygons by their nearest/farthest/average Z. For some cases, the result will be close enough. For static geometry, you can pre-compute a BSP tree, which makes the run-time overhead more manageable.