**Rendering Order
**

This images shows the rendering order problem, in the left image the bottle is drawn in front and in the right it is drawn behind. Here the objects are sorted on distance to the camera (the object’s position to the cameras position) so only by moving the camera it’s possible to change the rendering order. This problem can be even more complex when the object itself needs a internal rendering order to look correct.

**Shadows for Transparent Objects**

In this image the fully transparent (opacity 0) bottles cast shadows that are too dark. The reason for this is the shadow maps only store a single depth for each pixel which means that there is only a “cast shadow” or “not cast shadow” for each object, while it here should cast a softer shadow since some of the light is passing through.

**Distance Fog and Transparency**

Here is the distance fog calculation not calculated correctly making the transparent object get more fog applied than the surroundings. This problem should be easily solvable but it’s a general problem for transparent objects in fog that the fog needs to be calculated for different depths of the same pixel.

**Clouds and Transparency
**

The left image is the bottles seen from above and in the right image the camera is placed on the left side of first image, viewing the bottles from the front.

**Instancing and Transparency
**

To increase performance, objects of the same type are often instanced so they are all drawn in the same time. It can be seen as many objects are combined into a single object which means the objects needs to be sorted internally to be drawn in the correct order.

**Depth of Field
**A shader technique which requires the depth of the objects to work is Depth of Field. As can be seen here the bottle, even at the same depth in the scene as the barrel, looks blurry, the reason is that the transparent objects don’t write any depth so the bottle uses the same depth as the background.

**Physical Notation
**

**Radiance **is the amount light that is received from a solid angle . This can be seen as the amount of light that is reflected, emitted, transmitted from a point on a surface and hits an observer, e.g. the eye. It’s measured in watt per solid angle per square meter ().

**Bidirectional Reflectance Distribution Function (BRDF)
**The BRDF is a function () which takes a point at a surface, the incoming direction vector of light, the outgoing direction vector of light and returns the amount of light reflected in the outgoing direction. The incoming and outgoing vector must be part of a normal oriented hemisphere .

**Bidirectional Transmittance Distribution Function (BTDF)**

The BTDF is closely related to BRDF () but where the outgoing direction vector must be on a negative normal oriented hemisphere. The function gives the amount of light transmitted through the material.

**Transparency Model**

In real time rendering a simplified model is usually used. The BTDF function is usually set to only transmit light in the opposite direction of the incoming light. In reality the light also scatter in the transport medium, this effect is mostly ignored unless it has a large impact on the result, like in fog like effects.

**The Rendering Equation
**The rendering equation gives to total light going from a point of a surface into an observer. : Outgoing radiance from the point in the direction . : Incoming radiance to the point from the direction .

The reflected and transmitted components are given by the amount of incoming light from respective hemisphere, the BRDF and BTDF functions and the angle from the normal.

**Painters Algorithm
**The idea is to work like a painter by adding the background first, and then add the next layer, maybe some distance houses and work through all the layers till you are at the front figures. In 3D rendering this would be to sort all the objects on the distance to the camera. This algorithm has many problems as can be seen in the image below, which colored rectangle is furthest away from the camera?

**Depth Peeling
**Renders the transparent objects

**Stochastic Algorithms**

To speed up the algorithm and use a fixed amount of memory, it’s possible to use sample the transparency using a random sampling pattern. The idea is to take *n* samples for each pixel to be rendered and try to make the number of samples for each transparent layer proportional to how much they contribute to the final color e.g. if we have 3 layers, front (a) 75% transparent, middle (b) 25% transparent and background (c) 0% transparent. We use 16 samples (4×4 pixels) and then render order is (b) -> (c) -> (a). (b) is rendered, filling 75% of the samples and also keeping track of the depth. (c) is rendered, since it’s depth is lower and covers 100%, it fills all the samples not filled by (b). Finally (a) is rendered, with the lowest depth, it writes on top of all the other samples, filling 25% of the samples.

When all the samples are gathered the average of these 16 samples is used as the color for the pixel.

**Commutative Function
**The rendering function for transparency is not commutative, that means that it’s not possible to switch places of the terms in the function (in the rendering this means that the layers must be rendered back to front). If it would be possible to find a function that has the same result as the transparency function but where the terms could commutative would make it possible to render the layers in any order. There are some attempts to find a function with these properties but all of them only give an approximation of the of the correct result. The equation below is the transparency equation and it’s repeated iteratively, back to front.

**Per Pixel Linked List
**To get an exact result all the layers must be saved and drawn in the correct order. To accomplish this on a graphics card a method where each transparent layer’s pixels are stored in linked lists can be used and then finally sort the lists and render it. This uses both lots of memory, GPU time and require some kind of synchronization for the lists. Approximations exist where only the

**Weighted Order Independent Transparency
**An

**Adaptive Transparency
**Uses a combination of

]]>

In rasterization, opaque (none-transparent) objects are render to the screen in any order but only the objects closest to the screen are saved. With transparent object, not only can many layers contribute to the final color but also the transparent objects need to be rendered in the correct order. With an simple approach this both adds required computational power to sort the layers, and added memory usage to store the layers, both of these are not available in large amounts when doing real time graphics.

My goal is to find a solution that with the given constraints (CPU power and memory) get as good visual quality as possible.

]]>