SG User's Guide
0.1
Table of Contents
- Overview
- Information and Resources
- Obtaining SG
- Frequently Asked Questions
- Installation Instructions
- Author Information
- Copyright and Terms of Use
- GNU LGPL
Overview
SG is an unstructured simplex mesh OpenGL display and manipulation tool for use with the finite element research codes MC and PLTMG. SG provides OpenGL-based graphics over UNIX and INET sockets on UNIX/X-based systems, Win32-based systems, and other systems. It can also be used with MCLite as a replacement for MATLAB's builtin graphics for polygons. SG can read Geomview OFF files and OpenInventor files for polygonal surface descriptions, and it can also read PDB files for molecule descriptions. SG looks and acts somewhat like Geomview, and it mimics most of the basic features and controls of Geomview for displaying polygonal 2-manifolds.
SG is designed to mimic the well-known Geomview program from the University
of Minnesota's geometry center, and it uses one of Geomview's input file
formats (the "OFF" format). However, SG it is quite a bit simpler than
Geomview, it has three advantages when compared to Geomview. First, it can
take input directly from files, UNIX pipes, UNIX domain sockets, and
INET sockets (Geomview cannot take input from INET sockets).
Second, it can produce provably
correct PostScript renderings of meshes (Geomview uses a baricenter-based
front-to-back ordering for the Painter's algorithm, which often fails for
complex meshes; SG uses a linear programming approach which is
mathematically guaranteed to work if the picture is paintable with the
Painter's algorithm). Third, it will build and run on Win32 platforms
such as Windows 2000, Windows NT, and Windows 98.
(Some may actually view this as a disadvantage.)
In the case of Win32, SG uses the WINSOCK API for INET socket access.
The window-system specific connection to X11 or Win32 is made through
"WGL" extensions to Win32 under NT, or using the SGI "GLw" widget set
on X11 platforms.
The graphics in SG is done in an entirely platform-independent manner
using OpenGL.
This portability is due to SG having been built on top of
a portable low-level abstraction library called MALOC (Minimal Abstraction
Layer for Object-oriented C). MALOC was written primarily to support the
development of MC, but is now also used for SG. Both MALOC and SG are now
both used by Randy Bank in the development of his software package PLTMG.
Quaternion-based Trackball Rotator
SG is a polygonal manifold display and manipulation tool.
It can also display PDB (Protein DataBase) data as a collection of
intersecting triangulated spheres of appropriate color and radii.
It is basically a trackball rotator, although one can also scale and
translate the object being displayed.
The manipulation is done with a combination of the mouse and the keyboard.
The rotator is quaternion-based, following the trackball example in Mark
Kilgard's OpenGL programming book.
The rotator avoids gimbal lock, rotation instability, and other degeneracies
through the use of a projection ball and quaternions.
The hysteresis problem usually present in rotators is removed by employing
Ken Shoemake's non-accumulation trick from his famous Arcball example in
one of the Graphics Gems.
(I.e., when you move the mouse back to the starting point in a rotation,
the object resumes its original position.)
OpenGL-to-Postscript Generation
SG can generate a very high-quality Postscript rendering of any displayed
scene, with (provably) correct logical rendering order of the polygon
primitives, through the use of builtin routine called SGps.
SGps generates Postscript output from an arbitrary
OpenGL scene, by using the feedback buffer mechanism in OpenGL.
SGps is similar to Seth Teller's PSGL, and to Gary Wu's PSOGL,
but it does not use the same baricentric depth quicksorting of the polygons,
which is prone to incorrect rendering orders for complex scenes.
Instead, SGps is based on a linear programming approach
developed jointly with R. Bank.
If a scene can be rendered by the Painter's Algorithm, then SGps is
guaranteed to find a logically correct painting order, and it will then use
the Painter's Algorithm to render the scene correctly in Postscript.
Input Format
Here are some examples illustrating the Geomview-compatible OFF input format tha t SG employs: tri, tet. The portability of SG is attained by the use of a low-level abstraction library called MALOC. The MALOC library must be installed before installing SG. Similar to MALOC, SG is easily buildable from source on any UNIX-like system, and uses a GNU autoconf build environment.
Information and Resources
Detailed information about SG can be found in the User's Guide and Programmers's Guide.
While SG is itself a self-contained software package, it is one of several components of FETK (the Finite Element ToolKit). FETK consists of the following components written in Clean OO C:
- MALOC - Minimal Abstraction Layer for Object-oriented C programs.
- PUNC - Portable Understructure for Numerical Computing.
- SG - Socket Graphics mesh display tool (uses MALOC).
- MC - Manifold Code finite element package (uses MALOC and PUNC).
- MCX - MC eXtension libraries (uses MALOC, PUNC, and MC).
MALOC is self-contained, and requires only an ANSI-C compiler on a UNIX or Win32 platform. PUNC, SG, and MC are also self-contained, but rely on MALOC having been previously installed on the platform. Additional features of MC are enabled if PUNC is available, but PUNC is not required to build MC. The MC eXtension libraries MCX are constructed on top of MALOC and MC, and in order install and use MCX one must first correctly configure and install both MALOC and MC. MCX is made up of a number of individual libraries developed by members of our group, or contributed by one of a number of colleagues. More information about FETK can be found on the FETK website:
Obtaining SG
SG is copyrighted, but is redistributable in source and binary form under the following license. The SG source and binary code can be downloaded from the following locations:
Some older pre-compiled SG and related binaries for Win32 platforms can be found below:
SG uses the low-level abstraction library MALOC, which must be installed before installing SG.Frequently Asked Questions
What is SG and what does SG stand for?
See the Overview.
How to I obtain a copy of the SG source code?
See the Obtaining SG section.
I managed to get a copy of "sg-VERSION.[i386|src|tar].[rpm|gz]"; how do I now install SG?
See the Installation Instructions.
You gave me a "patch.gz" file to fix a bug in SG; how do I apply the patch?
To apply patches to upgrade SG to a new version, you first obtain the patch from me or my webpage as a single file with a name like "patch.gz". You apply the patch after you have unpacked the sg.tgz file as described above. To apply the patch, cd into the directory containing the root SG directory (called "sg" after unpacking sg.tgz) and execute the "patch" program as follows (the patch program exists on most UNIX machines):
- gzip -cd patch.gz | patch -p0
Patch files are simply the output from a recursive "diff" that are used to represent all differences between two directory trees. For example, to create a patch representing the changes from version 1.0 of SG (in directory sg_1.0 for example) to version 1.1 of SG (e.g. in directory sg_1.1), I would normally type the following:
- diff -r -u -N sg_1.0 sg_1.1 > patch1
- gzip -v patch1
I really don't know what I'm doing; how to I get more documentation for SG?
The User's Guide and the Programmers's Guide contain all of the SG documentation.
Why did you develop SG? There are many other mesh viewer packages, right?
Yes, there are. Geomview is awesome. However, we often want to display the mesh in a calculation on a local workstation, while running the calculation on a larger remote (possibly parallel) machine. For large complex meshes, opening up a remote X display is extremely slow (the X libraries may not even exist on the large number crucher). By running SG on the local machine, our numerical codes on the remote machine can send polygons in binary XDR format directly to an INET socket on the local machine. This is extremely fast, even for very large datasets. Finally, we often need to run visualization tools natively on Win32 platforms.
There are a couple of things we didn't like about Geomview, which we made different in SG. For example, the rotator in Geomview exhibits hysteresis in the sense that if you return the mouse to its original location when rotating, the object doesn't actually return to its original position. SG on the other hand uses a quaternion-based trackball rotator, and uses a rotation non-accumulation trick due to Ken Shoemake to avoid this type of hysteresis (the particular trick can be found in one of the Graphics Gems volumes). The PostScript generation mentioned above was another reason for writing SG.
What is in all of these subdirectories? Where exactly is "SG"?
SG consists of several (class) libraries from which you will call routines to handle your application. You will need to write a main driver program (and any supporting routines you need) and then link to the libraries. Alternatively, you can build the SG tools "sg" and "mcsg" by doing a "./configure ; make ; make install" in the tools subdirectory. These two tools process and display polygon data, and have functionality and behavior similar to Geomview. If you are simply after these two tools, then you don't need to actually use the libraries and headers that get installed when you configure/make/make install the SG libraries. However, the in order to successfully configure/make/make install the tools sg and mcsg, you must first succesfully configure/make/make install the SG libraries.
As described in the file "INSTALL", you will build all of the libraries in one
shot for your particular architecture, along with various test programs to
verify that the various pieces are functioning correctly. The libraries end
up in
The following directory tree is created when you unpack the SG "sg.tgz"
distribution file by following the instructions in the INSTALL document:
The following is a brief description of each subdirectory of the package.
Okay, I seem to have installed SG correctly; how do I actually use it now?
Using the SG code is very simple; just type "./mcsg" without arguments and
you get a list of all of the options. The socket bridging tool functions
similarly; typing "./mcbridge" without arguments gives you a list of all
of the possible options. The remaining tool "sg" is a motif version of
"mcsg" with similar functionality, but with a more sophisticated button
layout.
What is the class hierarchy? How are the various libraries related?
Detailed information on the class relationships can be found
in the
Programmers's Guide.
The following directed graph shows the class library dependencies.
(This tends to evolve as MC is developed.)
Wait! I have a bunch of other questions, such as:
Available distribution formats
SG is distributed in both binary format (as a binary RPM file
sg-VERSION.i386.rpm for i386-based versions of Linux) and in source
format (as a source RPM file sg-VERSION.src.rpm and as a gzipped tar
file "sg-VERSION.tar.gz").
Installation using the binary RPM file
The following rpm command will install all of the SG headers and libraries
into /usr/local/include and /usr/local/lib, and will install the SG
documentation into /usr/share/doc/packages/sg:
Installation and rebuilding from sources using the source RPM file
The following rpm command will unpack the source rpm file
"sg-VERSON.src.rpm" into the SG gzipped tar file containing
the sources called "sg-VERSION.tar.tar.gz" and into a small RPM
spec file called "sg-VERSON.spec":
Rebuilding binary and source RPM files from the gzipped tar file
The SG sources contain the RPM spec file "sg-VERSON.spec" in the
root source directory; as a result, rebuilding the RPM files from sources
can be done using the rpm command:
Installation and building from sources using the gzipped tar file
The following command will unpack
SG into a number of subdirectories and files on any UNIX machine
(and on any WinNT machine with the GNU-Win32 tools gzip and tar).
Building the package using the GNU "configure" shell script and "make"
The "configure" shell script in the "sg" directory (the toplevel
directory created when you unpacked the SG tgz file) will build the entire
package. This is a standard GNU autoconf-generated configuration script.
For a list of the possible configuration options, type:
Building binaries for multiple architectures in the same source directory
If you have a version of "make" that supports the VPATH facility (such as
any recent version of GNU make), then you can build the package for multiple
architectures in the same source directory (in fact, you can do the compiles
at the same time without collisions). This is very useful if you have your
home directory on an NFS volume that you share among multiple architectures,
such as SGI, Linux, etc. To build SG for all the systems at the same time,
you simply make an additional subdirectory in the main SG directory for
each architecture, copy "configure" into it, "cd" into the subdirectory, and
then install as above. For example, on a linux machine you would do the
following:
Building shared libraries rather than static libraries
(MIKE: give an overview of libtool.)
Rebuilding the configure script and the Makefile.in files
If for some reason you actually need to rebuild the configure script or the
Makefile.in files using the GNU autoconf suite, you should read the block of
documentation at the top of the configure.in file. The commentary I put there
explains exactly how the GNU autoconf suite must be used and in what order,
and exactly what files are produced at each step of the process. A script
called "bootstrap" which automates this process is located in the config
subdirectory of the SG source tree.
Platform-specific information
Below is some platform-specific build/usage information for SG.
Things should work as described above.
Things should work as described above.
Things should just work, but you may have to set the CC environment
variable as follows before typing ./configure:
If you are on a 64-bit IRIX box such as an Onyx, Octane, or Origin,
set the CC environment variable as follows before typing ./configure:
Unless you have the Cygwin environment, you need to use one of the
included project file collections for one of the commercially
available ANSI C or C++ compilers for the Win32 environment.
What you end up with
Once the build completes via the "configure;make;make install" procedure above
with no errors, the SG library (libsg.a and/or libsg.so) is installed
into the specified installation directory. You can also build some useful
tools that employ the SG library by cd-ing into the "tools" subdirectory and
repeating the "configure;make;make install" procedure.
Once the tools build completes, you will end up with:
Getting SG to find your installation of GL/GLU/GLw/Motif/Etc
If your installation of OpenGL (libGL, libGLU, libGLw and headers) and/or
Motif is located in an unusual directory, then the configuration script may
have trouble finding the libraries or the headers. The configure script
prints out the state of affairs quite clearly as to whether it found the
libraries and the headers. If you have the libraries and configure is not
finding them, then here are several possible solutions, each of which usually
works. They are listed in preferred order (i.e. you should try Solution 1
first, and if that doesn't work try Solution 2, and so on).
Note that you DO NOT need Motif in order to build SG; if you DO have Motif,
then the additional Motif-based tool "sg" is built. Without
Motif libraries on your system, you still get the base socket graphics tool
"mcsg" and the socket bridging tool "mcbridge". ("sg" is
somewhat fancier than "mcsg", but "mcsg" has all of the core functionality
of the Motif tool.) On a Win32 machine such as Windows NT, you will also
end up with both "mcsg" and "mcbridge".
Have your system administrator install MPI in a proper system
directory so that MALOC (and other AUTOCONF-based codes) can find it!
SG (Socket Graphics) was conceived,
designed, and implemented over several years by
Michael Holst,
beginning with an initial implementation in 1994.
Various colleagues have contributed ideas and/or code to SG
(see the credits list below).
SG is currently released under the GNU LGPL (GNU Lesser General Public
License). What this means is that you may redistribute it and/or modify
it under the terms of the GNU LGPL as published by the Free Software
Foundation; either version 2.1 of the license, or (at your option) any
later verison. You should have received a
copy of the GNU LGPL with this distribution of SG; a copy can be found
here.
If you did not receive a copy of the GNU LGPL, please write to me and also
write to:
The Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA\
\
02111-1307 USA.
SG was initially released under the GNU GPL (GNU General Public License.\
What this means is that like all
GNU softare, SG is freely redistributable in source code form following
the rules outlined in the text of the GNU GPL.
Software included in the SG source code package
A complete roadmap to the source code forming the SG package can be
found above.
While the core SG classes were developed primarily by
Michael Holst,
some additional software is currently included with SG:
Credits
Below is a credits list for the people that have
contributed to SG in one way or another.
The fields below follow the credits file format used in the
Linux kernel CREDITS file to allow for easy manipulation via shell scripts.
The fields are as follows:
Contacting the Author
If you have questions or comments about SG, please feel free to contact
me at mholst@cam.ucsd.edu.
This version of SG is distributed under the following guidelines:
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
The LGPL (GNU Lesser General Public License) below is copyrighted by the
Free Software Foundation. However, the instance of software that
it refers to, my package in this case, is copyrighted by myself as
the author of the package. Any additional software that I distribute
with my software is copyrighted by the authors of those pieces of
software (see the individual source files for author information).
---Michael Holst
sg
|
------------------------
/ | | | \
config doc examples src tools
The src directory has the additional subdirectory structure:
src
|
------------------------------
/ | | | | | | \
aaa_inc aaa_lib base gl glu glw ogl vgl
Within each library source directory is an additional subdirectory,
"sg". The "sg" subdirectory contains public headers for the library,
representing the library API; these headers will be installed in the
specified header install directory during the install procedure after
building SG. (The OpenGL library subdirectories gl, glu, and glw contain
additional OpenGL-specific API files in additional subdirectories.)
sg - The entire SG package
sg/config - GNU Autoconf scripts and non-unix config files
sg/doc - SG documentation
sg/examples - Complex examples and data files for using SG
sg/src - SG source code (all source and headers)
sg/src/aaa_inc - Header installation tools
sg/src/aaa_lib - Library installation tools
sg/src/*/sg - The SG headers (API)
sg/src/base - Source for M. Holst's BASE (SG foundation headers)
sg/src/ogl - Source for M. Holst's OGL (OpenGL rotator kernel)
sg/src/vgl - Source for M. Holst's VGL (Virtual openGL)
sg/src/gl - Source files for dubset of B. Paul's MesaGL
sg/src/glu - Source files for dubset of B. Paul's MesaGLU
sg/src/glw - Source files for dubset of B. Paul's MesaGLw
sg/tools - Some binary tools for use with SG
MALOC ==> base ==> ogl ==> vgl ==> sg
/\ /\
|| ||
OpenGL ===> gl => glu ||
||
Window System =========> wgl/glw
These and other related questions are addressed in the MALOC FAQ, which is
distributed as the README file in the MALOC source distribution.
Installation Instructions
rpm -Uvh sg-VERSION.i386.rpm
rpm -Uvh sg-VERSION.src.rpm
The sources can then be unpacked and built using the directions for
the gzipped tar file below.
Alternatively, the following rpm command will do these steps for you:
rpm -bp sg-VERSION.spec
rpm -ta sg-VERSION.tar.gz
The result will be the corresponding source and binary rpm files,
named "sg-VERSON.src.rpm" and "sg-VERSION.i386.rpm".
Normally, these files are written to /usr/src/redhat/SRPMS
and /usr/src/redhat/RPMS respectively, but you must be logged in
as root for these to work.
The destination directories can be overriden using arguments to the
rpm program (see the rpm manpage).
gzip -dc sg.tgz | tar xvf -
./configure --help
You should be able to build SG by simply typing:
./configure
make
make install
However, it is often advantageous to keep the original source directory
pristine; the configure script can actually be run outside the source
tree, which will keep all files created by the build outside the source
tree. (This idea is related to the section below describing how to build
binaries for multiple architectures at the same time using the same source
tree, and requires that your version of make has the VPATH facility, such
as GNU make.) For example, I build SG in a separate directory from the
source tree as follows:
gzip -dc sg.tgz | tar xvf -
mkdir sg_build
cd sg_build
../sg/configure
make
make install
mkdir linux
cp configure linux/.
cd linux
./configure
make
make install
If you mount the same NFS home directory on for example an OpenStep box,
you could at the same time do the following:
mkdir next
cp configure next/.
cd next
./configure
make
make install
Again, both builds can actually be done outside the source tree rather
than in a subdirectory of the source tree, as described in the previous
section.
export CC="/bin/cc"
or you might need to use:
export CC="/bin/cc -ObjC"
export CC="/bin/cc -64"
If you are on a 32-bit IRIX box such as an O2 or Indy,
set the CC environment variable as follows before typing ./configure:
export CC="/bin/cc -32"
mcsg - Core socket OpenGL tool ([GLw | WGL] + [X | Win32] + OpenGL)
mcbridge - A socket bridging tool (FILE/PIPE/UNIX/INET)
sg - A Motif version of mcsg (Motif + X + OpenGL)
If the SG tools work like they were designed, you won't need any more
information to use the tools. If you want to know more about the details
of the algorithms in SG, or about the implementation details such as the
socket graphics, have a look at the
Programmer's Guide.
locate libGL.a
locate libGLU.a
locate libGLw.a
locate gl.h
locate glu.h
locate GLwDrawA.h
locate libXm.a
locate Xm.h
On my Redhat6.2 Linux box with LessTif supplying Motif, XiGraphics'
supplying two of the OpenGL libraries (libGL and libGLU), and Mesa
supplying the third (libGLw), the following output is produced:
mc:~% locate libGL.a
/usr/lib/libGL.a
mc:~% locate libGLU.a
/usr/lib/libGLU.a
mc:~% locate libGLw.a
/usr/local/lib/libGLw.a
mc:~% locate gl.h
/usr/include/GL/gl.h
mc:~% locate glu.h
/usr/include/GL/glu.h
mc:~% locate GLwDrawA.h
/usr/local/include/GL/GLwDrawA.h
mc:~% locate libXm.a
/usr/X11R6/lib/libXm.a
mc:~% locate Xm.h
/usr/X11R6/include/Xm/Xm.h
Therefore, my OpenGL libraries are installed as:
/usr/lib/libGL.a
/usr/lib/libGLU.a
/usr/X11R6/lib/libGLw.a
and the associated OpenGL headers are installed as:
/usr/include/GL/gl.h
/usr/include/GL/glu.h
/usr/local/include/GL/GLwDrawA.h
My Motif library is installed as:
/usr/X11R6/lib/libXm.a
and the associated Motif headers are installed as:
/usr/X11R6/include/Xm/Xm.h
FETK_GL_LIBRARY, FETK_GL_INCLUDE,
FETK_GLU_LIBRARY, FETK_GLU_INCLUDE,
FETK_GLW_LIBRARY, FETK_GLW_INCLUDE,
FETK_MOTIF_LIBRARY, FETK_MOTIF_INCLUDE,
to point to the directories containing:
libGL.a, gl.h,
libGLU.a, glu.h,
libGLw.a, GLwDrawA.h,
libXm.a, Xm.h,
respectively. Under bash, using the results from the example
above, I would do this as follows:
export FETK_GL_LIBRARY=/usr/lib
export FETK_GL_INCLUDE=/usr/include
export FETK_GLU_LIBRARY=/usr/lib
export FETK_GLU_INCLUDE=/usr/include
export FETK_GLW_LIBRARY=/usr/local/lib
export FETK_GLW_INCLUDE=/usr/local/include
export FETK_MOTIF_LIBRARY=/usr/X11R6/lib
export FETK_MOTIF_INCLUDE=/usr/X11R6/include
./configure
The configure script should now report that it successfully
found the libraries and headers, and then SG should compile
without error.
Author Information
SG (Socket Graphics)
Copyright (C) 1994-2006
Michael Holst TELE: (858) 534-4899
Department of Mathematics FAX: (858) 534-5273
UC San Diego, AP&M 5739 EMAIL: mholst@cam.ucsd.edu
La Jolla, CA 92093 USA WEB: http://cam.ucsd.edu/~mholst
SG was designed to be a portable networked visualization tool for use in the
development of MC (Manifold Code), an adaptive multilevel finite element
package also developed by
Michael Holst.
It is also used by Randy Bank as
the primary visualization tool for PLTMG. Both SG and MC are written on top
of a low-level abstraction layer called MALOC (Minimal Abstraction
Layer for Object-oriented C), also developed by
Michael Holst.
SG was developed almost
entirely on a home-grown 90Mhz Pentium PC running various flavors of
Linux and [Free|Net|Open]BSD, using primarily GNU, BSD, and other free
software development tools. Most of the development occurred during the
hours of 10pm to 2am on a daily basis for several years, under heavy
influence of Starbuck's coffee, with helpful advice provided by Mac and
Mochi (two cats knowledgable in socket programming and numerical analysis).
sg/src/vgl/vglm.c - Motif Variant of vgl (joint Bank/Holst effort)
sg/src/vgl/oglps.c - Perfect PS generation (joint Bank/Holst effort)
sg/src/gl/* - B. Paul's MesaGL (the GL library)
sg/src/glu/* - B. Paul's MesaGLU (the GLU library)
sg/src/glw/* - SGI's OpenGL widgets (the GLw library)
The extra conditionally-build libraries provide the complete OpenGL
capability that SG requires in order to function, if these libraries
are not available on the particular platform. Under normal circumstances,
these three libraries will not have to be built; the OpenGL API they
provide is completely software-based, and will be slower than native
hardware-accelerated OpenGL which is normally available on modern
PCs, Macs, and SGI platforms.
N: name of contributor
E: email address
W: web address
P: PGP key ID and fingerprint
D: description of primary contributions
S: snail-mail address
N: Michael Holst
E: mholst@cam.ucsd.edu
W: http://cam.ucsd.edu/~mholst
P: 1024/0xB5212DCD
D: sg/* -- The package structure
D: sg/acconfig.h -- The platform abstraction information
D: sg/configure.in -- The GNU autoconf/automake structure
D: sg/config/* -- The GNU autoconf/automake shell scripts
D: sg/doc/* -- The package documentation
D: sg/examples/* -- The package examples
D: sg/src/aaa_inc/* -- Library header build structure
D: sg/src/aaa_lib/* -- Static and shared library build structure
D: sg/src/base/* -- M. Holst's SG Foundation headers
D: sg/src/ogl/* -- M. Holst's OpenGL-based trackball rotator
D: sg/src/vgl/* -- M. Holst's window system abstraction layer
D: sg/src/gl/* -- The libGL wrapper
D: sg/src/glu/* -- The libGLU wrapper
D: sg/src/glw/* -- The libGLw wrapper
D: sg/tools/* -- Tools built on the libraries
S: Department of Mathematics
S: UC San Diego, AP&M 5739
S: La Jolla, CA 92093 USA
N: Randolph E. Bank
E: reb@sdna1.ucsd.edu
D: sg/src/vgl/vglm.c -- Vglm Class (Motif variant; joint w/ Holst)
D: sg/src/ogl/oglps.c -- OglPS Class (Perfect PS; joint w/ Holst)
S: Department of Mathematics
S: UC San Diego
S: La Jolla, CA 92093 USA
N: Stephen Bond
E: sdbond@illinois.edu
D: sg/sg.spec -- RPM support (for building src/binary RPMs)
S: Department of Computer Science
S: University of Illinois
S: Urbana, IL 61801 USA
Copyright and Terms of Use
Please acknowledge your use of SG and
FETK
by citing:
Copyright (C) 1994-2006 Michael Holst
GNU LGPL
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc.