Using transparency slows rendering considerably (Kids web site) because the renderer
Using transparency slows rendering considerably because the renderer must track the transparency of every pixel in the frame. Without transparency the color of a pixel in the frame is dictated by the color of the geometry closest to the viewer. All other geometry that would be mapped into the frame pixel location can be discarded since it is occluded by the geometry closest to the viewer. If some of the elements in the scenegraph are transparent, however, the renderer must perform a sequence of complex blending operations between the colors generated for a single pixel in the frame. Figure 9.18 Five Sphere primitives with varying transparency, from left to right 100%, 70%, 50%, 30%, and 10%. All of the Spheres have the same color (black) Here is what the Microsoft/Silicon Graphics OpenGL reference says about using transparency: Transparency is best implemented using glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)with primitives sorted from farthest to nearest. Note that this transparency calculation does not require the presence of alpha bitplanes in the frame buffer. You can also use glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)for rendering antialiased points and lines in arbitrary order. The key phrase in the description is, with primitives sorted from farthest to nearest. This is where the problems with using transparency in Java 3D occur. Because transparency is a Shape3Dobject attribute, Java 3D users naturally assume that they merely have to set the object or vertex transparency and Java 3D will take care of everything else. Sadly, this is not the case, as Java 3D provides very little support for sorting the primitives from farthest to nearest. This should be changing however, as Java 3D 1.3 will implement depth-sorted transparency as demonstrated as a Sun presentation at the JavaOne 2001 conference. Traditional 3D rendering techniques rely on the Z-buffer to ensure objects nearer to the viewer are rendered on top of objects further away. The Z-buffer is essentially an array of depth values, one element in the array for each pixel in the frame. As the scene is rendered, the Z-buffer is updated with the distance of the source location for each pixel from the viewer. The Color buffer tracks the color of the closest source location for each pixel in the frame, as shown in the following sequences: Rendering for Surface 1 Prerender pixel at location 5,10. Get depth to geometry for pixel (10 meters). Update Z-buffer with depth to geometry and update Color buffer with color of pixel. Rendering for Surface 2 Prerender pixel at location 5,10. Get depth to geometry for pixel (15 meters). Do not update Z-buffer as 15 > 10 and do not update Color buffer as pixel is not closer to viewer. In this way, when all the geometry in the scene has been prerendered, the Z-buffer contains the depth values for each pixel to the nearest geometry and the Color buffer contains the color for each pixel. When transparency is used, however, the color of a pixel cannot be solely determined from the color of the closest geometry; instead, a complex blend of the colors of all geometry gets mapped to the pixel location. In general, the blending will only be calculated correctly if the geometry is rendered from back to front, which is of 141
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.