In this section, we discuss some advantages and limitations of MLIs. The major limitations are, of course, that viewing direction, position, resolution and lighting are fixed; this tradeoff was discussed in the introduction. However, a result of these same restrictions is that MLIs are very simple to implement. The code for rendering is given in its entirety in figure 2, and the code to generate and compress an MLI is not much more complicated. Assuming that pre-rendered frames and depth maps can be recorded, a script automating the generation phase is also straightforward.
In the next paragraphs, we address some specific issues arising in the use of MLIs.
The generation of an MLI requires the rendering of 2n images and depth maps for each view, but these can be quickly calculated on a graphics workstation. Since this is a one-time cost, it is even reasonable to generate the representation on a machine without any special graphics capabilities. In our experience, the size of a compressed MLI is roughly 3-4 times the size of a single GIF image of the models. This is both a reasonable size for transmission to remote users, and, we believe, an acceptable cost for the addition of important interactive capabilities. In most cases, our representation is smaller than that of any of the strategies mentioned in the related work section.
An important side-effect of our strategy is a limitation on the reconstructed images' lighting. This is a result of the fact that the static lighting is represented as only a simple intensity value for each pixel. Therefore, no colored lighting is possible, and in particular, the specular highlights are rendered in the same color as the rest of the structure's surface, instead of white, which is more realistic and often preferred.
A second side-effect is that back-faces are invisible; this effect is
equivalent to rendering with back-face culling turned on, and is only
significant when structures are renderered semi-transparently. In
applications, supplying separate views that are opposed by 
lessens the impact of this problem.
A significant advantage of MLIs is that overlapping transparent structures are rendered correctly with no extra work, due to the pre-computed front to back ordering of structures for each pixel. To render these structures in a conventional 3D graphics environment, each pixel must be rendered in a depth sorted order, since the contribution of a given structure depends on the cumulative opacity of the structures in front of and behind it. In a traditional Z-buffer algorithm, intersecting and interpenetrating semi-transparent objects cannot be rendered correctly, since rendering is performed in no specific order; therefore different methods are required for such scenes [18]. However it should be noted that we handle a slightly easier task: as discussed above, MLIs show only the front faces of structures, so the problem of rendering semi-transparent self-overlapping structures does not arise.