Miscellaneous other formats

'lv' is implemented in a very STEP-oriented manner. However, since the total capabilities of STEP do by far exceed those of some old-fashioned, outdated other exchange formats, it turned out to be very simple to make 'lv' also understand a selection of these, IGES and VDAFS.

'lv's support for IGES and VDAFS is limited to viewing and browsing. In other words, the repair mechanisms do not work and no output IGES or VDAFS files can be produced. There are also some limitations to the browsing capabilities if compared to STEP.

The implementation simply converts the IGES or VDAFS input data to a STEP geometrically_bounded_surface_shape_representation, which is then processed by 'lv' in the usual manner (i.e., 'lv' is mostly unaware it does not deal with STEP data). As a consequence, you will notice that the checking algorithms (i.e., -u option) will usually provide little or no interesting results (as most of the -u checks are focused on "topological" shape_representations).
One further consequence is that if you trick 'lv' into writing an output file (we won't discuss here how this can be done), you will receive a (probably unusable) STEP file.
Note: Refer to the file vdafs_iges.exp in lv's base directory for further details of the mapping.

This section provides a brief description of the scope of 'lv's IGES and VDAFS implementations.

IGES support

IGES stands for "Initial Graphics Exchange Specification". It is a commonly known data format for the exchange of CAD data which was developed since the late 1970s.

Note that in comparison to STEP, where the first parts were released after about 10 years of development, the initial version of IGES had been compiled within 3 months...

Scope of implementation

Health warning

IGES is still commonly used for the exchange of draughting data. Since this type of product data is not supported by 'lv', it is also not supported in the IGES part of 'lv'.
The consequences are that for typical usage scenarios of IGES, 'lv' is not a good choice as a viewing/browsing tool. In fact, it is most useful if the IGES input data contains only 3D geometry.

Note: For IGES there are is a large number of excellent viewing/browsing/repairing tools available, and also a large number of very cheap tools, and also some very good and very cheap tools. Therefore, if you do, for some nostalgic reasons, use IGES more often, it is strongly recommended to use some other tool that is better suited for the task and provides a more complete implementation.

Supported elements

In fact, 'lv' supports only a small subset of the IGES entity set, in particular, those elements that deal with 3D geometry (but no IGES solids). The supported IGES types and form numbers are:

100, 102, 104, 106/1, 106/2, 106/3, 106/11, 106/12, 106/13, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 130, 140, 142, 144, and 314.

There is a chance that the types 141 and 143 will be supported in the future, but all remaining IGES types are out of scope.

IGES scanner

During file read, the IGES scanner will indicate the section of the IGES file it is currently processing, unless the output verbosity is reduced (see -v option).

Errors in an IGES file will be printed to the command window where 'lv' was started from, and not be part of the usual logfile.
In particular, note the following error messages:

unimplemented IGES type(s) or forms(s): "list"
This is a list of all IGES types that are contained in the file, but are not implemented by 'lv'. The idea is that the user gets a hint how much elements are missing.
entity depends from unsupported or bad other entity, not converted: "list"
Elements in the IGES file that seem to be directly linked (physically dependent) from unsupported other entities will be suppressed. However, since the dependency is not always necessarily of type "physical", and even if so, as it is common practice in IGES to use dependency flags in an arbitrary fashion instead of as laid out in the IGES specification, this mechanism will not guarantee that unsupported types of data (e.g. auxiliary elements of a dimension) are completely suppressed, but it might help.
The given list is again intended to provide a feeling of how much is missing in the graphical display.

Differences in the user interface

The main differences in the user interface between STEP and IGES input data are in the text section:

The "Schema" button is not present.
The "STEPfile" button is replaced by a button named "IGESfile"
As can be seen in figure 1 below, additional elements will be displayed at the top of the text section. These elements will display the DE record entries of the currently selected IGES entity instance.
If a DE record entry contains a pointer, its value will be displayed with a preceeding "^" symbol. It is then possible to click on this record entry in order to select the IGES entity instance the entry points to.
As stated above, if an IGES entity instance gets selected, its DE record values will be displayed in the additional user interface elements.
If the "IGESfile" button was selected, the text section will perform a rather context insensitive markup of all occurrencies of the selected entity's DE number, and scroll to the beginning of the entity's PD record.

Figure 1. Upper area of the text section in case of IGES input data. Example shows the case that an IGES 128 (rational b-spline surface) entity with DE record number 1197 is selected.

As for the geometry display, there is a restriction for the parametrics mode: In this mode, face (144) boundaries are not tagged correctly, and clicking on one of them will not cause a selection in the text section.

VDAFS support

VDAFS stands for "Verband der Automobilindustrie - Flächenschnittstelle" (German car manufacturer's association - surface interface). It is a data format for the exchange of free-form (sculptured) surface data which was developed in the early 1980s. Its relevance can be described by the following formula:

Relevance of VDAFS ~ 1/((Distance from Germany+1)*Time)

Scope of implementation

The VDAFS comment element ($$) set aside, 'lv' can read and handle all VDAFS elements with the exception of the MDI (point-vector-sequence) and the TOP (set of surfaces or faces).

Errors in a VDAFS file will be printed to the command window where 'lv' was started from, and not be part of the usual logfile.

Differences in the user interface

The main differences in the user interface between STEP and VDAFS input data are again in the text section:

The "Schema" button is not present.
The "STEPfile" button is replaced by a button named "VDA file"
Browsing in the text section works significantly worse than with STEP files.

Figure 2. Upper area of the text section in case of VDAFS input data

Help Index