Transparency
Users can control the global transparency alpha_mode and transparent RGBA images are supported.
- Press '8' key to change the scenes alpha_mode.
- np_globals table stores the transparency alpha_mode.
- Press '9' or '0' to change selected objects alpha value.
- np_node table stores the nodes transparency color_a (alpha) transparency.
- See Texture Mapping for transparent image formats.
- Transparency Behavior it's not what you'd assume!
| alpha_mode | GL state | Description |
|---|---|---|
| 0 | glDisable (GL_BLEND) | Transparency OFF, all objects are solid. |
| 1 | GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA | Subtractive transparency is similar to layers of stained glass, (default). |
| 2 | GL_SRC_ALPHA, GL_DST_COLOR | Additive transparency is akin to the glow of a flame that adds light on top of the background. |
| 3 | GL_SRC_COLOR, GL_ONE_MINUS_SRC_ALPHA | Dark transparency is an interesting effect that is similar to additive transparency, but does not have a real-world analogy. |
A Short Explanation..............
First, one must understand that Transparency does NOT work the way you would intuitively expect and that there is no such thing as 'standard transparency.'
**Toroidal Paradox, who's in front?
Transparency is one of the most complex topics of any 3D engine, it is accomplished through a serious of approximations and tricks to create the illusion of reality.
In 3D, there is always a balance between speed and accuracy. For example, one of the most efficient, fairly good rendering engines is the default renderer in 3D Studio Max. But note that it is neither the fastest nor the most accurate. Lets consider a hypothetical 3DS scene that could be rendered in 1/30th of a second using OpenGL. It would take approximately 2 minutes to render the same scene in 3DS. However, the 3DS default engine is not good enough for a typical feature film, (3DS is known for its plastic look.) Instead you would typically use a plugin ray-trace renderer which may take 20 minutes or much much more... large scenes often take hours per frame. The main benefit of a ray-trace engine is better reflections and refractions which create more 'realistic looking' transparency, think of a wine glass.
3DS rendering is not done with OpenGL nor is any other professional 3D animation rendering engine. OpenGL is designed for realtime rendering, where we want complex scenes in fractions of a second, not hours.
OpenGL provides some low-level alpha blending functionality that aids in creating the transparency effect. However, it is not just a matter of flipping on a switch and saying make things transparent.
There are a little over a dozen possible alpha modes and about half of them tend to be useful. In general when people think of 'standard' transparency they are referencing subtractive alpha blending, (aka transparency.) This is a akin to colored glass, where the pigment in the glass subtracts out specific color ranges of light passing through the glass from objects behind the glass. Note that this is not the same as the light cast by a laser beam or Bunsen burner. Think of how in a bright light you cannot even see the beam or flame. These transparent emitters of light do not subtract out (a substantial amount) of light passing through them. The effect of a glowing object, flame or laser beam is achieved through additive alpha blending (additive transparency.)
Currently the application supports four modes of transparency. Subtractive, Additive, Dark and None. 'Dark Transparency' has no real-world analogy, and such things are not uncommon in 3D. For example, in GL you can create negative lights and negative color. A negative light is something like a flashlight that casts a shadow (of chosen color,) and so far we do not have any such real-world device, (far as i know.)
The easiest (and fastest,) method of transparency is just to turn on blending. However this usually looks terrible unless everything in the scene is very transparent. The next easiest (and fastest) trick is to render all opaque objects first and then render all transparent objects, sometimes good enough but still very problematic, (an early version of the app use this method.)
Currently we are doing what is typically considered 'proper' transparency and performing a z-sort on objects and then drawing the scene back to front. That is background objects are drawn first and then you work your way towards the foreground. Once again, GL does not provide these methods, just the underlying low-level alpha blending.
So we employ our own custom z-sort draw method which calculates the distance of all root pins relative to the camera. Then applies a q-sort that generates a list that is ordered such that the furthest pins are rendered first and the closest are processed last. The algorithm is relatively efficient as demonstrated by the ability to draw tens of thousands of objects in realtime. Remember that all these calculations are done for every frame. Which is to say, we process on order of a million objects per second.
Conflicts in depth arise from a variety of different cases. First of all we are not calculating the position of sub-objects of a pin. The sub-objects, (child-branches) are drawn immediately after its parent, (starts with the root pin, then children.) This provides proper transparency for the portions of the child object that are in front of the parent object, because it is drawn second, (remember back to front for proper transparency.) But not the other way around. Which is to say the portion of a child object that is behind its parent will not show up, (even if the parent is transparent.) Further, sibling objects are drawn simply in the order they were created. So multiple tori around a parent ring will typically show up properly on one side (right/left) of the parent torus, but not on the other. If you think thats bad, think about the conflict that arises of a torus that is around another torus. Who is in front, neither is the proper answer. Each torus is partially in front and in back. Let's call it the Toroidal Paradox!
One result of these conflicts is that camera view direction often effects the illusion of transparency.
The who's-in-front problem also arises when objects become imbedded or intersecting one another. Methods that deal with this range from particular tricks for a specific set of geometry to more general facet based techniques. The easiest thing to do is turn off depth testing. If everything is fairly (50% or less) transparent this tends to look pretty good. We still z-sort, so this looks better then the most basic techniques. Then there is a geometric specific technique. For example if you want sphere's within spheres. First start rendering the outer most sphere's back faces (the inside of the backside of outer sphere.) Then do the same for each sphere working towards the center. Now reverse the process and render the front face of the inner most sphere. Then work your way out to the front face of the outer most sphere. Note that this technique is relatively fast, but use case specific and needs to know the order of the onion rings, so to speak.
Another technique is to calculate the z position relative to the camera of each facet. However this would handle the Toroidal Paradox and dealing with imbedded objects, but not when facets intersect. For that, you need to calculate where facets intersect and create new facets along the line of intersect, then calculate the z-depth of the new polygons structure. Once again this needs to be done for every frame. At the moment a default torus has about a 1000 facets. So with face based techniques the CPU performance, (GL does not do this, so it is CPU process,) of 50 tori is akin to 50,000 tori. So in general speed vs accuracy needs to be balanced.
Remember this is the short explanation, literally hundreds if not thousands of transparency techniques have been implemented or tried. We expect to enhance transparency capabilities over the years. Just really looking forward to that neural-network holographic quantum computer based on a diamond substrate, (seriousaly, why not!)
**Embedded objects using Additive Transparency (left) and inverted normals (right)
