Web interface for contour

This is an experimental web interface for the appcontour that allows to experiment with some of the features of the code. Since it creates a heavy load on the server there is an authorization mechanism that should keep spiders and crawlers out of it. Just enter guest as user and password to gain access.

Click here to enter

Examples

Examples are divided in two categories:

Embedded: are apparent contours coming from the projection in 2D of an embedding of the 2D manifold (no selfintersections!). In this particular case, a so-called Huffman labelling is attached to the arcs of the contour which carries the information on the depth where the fold corresponding arc is located in space with respect to all other intersections of the light ray with the manifold.
Immersed: apparent contours corresponding to surfaces immersed in the 3D space (selfintersections allowed). Currently all examples correspond to surfaces that do not have singular points (Whitney umbrellas), however there is no particular reason to exclude such examples. Immersed manifolds do not possess a Huffman labelling.

Orientation of arcs

For terseness of the figures not all arcs are represented with their orientation. In most cases however the actual orientation can be inferred just recalling that:

The orientation carries over to arcs directly across nodes.
If one or more cusps are present, the orientation of the arc is forced by the rule that all cusps correspond to sharp left turns of 180 degrees when traversing the arc according to its orientation.

Huffman labelling

A Huffman labelling is an integer function d defined on the arcs. Such function must satisfy a number of requirements in order to be a valid Huffman labelling [BeBePa07], in particular it must be nonnegative and locally constant far from crossings and cusps. In all embedded examples, the labelling can be inferred by the line style of arcs:

solid lines: d = 0,
dashed lines: d = 1,
dotted lines: d = 2.

For arcs with labelling larger than 2, the value of d is displayed.

Visualization problems

The showcontour code, responsible for the graphical presentation, is not very satisfactory. In particular:

It often produces excessively involved results (as an example you can have a look at the genus_2_linked example after the CR2 move), although with the correct topological structure. This is due to the fact that it relies on a Morse description that is generated authomatically by the contour engine, which is typically not the simplest possible. The optimization and smoothing process is not capable of satisfactorily simplify the generated contour.
It sometimes produces fake crossings, i.e. two arcs that cross over each other when they shouldn't (e.g. example genus_2_linked after the sequence of moves: CR2, CR3L, CN2RB:2). Such fake crossings can be spotted because there is no corresponding marker (a small circle).
Computation time: Each picture requires approximately one second of cpu time; times will accumulate when there are many applicable rules. However this is alleviated by the fact that each computed sequence of moves is kept on the server for some time.