edds@unc.UUCP (Tom Edds) (05/15/84)
Several months ago I sent out a request for information on implementations
of CORE. This being my first inquiry to the net, I was amazed at all
the helpful responses I got, including information not only on CORE, but
also on systems based on the GKS standard, and some other tidbits.
Last week I sent out an inquiry to see who was interested in what I'd
found; again, I was surprised by the number of responses.
Following a suggestion made by several people, I am posting this
rather than mailing it.
Here is the summary:
--------------------------------------------------------------
One well-known implementation of the the Core standard is GWCORE,
done at George Washington University. It is written in FORTRAN, and
includes a FORTRAN driver for TEK 401x devices, and a C Driver for a
RAMTEK 9400.
A detailed description of the Core System was given in an article by
Jim Foley, (who is at GWU) in the Aug. 82 issue of Computer Graphics World.
More current information comes from the February issue of the Klein
Newsletter on Computer Graphics:
....
GWU Offers Enhanced Version of Its CORE Subroutine Package
Claiming distribution at 100 locations, The George Washington University,
unveils an enhanced version of its device-independent, 3-D SIGGRAPH-CORE
graphics subroutine package, called GW Core. The package incorporates
that standard's output Level 3C, having 3-D output primitives; image,
modeling, and viewing transformations; segments; and raster extensions.
It also incorporates Level 3 synchronous and asynchronous input functions.
GW Core runs under VMS on VAX computers, UNIX, and other operating systems.
Fee for single CPU use: $1,000 US (for colleges $500 US).
Contact Chuck McMath, Research Associate, Department
of Electrical Engineering and Computer Science,
The George Washington University, Washington, D.C 20052 (202/676-5923).
--------------------------------------------------------------
Here is another:
I have a C-language version of the SIGGRAPH Core at a basic level (2-D only,
no segmentation, some input primitives). The program runs under 4.1bsd UNIX
and supports about nine different devices with more to come: AED-512 frame
buffer, Ikonas frame buffer, Raster Technologies model one frame buffer,
ID100-V graphics terminal, Versatec V-80 plotter, Ramtek color printer,
Symbolics laser printer, CIF (for putting graphics on your VLSI chips), and
normal video terminals with TERMCAP cursor control. Release status is not
known yet, but further information will be available soon. Documentation is
available now.
Steve Rubin <Strubin at SRI-KL>
However, note this comment:
There is one in existance, developed (I believe) by steve rubin at fairchild
("flairvax" on usenet). Having used both that package, and the original
core graphics package done by G. Washington U., I would question if you
really want to use CORE. CORE is -increadably- clumsy with raster and
bitmapped graphics; and is already becoming archaic. It usually isn't that
hard to design your own portable graphics package, and it's usually less of a
headache than dealing with all the oddities of individual CORE implementations.
ps- the flair CORE implentation was oriented towards doing graphics for VLSI
design, and was missing some of the CORE features not relating to those applications.
--------------------------------------------------------------
Another one came from Michael Wayne Young <Michael.Young at CMU-CS-A>:
I have such a package in the works for 4.1BSD; it's a SIGGRAPH "Core" system
written for any version 7 or better system (which of course includes System
IIII or 4.1BSD running on Vaxen). It currently supports level 1 input and
level 1 output; that is, full 3D viewing, no segmentation, no input. It
supports the definition of various attributes (such as color, which is what
you're interested in); it's up to the device driver to decide how much to
actually implement though, and the devices I've had are primarily monochrome
(4010 series, hp2648, Tek 4025), but some support color (an AED 512, a Dec
Gigi terminal, and an hp7221 plotter [4 pens]).
Currently, all of level 1 i/o is complete; it is currently in use in part
of a larger graphics system (only in size, not complexity...) at the
University of Delaware.
A fairly sophisticated device assignment feature is provided (but not
mandated); it allows various device types to be handled on any output file
(discriminated at runtime), with various device options (like screen window,
startup color, device defaults). It also allows output to be piped to a
command, if that's your interest. [I've used that a lot to build device
drivers without having a device available.]
It's fully device-independent; the effort involved in building an additional
device driver is minimal (for me, at least, as nobody else has had to try yet).
It relies heavily on standard device driver parts, to maintain continuity among drivers.
It's all C code, but is barely accessible from Pascal. [I have an include file
for Pascal use, but it's been minimally tested.] Fortran (IV or -77) support
is not even conjectured yet, as most parameters are passed by value now, and
I see no need to change that either. [It'd be a matter of writing a F77-C
interface.]
What I plan to be doing in the next 1-2 months is finishing up level 2
(and maybe 3) output; this would add segmentation and the associated visibility
handling. Batching of updates would become more important. I am currently
part-way through this section, but it's not available yet.
I have no current timetable for the inclusion of graphical input; aside from
simple "locator" input (joystick or cross-hair cursor), none of my devices
could do anything anyway, so it's not that important. A possible intermediate
stage is an "escape" function to read this joystick position.
I think what I have is probably sufficient for what you want to do...
moderately tough vector graphics, primarily for plots, in a device-independent
way. If you have any questions/doubts/whatever, don't hesitate to let me know.
Now, as for the "distribution" of the package: I'll give it out for free, but
I want to retain copyrights on it. [I.e. not public domain, but free to use.]
What I'd need is a statement from you saying that you were to use the package
for yourselves only, and not to distribute it, plus I guess to pass back
changes to me (although I'm not sticky on that point). Let me know if this is
the only problem; I'm sure we can arrange something if you're still interested.
Michael
(This seemed like an old note; he's probably already done a lot
of the planned changes.)
--------------------------------------------------------------
And yet another:
You we asking about implementations of the SIGGRAPH CORE system written in C.
I have an implemention of CORE. It is level ("basic","no-input","3D").
I am currently adding the raster extensions to bring it to level ("basic",
"no-input","3D","none"). The implementation is not complete, it lacks the
following CORE functions:
map_world_to_ndc_2 map_world_to_ndc_3
map_ndc_to_world_2 map_ndc_to_world_3
set_primitive_attributes_2 set_primitive_attributes_3
inquire_primitive_attributes_2 inquire_primitive_attributes_3
set_viewing_parameters inquire_viewing_parameters
inquire_output_capabilities
Most of these could be easily implemented, I just haven't had the time or
need for them yet.
The system is all written in C and conforms to the '79 proposed standard as
close as possible. It currently requires long variable names (the full CORE
function names are used) and may have 4BSD/VAX dependancies. I have a short
naming convention defined (6 letters for FORTRAN) but haven't implemented
it yet. (The functions names are really bizarre!)
It supports the following devices:
Tek401x, DEC GIGI (vk100), BBN Bitgraph, SELANAR vt100 graphics (in tek mode),
Tek4662 plotter (with 8 pen option), DEC LXY11 printer/plotter, Houston
Instruments DMP-29 plotter, Vextrix Corp. Vectrix (raster device). New device
drivers are easy to add, initially most of the work can be deligated to the
centralized device dispatcher (which can perform some simulations).
There is currently very little documentation with the system (almost none),
but some prodding could get me to sit down and do the work necessary.
I wrote this package as part of my requirements for an honours degree in CS
and would be glad to distribute it. I feel however that I should do some
further work making a cleaner distribution. If there is enough interest in
getting this package I would be glad to do it.
Hope this helps,
John McCarthy.
UUCP.us: ucbvax!allegra!garfield!john
ihnp4!garfield!john
MA BELL: (709) 737-8330
SNAIL: Computing Services;Memorial University;St. John's, NFLD.;A1C 5S7
------------------------------------------------------
Other information about CORE:
There is a survey of graphics software in Computer Graphics World,
Vol 5 no 8, August 1982. The CLICS package was available to the public
on USENIX a few years ago. It was written in C but was 2-D with no input
routines. It has now been extended and is sold by Garrett Information Systems, Crofton, MD.
* * * * * *
One [CORE implementation] of these was written by DOD in C. It is not very
well written as it was the author's first C project. It is 2D only, but
has a reasonable device dependent - device independent interface.
Another is available commercially from Precision Visuals, it is called DI-3000.
It is a 3D implementation of CORE that includes many tools for editting/viewing
metafiles. They do have versions for UNIX CPU's but you will have to pay
much $$$ for it as it is a commercial product.
The dodcore I have was in a Usenix distribution, I don't remember which one.
* * * * * *
Contact Joe Pato at Brown University -- they distribute (or did, anyway) a 2D
subset of the CORE standard, I believe available in both C and Pascal.
* * * * * *
Apollo has this implemented. I have not personally examined it, but there
are a large number of nice graphics programs and games running on Apollos.
In case you are unfamiliar with Apollo, they have a number of very nice
workstations with bit-mapped high res screen, windowing, multi-processing
and session management, built-in networking and distributed file system
etc. available for $12K (diskless) - $60K (in color) [before discount].
They run a unix-like op sys designed for windowing and networking; their C
compiler runs unix code, you can run unix (and unix programs) in any
window. They make any pure unix machine look real shabby.
I doubt you could buy the code from them without a machine to go with it.
* * * * * *
Sun Microsystems machines implement the SIGGRAPH CORE system in C.
I am currently trying to write some image processing and display routines
in it with partial success.
-------------------------------------------------------------
I also got some good information about GKS systems:
David Rosenthal has written an implementation of GKS (one of the proposed ISO
and US graphics standards) for UNIX. GKS is functionally similar to a 2-D
SIGGRAPH core system, with several groups working on the 3-D version. It is
also the case that SUN Microsystems (Jerry Evans, if my memory serves me,
though Bill Joy would know also) is writing a UNIX version of GKS. You should
also contact Precision Visuals (if you are interested in commercial software),
as I believe they have DI-3000 (SIGGRAPH CORE system) running under UNIX.
David Rosenthal
Strichting Mathematicsh Centrum
Kruislaan 413 1098 SJ Amsterdam
Postbus 4079 1009 AB Amsterdam
THE NETHERLANDS
Phone: (020) 592-9333 (Don't try this unless you speak Dutch.)
Telex: NETHERLANDS 12571 (this should be checked)
Uucp: ucbvax!decvax!mcvax!david (sometimes this works)
Bill Joy
SUN Microsystems Inc
2310 Walsh Ave
Santa Clara, CA 95051
------------------------------------------------------------------------------
Here at The Mathematical Centre, Amsterdam, an implementation of GKS, the
draft International (and ANSI) standard for 2D graphics software, is underway.
It is being made available, but to find out the terms you will have to mail
..decvax!mcvax!paulh (Paul ten Hagen).
I did some of the design, but am not involved in the implementation. GKS
defines a 3*3 matrix of capabilities, viz:
Output Input
None Synch Asynch
Basic Works Works Wait 4.2BSD
Segment Works Works Wait 4.2BSD
Full Untest Untest Wait 4.2BSD
Some work is still needed even on the bits that work to make them
fully distributable (e.g. clean up makefiles, translate comments
from Dutch). At present the interface between the Device Independent
parts and the Device Dependent bits (drivers) is very low-level and
does not exploit the capabilities of advanced devices. Most testing
uses an AED512.
For information on GKS, contact the ANSI committee:
ANSI X3H3
c/o Dr. Peter R. Bono
Athena Systems Inc.
206 South Broad St.
Pawcatuck, CT 06379
203-599-3061
David Rosenthal
* * * *
There is also an up to date report on graphics standards in the
February 1984 issue of Computer Graphics World.
Thanks once again for your input;
Happy plotting to you.
Tom Edds
edds@unc