Graphics Reference
In-Depth Information
For more details see [ShaV91a], [ShaV91b], and [ShaV93]. [GHSV93] has a nice
overview of the generic representation conversion process and the general principles
that are involved. Step 4 above points to one of the stumbling blocks to having a nice
theory of conversions between different representations. The answer may not be well-
defined. In the b-rep-to-CSG case, we do not have a clear idea of which of the many
possible primitives that one can use are best.
As we have seen, converting between different representations is potentially a hard
problem. There is another related problem. Two modelers may use basically the same
representation scheme but have implemented them differently. This is hardly sur-
prising since each had a different team of programmers. What we have here is an
implementation conversion problem. Because there are many commercial modeling
systems in use, this is a real problem since many businesses are not able to assume
that all needed data will be generated internally and there is a need to transfer
data from one system to another. IGES (
I
nitial
G
raphics
E
xchange
S
pecification)
was developed to solve this problem and enable different systems to exchange data
between themselves. To use IGES, a modeling system must have translators that
convert from their representations to those of IGES and vice versa. A person wishing
to transfer data from system A to system B would then first use system A's IGES trans-
lator to translate the system A data into the IGES format and write this to a file. That
file would then be read by system B's IGES translator that would convert the IGES
data into system B's own internal format.
IGES is not perfect and it is easy to complain about its constraints. There is
another more advanced data exchange format STEP that allows for much more
high-level descriptions than the relatively simple annotated geometry formats of
IGES, but we refer the reader to [ShaM95] for that. Nice features of a modeling system
can get lost in the translation to and from IGES. A direct translation from one system's
data structure into the other's would usually be more efficient. The latter approach
would therefore be the way to go in certain dedicated situations. However, it is
certainly much simpler to write one translator (for IGES) than writing many (one
for each external modeling system). Writing translators is a nontrivial task. Further-
more, modeling systems continue to evolve and one would have to keep updating
any direct translators. IGES also continues to change with the times, but at least only
one update has to be written if one uses it. The bottom line is that IGES is a cost-
effective solution to the geometric data transfer problem that works. See Appendix C
for a summary of how various object types are represented by IGES and the format
of an IGES file.
5.10
Round-off Error and Robustness Issues
Accuracy and robustness are important issues in numerical computations. For an
overview of some common pitfalls see [McCa98]. Because geometric modeling
involves a great many numerical algorithms, one wants to minimize the potential of
round-off errors and avoid situations where small changes can lead to radically dif-
ferent results. To accomplish this one must choose carefully between different algo-
rithms and representations for objects. In this section we only scratch the surface of
