Please forgive me if the following forwarded message is a
duplicate ... I have attempted to create an e-mail list
of correspondents on this issue who are not already on the
IGES Project exploder.
Since most of you are unknown to me, I shall assume that I
am also unknown to you. I am a former IGES Project Manager
for the IPO, and am currently an independent IGES developer.
My product, IGESDRAW(tm) has been used since IGES Version 5.0
to create the HPGL files (and now Encapsulated PostScript
files) used to print the figures in the IGES specification.
Having established both my credentials and my business interest
in IGES viewing tools, let me say that I am opposed to the
registration of IGES as a MIME data type. My reasons are best
expressed in the following (appended) flame.
I don't know how familiar you are with the format of an IGES
file, so I would also like to add an excerpt from my reply to
one of Alan Peltzman's messages:
>My problem is the Real World utility of IGES in a view-only
>mode on the Web, and the attitude that it is just for 3D
>graphics. IGES is a *TERRIBLE* format for exchanging 3D
>data over the Internet, not the least because of the 240
>byte overhead for each entity, be it a Point, Line, or Arc,
>and the 1,440 byte minimum for dimension entities.
>
>Couple this with the plethora of vendors who put a unique
>Transformation Matrix (Type 124) on each 3D entity, and
>you have an additional 240-320 bytes of overhead on
>each curve. Note that many systems cannot avoid this
>situation because of the way their data base stores 3D
>curves - they create the matrix on the fly by using the
>cross-product of vectors, and although arcs on the same
>plane will have a common normal vector, the "x-axis"
>is *not* the same for each matrix, so they cannot be
>reused!!
I might add that this problem exists with 2D arcs as well.
In a test of one translator, a 2D IGES file with no
transformation matrices was read into the system, then
written back out as IGES. It contained an additional 500+
unique transformation matrices, making 160,000 bytes of
extra data (320 bytes for each matrix).
FYI, you can browse my Homeboy Home Pages at:
http://www.ultranet.com/~dennette/
Also, please note that my e-mail addresss on Compu$erve
will be changing in a few weeks when my domain name of
"wiz-worx.com" becomes official. In the mean time, you can
also reach me at "[email protected]".
Share & Enjoy! -=DAH=-
---------- Forwarded Message ----------
Date: 21 Mar 95 19:09:39 EST
From: "Dennette Harrod, Jr" <[email protected]>
To: "INTERNET:[email protected]" <[email protected]>
Cc: IGES Project Committee <[email protected]>
Subject: media types clarification
Message-Id: <[email protected]>
Curt ...
This discussion of IGES as a MIME type is totally bogus!!
Having been involved in the electronic transmission of IGES files
for many years now, I can assure you that *NOBODY* wants to
send a 10Mb IGES file (or a 100Kb for that matter) as a plain
ASCII file ... we compress them using PKZIP and then use
UUENCODE to make them 7-bit, and they are still one-fourth
the size of the original.
Has anyone really thought about the day-to-day mechanics of
this whole scheme? If it's "production" data we're talking about,
then compression becomes a business nessessity, otherwise the
data will be obsolete by the time the transmisson is finished. OTOH,
if we're talking about "sample" files or "debug" files, then it's
a lot of effort for very little use.
We're also talking a "get" versus "put" scenario ... someone
DOWNLOADS an IGES file with malice aforethought. Why?
Just to look at it?? What is this IGES agent really supposed
to do ... just show the graphics? Or do you expect the CAD
vendors to provide the agents so that the IGES file is converted
to Autocad or Cadkey files?
Yes, businesses exchange gigabytes of IGES files on a daily
basis, but these are mostly in SETS of a dozen files or more,
not simple illustrations like in the IGES manual, and even if
they are, they're part of a package of illustrations! So the idea
of someone requesting a *SINGLE* IGES file is *very* uncommon,
and the thought of tying up an Internet link for a couple of hours
just to get some IGES files is not very appealing.
This looks like another "If we build it, they will come" proposal
that does not have any impetus from the USER community. Does
anyone really imagine an open, unrestricted access data repository
of IGES files that people will browse like they do Web pages, and
then simply VIEW these files as view-only data??? Let's face it,
CGM makes a LOT more sense as the format for such a library.
My final argument is that viewing IGES as just another 3D vector
format is really wasting its potential. The value of IGES over
CGM or DXF lies in (a) surfaces and solids, (b) network topology,
as used in AEC and EAC, and (c) the process attributes that are
defined by the property entities. Note that neither (b) nor (c) are
going to have any useful "display" characteristics in a "viewer"
for these IGES files.
OTOH, maybe Curt's pipe-dream envisions the IGES client being
able to run a circuit analysis on the IGES data, or a collision test
on the pipes in a 3D-Piping IGES file? In that case,
"display/image/graphics" is totally inappropriate as a type for
IGES.
<Flame Off!> -=DAH=-
-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-
Dennette Harrod - WIZ WORX
[email protected]
Voice: (508)251-4640
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+
"The riskier the road,
the higher the profit."
(62nd Rule of Acquisition)
-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-