Transparency in shaders

Replies to This Discussion

Permalink Reply by David Rutten on November 27, 2012 at 5:43am

Hi Miguel,

what alpha channel where?

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Miguel Vidal on November 27, 2012 at 10:13am

Hi David,

I may not have made myself clear. I meant the alpha channel of the colour swatch component, for instance.

It seems to me like there is an order of visualization in Rhino, depending on the order of the collection that comes from GH itself, and although some objects are meant to have transparency, if they have different colour than objects "below" in the list or datatree, they are overlapped by those "above".

I hope I am clear now?

▼ Reply

Permalink Reply by Daniël Smidt on June 26, 2013 at 1:43pm

I have the same problem. The red surface is transparent but the sphere below is not shown. (Note the red cross and blue curve).

Permalink Reply by David Rutten on June 27, 2013 at 1:55am

Indeed. This is a known problem but it's not a bug as such. To understand what is going on here you need to know how OpenGL draws 3D objects. If you would just draw every object without any testing then the draw order would completely determine the display order on the screen. You can see this in Rhino if you have text-dots. The top-most dot (in case they overlap) is not necessarily the nearest one, it's the most recent one.

To get around this you could sort all the object from back to front prior to drawing them. That way objects that are nearer will be drawn later and will thus be drawn on top of those objects further away. Rhino does this for geometry in the document, Grasshopper does not do this, partly because there is no single repository for all the preview geometry. It is stored in lots of different places.

But now you still have a problem with objects that intersect or interlock. Sometimes two objects cannot be properly sorted back to front. Some part of object A is closer to the camera and another part of object B is closer to the camera. This is where z-buffers come in. A z-buffer is a greyscale image of the same dimensions as the 3D viewport. Every pixel in the z-buffer 'remembers' the distance from the camera to whatever object is at that pixel. You can use the Rhino command _ShowZBuffer to see what it actually looks like:

There's three important things going on here:

1. The textdots are missing. This is why they do not properly display based on depth, they are omitted from the z-buffer.
2. The inside of the cylinder is missing. I'm not exactly sure why right now, this needs looking into.
3. The transparency of the cylinder is not represented in the z-buffer.

OpenGL uses a z-buffer to figure out whether an object is visible or whether it is obscured by something in front of it. Actually, that's wrong. A z-buffer is used to determine whether a specific pixel of a specific object is visible or whether it is obscured. For every pixel of every object that OGL draws, it first figures out the distance from the camera to that location. This distance translates to a certain grey-scale value. The further away it is, the darker it will be. Then it looks at the z-buffer to see whether the current colour at that pixel is brighter. If it is, then something else which has already been drawn is in front of the thing we're currently drawing and therefore obscuring it. In this case the pixel will not be drawn.

If the z-buffer is darker than our local colour, then whatever is in the viewport is farther away then what we're trying to draw now and we can go ahead and draw it. Then we'll need to update the z-buffer to reflect the new shortest distance from 'stuff' to the camera at that given pixel.

This scheme is brilliant and due to hard-ware acceleration incredibly fast. However it completely breaks down when transparency is involved. There's no way to encode transparency in a greyscale z-buffer image. Something is either in front of something else or it isn't. Whether any of those two objects are transparent doesn't enter into it.

To (partially) get around this, Rhino sorts all geometry back to front and uses a z-buffer and draws objects in multiple layers. Grasshopper only uses the z-buffer. That is why transparent objects will sometimes fully occlude objects behind them, because the representation of transparent objects in the z-buffer is the same as the representation of fully opaque objects.

Partly this is for performance reasons and partly it is to keep the code simple and easily extendible.

--

David Rutten

david@mcneel.com

Tirol, Austria