On Fri, 2013-02-15 at 18:55 -0500, Barkmeyer, Edward J wrote:
> Paul Tyson wrote:
>
> > I don't know the history of computer graphics
> > applications, but something similar must have happened--the early
> > developers looked at draftsmen putting lines and curves on mylar and
> > decided to write a program to put lines and curves on a CRT. It's taken
>several
> > generations of graphics software (each having to "interoperate" with the
> > previous generation) to really begin to augment the engineer's primary goal
> > of communicating design intent--and some people still don't believe that's
> > possible without honoring the conventions of antique draftsmanship.
>
> Well, part of the problem was to get an effective computational
> representation of solid geometry, and the tools that did that began to
> emerge after academic feasibility demonstrations in the mid 1980s.
> And part of that feasibility was having fast enough processors,
> accurate arithmetic, and fine enough graphical resolution and fast
> enough graphics refresh. That is, a mere 4 or 5 technologies were
> needed to enable that. (01)
I'm not sure I buy all of that, since there are examples of system
designs that outstrip available technology or outpace current
requirements in passionate pursuit of a goal: some of da Vinci's
machines, Knuth's TeX typesetting system, and sendmail come to mind. (02)
More to the point of this forum and thread: when (if ever) is it OK to
merely "pave over the cow path" by reimplementing concepts, conventions,
and methods, largely unchanged, from pre-computer processes into
computer systems? Did the early graphics application developers really
say to themselves: "Look, we know that these engineers actually need to
communicate all the essential physical, functional, and process
characteristics of their designs, but that's way more than we know how
to do at this time. Currently they get by with inked lines on mylar,
notes and callouts, and parts lists. We can do that much electronically,
so let's go for it!" (03)
And then the designers of the Nth generation of the software have to
decide (assuming they even have some awareness of the problem) whether
or not to put yet another layer of asphalt on the cow path to preserve
vestigial features from an initial choice to render into software what
should never have been there in the first place. (04)
>
> BTW, putting accurate lines and curves on a CRT from a digital source,
> rather than an analog recording, was no small feat in 1970, when the
> early graphical CRTs first appeared (at significant cost). As late as
> 1990 the cost of top of the line graphics terminals was in the 30K$
> range, and had been since the first ones 20 years earlier, which is a
> big difference in constant dollars, and had a big impact on the size
> of the potential market. The Tektronix folk made the
> price/performance breakthrough about 1974, and dominated the market
> for 10 years until cheap raster technology emerged that could
> approximate the accuracy of their technology.
>
> And for the record, the antique draftsmanship conventions have a
> different motivation -- long-term archival of the engineering models.
> What CAD form from 1985 can still be processed? Do you think all
> those 1985 aircraft have been junked? Do refineries built in the
> 1980s still function? If we now commit to saving the latest and
> greatest Pro-Engineer solid models in native form, what tools will be
> able to read the recording media and decode the model and display the
> holographic images in 2025, let alone 2050? If you are authorizing
> the construction of a nuclear plant, what archival form of the
> engineering models are you going to require? Maybe those antique
> draftsmen still have a value. (05)
There's probably no bigger fan (except you, perhaps) of fine engineering
draftsmanship in this forum than me. I'm intrigued by the processes of
recording and communicating the design of complex products, and I think
the engineering and architectural drafting practices of the 20th century
brought this to a high art. I also think those practices were translated
into suboptimal computer systems for achieving the same goals,
notwithstanding some obvious local gains in productivity and precision.
One troublesome symptom of the suboptimization is the archiving problem,
so that 40+ years into the era we still fall back to 2d drafting
representations for long-term storage. (Of course, the reluctance of CAD
vendors to fully support common standards for product model
representation is much to blame for this also. See my point 6 in
previous post.) (06)
Regards,
--Paul (07)
>
> I agree with Paul's sentiment, but the business of engineering models
> is important, it is very high tech, and it is fraught with all kinds
> of very real business constraints.
>
> -Ed
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology
> Systems Integration Division
> 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> (08)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (09)
|