DisplayConduit ghosted

Hi @dale and everyone else,

Is there a possibility to create actually transparent materials in display conduit? I’m trying to create the same effect as in the rhino ghosted view for my display conduit objects. I’ve tried creating displaymaterial with transparensy but that just creates a feeling of transparensy meaning that i cannot see the objects inside of other objects. I’m guessing this has something to do with the depthwriting…


@jeff - is this something you can help with?

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).

  1. The order in which you draw “transparent” objects
  2. 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:

  1. The existing pixel in the frame buffer
  2. 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:

  1. 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)
  2. 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.


  1. 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 :slight_smile:



Thanks @jeff for the indepth response. Luckily I’ve taken a basic course of computer graphics so all you said makes sense :). I think for now I will opt out to draw all the objects I want to see inside as a wireframe and the all the objects inside of them as shaded. I know that one bottle neck in our plugin is that none of our plugin object is living in the rhinodoc which limits the functionality of our object. In the future we will probably opt out to implement them to rhinodoc. For now we will continue with the duct tape solutions :slight_smile:

What if instead of this (as it is now):

class DisplayPipeline
    static DrawCurve(curve, color)
        // Now draw a curve.
    static DrawMesh(mesh, material)
        // Now draw  a mesh.

class DisplayConduit
    abstract DrawPreObjects(pipeline)
        // Override to draw in this channel.
    abstract DrawPostObjects(pipeline)
        // Override to draw in this channel.

you support another drawing pipeline:

abstract class Painter
    abstract Draw()
       // Override on different classes to each drawing method.
       // Returns its order using channel and transparency.

class DisplayPipeline2 
    SortedList<PainterRank, Painter> stack
    void AddDrawCurve(curve, color, channel)
        // Instead of draw now the curve, add this method to the stack.
        stack.Add(new PainterCurve(curve, color, channel))
    void AddDrawMesh(mesh, material, channel)
        // Instead of draw now the mesh, add this method to the stack.
        stack.Add(new PainterMesh(mesh, material, channel))
    internal Render()
        // Now draw all the stack.

 class DisplayConduit2
    abstract Render(pipeline2)  
        // Override to add draw methods to the pipeline2 drawing stack.

I know it is complex because of all the instances that can come from anywhere and I don’t know how an alternative pipeline could be included, and probably ignore something important, but the idea is there. I don’t think there is a technical limitation to force the system to draw things in the way the developer expects the results, without needing a computer graphics degree. Rhino 6 has a lot of problems with drawing order/transparency using GH. If transparency needs to be rendered at the end, why not force it under the hood? Why allow the developer to restrict the channel (overriding one or another method) is it more important that the system restricts how some things should be drawn? I don’t understand why you never hide the complexity for the developer or end user, as if they had to be an expert, instead of making the implementations dependent on its end use.