This is a much more complicated problem than most people realize. Mainly because there is no such thing as “transparency” to a computer…there is only the “perception” of something that looks transparent.
Without going into great detail here, there are two major issues that exist (but there are many other not so major issues as well).
- The order in which you draw “transparent” objects
- The timing at when you draw “transparent” objects.
The effect of transparency is achieved by blending two pixels together by some amount. Those two pixels are:
- The existing pixel in the frame buffer
- The pixel currently being rendered for a given object
So given that, you should be able to realize that if an object that is closer to the camera is drawn first, then the existing pixel in #1 above will never exist (due to depth buffering logic), and therefore, no blending will occur (or at least not the correct blending)…only the object’s pixel will be in the result.
Long story short… In order to achieve any kind of transparent effect the following must happen
- Any object that wants to “look” transparent must be drawn after ALL non-transparent objects
- All transparent objects MUST be drawn in a specific order…from furthest object to closest (i.e. a painter’s algorithm)
That’s the minimum requirement…there are many other issues that can exist, but following the two above will yield ok results in most cases.
That being said… Rhino ensures all of the above, by accumulating any/all objects that have the slightest hint of being transparent, sorting them, and then draws them as the very last step in the pipeline’s “drawing” phase. However, it also does a huge amount of voodoo in order to get open back faces vs. closed back faces to look correct as well…but that’s another long story.
Since conduits can pretty much draw something in any channel within the pipeline, there is no way Rhino can ensure that “transparency” for that object will look correct (for reasons explained above). You cannot just draw something in say, the pre-drawobjects channel, and expect it to produce proper transparent results…
Because of this, there is really no good way to get or allow 3rd parties to do this very easily. The only thing I can suggest you do is:
- Store your “transparent” objects in their own object list, Sort that list based on distance from camera. (Note: This needs to happen any time the camera changes)
- Then make sure you draw all of your “transparent” objects in the SC_POSTDRAWOBJECTS channel
That still won’t be perfect, but it will be much better than just drawing them any time you want from within any channel.
- You create real Rhino objects and add them to Rhino’s database/document, and let Rhino’s pipeline draw them correctly.
Sorry, there’s no magic or silver bullet for doing this…again, transparency is a conceptual thing in computer land, it doesn’t really exist. Making people’s brains think it exists is the trick