The implementation of visualization functions in `polymake` is divided in two independent layers. At the user accessible front-end there are methods such as VISUAL, VISUAL_GRAPH, SCHLEGEL, etc. Their task is to create one or more geometrical primitives, fill them with decoration attributes like colors or textual labels, and finally hand them over to the back-end layer via the visualize or compose function.

The back-end layer is made up from a set of perl packages, each of them dedicated for translating the geometric primitives to the form understandable by some visualization software. This can vary from writing plain ASCII or XML data files up to generating Java code which should dynamically build the requested drawing.

This design may seem unnecessary complicated, but it became necessary as the number of various visualization tasks grew together with the variety of software packages `polymake` users were wishing to work with. Diverse optional parameters controlling the appearance of the pictures and decorations like labels or arrows made the situation hopelessly confusing. Without clear separation between geometric constructions, decorating elements, and software tools, we had to implement at least quadratically more methods than we currenty have in the rule base.

In the current design the kind of drawing is chosen by the appropriate visualization user method, with appearance attributes supplied as optional arguments. The decorating elements are added in supplementary methods of the geometrical primitive objects. Finally, the visualization software is chosen based on the user's preferences and the capabilities of the back-end interface modules.