Graphics Muse
Author: Michael J. Hammel
Description: The Monthly Column of Computer Graphics for Linux Systems.

#### "Linux Gazette...making Linux just a little more fun!"

| Set your browser as wide as you'd like now. I've fixed the Muse to expand to fill the aviailable space! © 1998 by mjh

| muse: v; to become absorbed in thought n; [ fr. Any of the nine sister goddesses of learning and the arts in Greek Mythology ]: a source of inspiration elcome to the Graphics Muse! Why a "muse"? Well, except for the sisters aspect, the above definitions are pretty much the way I'd describe my own interest in computer graphics: it keeps me deep in thought and it is a daily source of inspiration. [Graphics Mews][WebWonderings][Musings] [Resources]

his column is dedicated to the use, creation, distribution, and discussion of computer graphics tools for Linux systems.
Not much to say this month. I've been very busy working on some things for Linux Journal and a few other projects. I did manager to get the reviews done that I had promised last month. Well, 2 out of 3 of them. That's better than I usually do.

In this months column I'll be covering the following:

- XeoMenu, a Java based menuing program
- an update on X server support for 3D cards and the X Input Extension
- VRWave, a VRML browser for Linux

Disclaimer: Before I get too far into this I should note that any of the news items I post in this section are just that - news. Either I happened to run across them via some mailing list I was on, via some Usenet newsgroup, or via email from someone. I'm not necessarily endorsing these products (some of which may be commercial), I'm just letting you know I'd heard about them in the past month.

## XFPovray 1.3 Robert Mallozzi announces a new version (1.3) of his XForms interface to the ray tracer POV-Ray. If you have ever used POV-Ray from the command line, you might find this program useful. Check http://cspar.uah.edu/~mallozzir/ Source code is available in tgz, bzip2, and rpm formats. Robert S. Mallozzi University of Alabama http://cspar.uah.edu/~mallozzir/ |  | ## XMRM 2.0 (Alpha release) The Institute of Computer Graphics at Vienna University of Technology, Austria, announce the release of XMRM 2.0alpha XMRM (multi resolution morphing for X) is an image morphing program written for XWindows. A special feature of this program, which is not found in other morphing packages, is the ability to control the morphing speed of details in relation to the morphing speed of big features. Check out the XMRM homepage: http://www.cg.tuwien.ac.at/research/ca/mrm/ For a few animated GIFs visit the Online manual: http://www.cg.tuwien.ac.at/~xmrm/ For download got to: ftp://ftp.cg.tuwien.ac.at/pub/linux/xmrm/ Greetings, The XMRM-Team <xmrm@cg.tuwien.ac.at>
## FREETYPE 1.0 The FREE TrueType Font Engine Copyright (C) 1996-1998 The FreeType Development Team The FreeType engine is a free and portable TrueType font rendering engine, available in ANSI C and Pascal source code. It has been developed to provide TrueType support to a great variety of platforms and environments. Notice that FreeType is a library. It is not a font server for your preferred environment, even though it has been designed to be the basis of many high-level libraries, tools and font servers. It's a clean-room implementation that is not derived from the original TrueType engine developed by Apple and Microsoft, though it matches it regarding rendering quality. To our knowledge, it's the only royalty-free complete TrueType engine available. For more information, please visit the Freetype web site at: http://www.physiol.med.tu-muenchen.de /~robert/freetype.html | That's it. Not much in the way of announcments this month. I had a few more, but lost them pasting them into my XPostitPlus program. That's the first time it's crashed in that manner - where I lost the data. Bummer.

#### Did You Know?

...there is a OpenGL widget for GTK? Take a look at ftp://ftp.gimp.org/pub/gtk/contrib/glgtk-demo.971104.tgz.

#### Q and A

Q: How do you use anti-aliasing with POV-Ray? Do higher values cause more anti-aliasing?

A: Ron Parker responded on the IRTC-L discussion list: Whenever POV-Ray detects a sufficient change, the threshold, in colour from one pixel to it's neighbour, it will calculate the in-between color pixels by shooting multiple rays into the scene, rather than just one, to determine the colour. The higher the "+A" number is (from 0 to 1), the more rays will be shot into the scene, and the smaller a difference in colour from one pixel to the next will be needed to cause the anti-aliasing to be brought into effect. Anti-aliasing is triggered when the threshold between two pixels is reached. The number of rays is controlled by +R, and the "spread" is controlled by +J. Setting +A0.1 will trigger on smaller color differences than +A0.3, so it actually anti-aliases more than higher values of +A. All this is the description for +AM=1. Adaptive supersampling (+AM=2) works somewhat differently.

For more information, see section 6.2.5.4 of the POV documentation.

Ron Parker * parkerr@mail.fwi.com * http://www2.fwi.com/~parkerr

Q: I took an image to a printer today who requested that I bring back the image when I have increased the resolution from 72 pixels/inch to 300 pixels /inch. I cant locate how to do this with the GIMP. Any pointers?

A: You can scale the image, but that will decrease the quality of the image. The best way to deal with images you plan to print is to plan to create them using the correct resolution. For example, if you want an 8.5" by 11" image at 300pixels/inch:

width: 8.5*300 = 2550 pixels
height: 11*300 = 3300 pixels

So you need to start with an image window that is 2550x3300 and work from there. Keep in mind - doing this sort of image manipulation (with such large image sizes) is better suited to:

1. faster CPU's.
2. tons of memory
3. lots of disk space

As to "can I convert from 72 to 300 pixels from my original image": yes, use the scale option (image->scale) and set the correct size. But remember - scaling up will reduce image quality, especially going from 72dpi to 300dpi.

## Reader Mail

An unnamed reader sent the following information:

I've recently written 3 Perl scripts which help to distribute the task of rendering with povray between several CPU's. One script is for SMP (multiple processor) machines. It will break an image into halves and start a separate process for each. This utilizes both CPU's in a dual processor machine, and nearly halves the rendering time. The other two scripts work together to utilize multiple machines on a network. The server script tells each client script how much of an image to render (also sending the .pov file and any necessary files to each client).

These scripts were created using Perl 5.004, Linux 2.0.32, and POVRay 3.0. I'd be honored if you would like to include a link from your excellent graphics site to my page at http://www.frozenwave.com/~hixson/projects.html.

'Muse: I really need to update the LGH and UGU pages. Anyway, if any of my readers tries these scripts, let me know what you think of them. I don't have any multiprocessor boxes, although I do have a network. I just don't have time right now to experiment with these scripts.

Syd Logan, Senior Software Engineer @ NetManage, Inc., writes:

I was perusing an old copy of The Linux Journal in preparation to do an article or two for them on the X Image Extension when I came across your article in the November 1996 issue. This isn't so much about the article, but I just thought I'd drop you a line to make you aware of my home page which is devoted to XIE at http://www.users/cts.com/crash/s/slogan. Feel free to point any queries you may hear about or receive regarding XIE or XIElib to my home page, or to me directly at slogan@cts.com.

'Muse: Thanks for the note. While working for Xi Graphics I had read the XIE specification and wondered why it hadn't been used much. Perhaps it's like X Input - it just needed a market to drive its use. Well, the exposure Linux will give X Windows may be that driving force. We'll have to wait and see.

Thomas Vaughan writes:

My work involves writing code in Iris GL and OpenGL. I am particularly interested in accelerated 3D graphics, as I just bought a ViRGE 3D accelerator for my home PC which runs linux 24 hours a day. I have played with Mesa, but there is apparently no real free hardware support yet.

'Muse: No free support, but Xi Graphics has recently announced ViRGE 3D support in their commercial Accelerated X server.

The GGI project sounds interesting, but I don't really know whether it's worth investigating seriously yet.

'Muse: I don't really like the idea of GGI, partly because I don't think sticking the graphics driver in the kernel is a good idea but also because I don't want to see the desktop interface splintered into seperate camps. X is just really coming into its own on the desktop and I'd like to see it continue.

At work my supervisor has, on my advice, just made a capital request for a graphics card based on the 3D Labs Permedia chip which comes with accelerated OpenGL support for Windows NT. In the back of my mind, I am hoping that I can convince people at work to give linux a serious look as a low-cost alternative to the SGI platform. After all, even with GNU/Win32, the NT platform is not nearly as nice as real Linux. Unfortunately, however, this seems just a little out-of-reach at the moment, because of the apparent lack of 3D hardware support on Linux. Any news on this front would be heartily appreciated, and I would love to write bug reports and use either machine as a test platform.

'Muse: I got a similar request from Anand Rangarajan:

I noticed that SuSE http://www.suse.de/XSuSE/XSuSE_E.html has developed a bunch of drivers for the ELSA Gloria family of 3D graphics cards. Will their drivers accelerate Open GL or Mesa? Also, these drivers are free and will be integrated into the XFree 4 release.

'Muse: Well, I thought it was about time I did a little survey of the various graphics card vendors. See the X Server Update article below.

Marc S. Jensen writes to the GIMP User mailing list:

When I run xscanimage, it complains about my system not having a /dev/scanner device. So, here's my question: What do I do to my Red Hat 5.0 system to get a /dev/scanner device installed. I'm using an Adaptec 2940 SCSI adapter, and my kernel is compiled with SCSI support. What's wrong here?

'Muse: Assuming your scanner is the only deviced attached to your scsi card:
ln -s /dev/sga /dev/scanner

and you're all set. If you have more than one device connected to the scsi bus (re: cable) then you'll need to figure out which one of the /dev/sg[x] devices maps to your scanner. Then link that one to /dev/scanner.

Joel Becker also wrote to the GIMP User mailing list:

Just a quick question. What is a reccomened drawing tablet, for best use and easiest XInput setup? I think I heard the Wacom ArtPad thrown around here. Also, what is a good scanner to work with SANE? I mean ease of setup as well as quality of image.

'Muse: Can't answer about the tablet, but I just happened to install a scanner recently. I bought a Adaptec 2940 SCSI card and a UMAX 1200S scanner. The Adaptec dropped right in on my Pentium 200MMX board with no hardware config necessary. The RH 4.2 distribution I use already had the necessary scsi module prebuilt in /lib/modules (the module name is aic7xxx.o). I ran insmod aic7xxx and up it came.

The scanner I chose from the list of scanners I reviewed last year for my Graphics Muse column in the Linux Gazette. I first tried a 610s, but it only worked in greyscale modes. So I exchanged it for the more expensive (about $250) 1200s. Works quite well with the Umax drivers. Image quality is excellent. I've been scanning hardware (twisted pair and thinnet cables), and my hand once, and the scans were quite good although very dark. I just brightened them up with xv and the GIMP and all was well.

However, I haven't tried the scanner and drivers in conjunction with SANE.

Marco Iannacone wrote:

First of all I want to say thanks for all the great stuff you wrote (and still write) about Linux & Graphics.

'Muse: No problem.

Since a friend of mine uses Photoshop on Mac, I wanted to show how powerfull is Linux, so I installed RedHat 5.0 on a Pentium 166 with 64Mb of RAM, with a Matrox Mystique. When I showed him GIMP he was REALLY impressed but he found it quite slowly compared to Photoshop. I told him that the reason was probably that XFree86 was using the generic SuperVGA driver since it doesn't have a native driver for it.

'Muse: Possibly, but that would only make a difference in screen updates. The majority of the GIMP's processing is done before it updates the screen.

Is that true or maybe GIMP is only slower that Photoshop?

'Muse: Define "slower"? Slower loading the same file? Slower in computing a new brightness or contrast? Slower how?

What he might be talking about is the use of tiles, which may appear to update slowly, wherease in Photoshop they may all appear almost at once (I've never used Photoshop, so I don't know if this is true or not). So before I can answer "is GIMP slower than Photoshop" I need to know by what means you've been measuring the two.

More than this I was not able to open any GIF, JPG or TIFF coming from Photoshop... do you know the reason?

'Muse: You may not have installed the proper image libraries. Download the libgr package and install it, then try again. You may want to build the GIMP from the sources, after you install the libraries in the libgr package. Or, if you installed GIMP from one of the distributions (Red Hat, Debian, etc) you may want to verify you installed all the graphics libraries that came with that distribution too.

Tero Auvinen wrote:

In a past Graphics Muse you wrote:

...from the archive of shaders from Guido Quaroni. This archive includes shaders from the RenderMan Companion by Steve Upstill, from Texturing and Modeling by Ebert, Musgrave, et al, Larry Gritz, and various other places.

Where could I get this semi-wonderous package? Found one link from BMRT homepage, but it was defunct (anonymous ftp access denied). If you'd happen to have it somewhere, I'd appreciate a copy, otherways I'll just go and grab everything from the aforementioned fellows homepages etc.

'Muse: If the link from Larry's page (the BMRT home page) is not working I'm not certain where this package can be found. Try the Renderman Repository: http://rmr.spinne.com/.

Also hmm, I might've missed it, highly possible, but I remember that you 'promised' a 3 part BMRT special, seen 2 so far(issues 15&17), maybe in march issue?

'Muse: No, there wasn't a third part. I wanted to do one but I'm not that experienced with it and I had too many other things come up. I've never had a chance to go back and revisit it.

Re: Modellers: I can't seem to find one GOOD one, if it's nice to look and use at, then it won't export RIB, or does it in a silly way, using polygons and whatnot, one'd prefer RMan primitives huh? Sure I can do the basic primitives in a non-wysiwyg way, the ascii way. But anything more complex, no thanks.

'Muse: No modellers are available for Linux which export RIB primitives. All of the ones I know of export polygons only.

I've been thinking of getting another computer, running only MSWindows, networked together with Linux, I could edit [3D models] using Rhino or equivalent free Win95/NT modeler and render in Linux. (oh yeah, now there's Win32 port of BMRT even...but Linux I will NOT leave, Windows generally drives me nuts). Only if I had the money.

'Muse: You couldn't pay me to run MS on anything. But that's just me.

You happen to know what Larry uses for modeling? (besides Alias on SGI sighs..)

'Muse: I think he's got some big boxes, SGI's and Sun's probably. I'm sure Pixar feeds him well. On Linux he may be using AC3D (as do I). It's a pretty good modeller, but still exports everything as polygons only. It does import 3DS and Lightwave files, though. That's quite useful for using the canned models from the various model sites and CDs that are available. AC3D - http://www.comp.lancs.ac.uk/computing/users/andy/ac3dlinux.html.

Marsel Osipov writes:

I am starting a project called Virtuoso. It's a 3D Modeling/Animation/Rendering package for Linux. I am sure that I would not be able to create a high quality package by myself, so if you would like to join, visit my home page for more info. http://www.geocities.com/SiliconValley/Lakes/7705/

'Muse: We can never have too many modellers.

## XeoMenu 1.1

One of the problems with pages based around standard HTML constructs is the inability to easily modify navigation aides. A navigation aid can be a set of text links, a set of images with individual links or it can be an image map using hot spots for links. These tools allow readers of a page to move around a Web site easily. Properly done, they can remove the linearity (the hierarchical structure) of a Web site and allow the reader to move freely between pages.

Adding an text links is fairly easy to do and updating them simply requires editing the HTML. But text links lack pizazz. Images used as text links are better, but aside from using JavaScript to do image rollovers, the images are fairly static. They lack the feel of a real user interface. Image maps are no better and, in fact, don't even allow rollover changes as easily making them even more static than individual images used as links.

Fortunately, issues such as this is part of why Java exists. Java allows for more programmatic interfaces. These interfaces can take on the more familiar menu-based interfaces that readers will be accustomed to. Although it can be argued that such interfaces are not any better than static image maps, for the sake of this article we'll assume that menuing systems are a good thing.

XeoMenu is a simple Java program from Patrick Chan at Xeo (www.xeo.com) that overlays a menuing system over an image in a Web page. The program is run as an applet and is used by embedding it within HTML source code. Readers can retrieve a copy from http://java.sun.com:81/share/classes/menu/source/source.html. Java source code is included, along with an example HTML file, sample images, a users manual (a sort of man page in HTML) and the compiled Java byte code. There is also a second version of the code, called horizMenu, that permits menus to be layed out horizontally instead of vertically. Since I can't seem to get Java working on my Red Hat 4.2 system (neither through the javac compiler nor through my version of Vibe - something about my CLASSPATH is not set up right I think), I won't be able to provide information on compiling the source in this article. If I do get javac and/or Vibe working, I'll start talking about how to compile Java programs. If anyone has a write up of what I need to do to get my stock RH 4.2 version of the Java compilers working, please drop me a line.

To use XeoMenu you need to first create an image that contains two parts: The menu as it is displayed without the mouse over the image and the image as it would look if the mouse were over different parts of the original. For our example, we'll use the following image:

The image is divided into 2 halves. The left half is the image as it displays without the mouse over it. The image is actually going to be subdivided into a top (Linux) and bottom (Gazette) section. The right side, then, shows how each section will be displayed when the mouse is over that section. For example, if the mouse is over the word Linux in the image then the blue Linux text will be displayed. By default, the red colors (the left half of the image) is displayed.

Now, in order not to annoy readers without Java support, you need to move to the next section of this article, which will show how the Java application is used and what it looks like when it runs. You will need a Java compatible browser to view this part of the article.

####

#### Summary

This was just a simple example. XeoMenu itself comes with a more sophisticated example, but there is no real explanation (ie documentation) of what is going on in the code. Hopefully, between that example, the user manual, and this article you'll be able to do something useful with XeoMenu. The main applet page for Java.sun.com shows an example of the horizontal version of XeoMenu running and it's quite slick. Although the interface uses a fairly large number of optional parameters and the format for menu descriptions is less than ideal, it is still a useful tool that takes only a little getting used to in order to make a very usable menu-based interface for your Web pages.

## X Server Update I've been doing this column now for over a year and writing for Linux Journal on and off for another year. In that time I haven't really addressed one of the more obvious topics related to doing graphics on Linux - the X server. Part of the reason for that is that I don't have the resources to test a bunch of different server configurations. If I got paid to do this it would be a different story, but this column is born from whatever time and system resources I can spare each month. Still, I get requests fairly often asking for information about what 3D video cards are supported under Linux and which ones support various hardware extensions such as the X Input Extension. Most of the questions specifically ask "which are supported under XFree86". But some readers ask about support in general, either free or commercial. Well, I thought it was time I sent a query to the various vendors and find out where things stand. The email I sent was fairly generic. It read as follows: This query was sent out around the 12th of this month to Xi Graphics, Metro Link, SuSE, and the XFree86 project. I received responses from all 4, however Metro Link did not receive my query immediately and so their response came in too late for this article. I will cover Metro Link's response next month. Please note that this article is intended to list which servers support what features/devices and is not intended to explain how to use those features. The responses have been edited to remove what appeared to be editorial comments, where recognizable. I will refrain from editorializing on these responses in this article as well. The first reply was nearly immediate and came from Dirk H Hohndel at SuSE. He sent two emails, one as the Vice President of The XFree86 Project, Inc. and one as the Lead Developer, S.u.S.E. GmbH. Dirk wears both hats, and therefore his comments are considered official responses, one from each organization. Both responses were direct and to the point. First his XFree86 response:
Well, XSuSE and XFree86 are mostly identical. As far as legally possible, all work done on XSuSE is integrated into the next XFree86 version. XFree86 in itself focuses on the X Window System and 2D support for the different cards. While they are not actively pursuing 3D support, they are in contact with several groups working in that area. I do not speak for Metro Link, but I can tell you that Metro Link and XFree86 are in very positive cooperation on the 2D side of servers. Metro Link donated lots of code to XFree86 recently, and Metro Link and XFree86 are working together on many aspects of the design of our future X servers.
Because Dirk's response came quickly, and because responses from the other vendors provided more detailed information, I thought I should offere XFree86 a chance to expand their reply. When asked to comment on architectural details and XFree86's relationship to the commercial vendors, Dirk responded:
Why would I bore you or anyone else with architectural details that no one really cares about.
He followed up his XFree86 reply with a response from SuSE:
SuSE is working on hardware 3D support, but there is no release date for that, yet. The 2D drivers from SuSE are intended to be integrated into XFree86-4.0, but we are currently running into some legal problems with that for one of them (3DLabs GLINT), as some of the docs are under NDA and we have not been able to get the permission to release sources, yet. We are working on it, though. All the other drivers from SuSE have already been included into XFree86-3.3.2
The other replies came from Xi Graphics. Both Thomas Roell, President of Xi Graphics and technical architect for their servers, and Jeremy Chatfield responded. Thomas wrote:
Our next generation X-Server will support additional new input devices for the XInputExtension. The extension itself is supported since Accelerated-X 4.1. Planned devices are mainly CAD oriented input systems, like Tablets, Touchscreens and Space-Balls. As for Hardware 3D, you can bet that the next generation will have that.
Jeremy Chatfield followed up with the following (edited partially for length):
Accelerated-X 4.1 supports the XInputExtension, using a small and fixed list of devices, with very limited device management. Future releases will support a wider range of devices. We've been evolving Accelerated-X ever since 1994, to take advantage of 3D hardware acceleration. Examples of the technology introductions and the reason for needing them for 3D support: Memory allocation and buffer management. 3D uses a lot of memory. Standard malloc() (as of 1994, when we started this work) did not permit programs to decrease in size, tended to thrash memory when freeing and sometimes when allocating, and exhibited other behaviors that were not suitable to long running processes with a mix of temporary and long term storage in a wide variety of data sizes. We do things like lazy buffer allocation, only allocating stencil buffers when needed, and so on. This improves speed and reduces system impact, seen in total Server size, and paging demand.
-Top of next column- |  |
More Musings... VRWave 0.9 --
Coprocessor locking. When using the host processor, graphics engine and 3D engine, all writing in the same memory areas, and when using both system memory (via AGP) and graphics board memory, fast and correct mutex locking is essential. [Without locking] this will cause problems when all three processors (or more) attempt to handle the same memory. We have continued to refine our mutex locking for several years, though this is not visible in any product other than multihead, at present. Asynchronous I/O When X Servers with high levels of hardware acceleration are handling buffered drawing requests, keyboard and mouse input is put into the end of the queue. This results in sluggish response, and in mouse and keyboard data being handled in bursts. Mouse acceleration can be triggered inappropriately, so mouse motion becomes very hard to control, and sequential single button clicks can be misinterpreted as double clicks. We introduced the "Velvet Mouse" mechanism to permit input even while the Server was in heavy rendering, as will be typical of 3D dynamic applications. Overlays. Many 3D applications on workstations rely on the presence of overlays. [Overlays] also benefit from the memory management and other architectural changes in Accelerated-X.
Xi Graphics recently announce support for ViRGE 3D (see the February 1998 Graphics Muse). Beyond these two vendors, there is also 3D hardware support available for Mesa for the following video hardware: 3Dfx Voodoo - Cards based on the 3Dfx Voodoo chipset (such as Diamond Monster 3D and Orchid - Righteous 3D) are supported under Linux and Windows 95. Look here for the latest info. This is the best supported 3-D hardware for Linux at this time. 3Dfx Voodoo Rush (rendering into window) - Supported under Windows. Linux support is underway. GLINT-based boards - Look here for the latest info. Cirrus Mondello - No longer supported- download Mesa 1.2.8 if you're interested in this driver. This information was taken directly from the Mesa Web pages. I ignored any cards for which Linux was not mentioned except the Cirrus Mondello. I don't know if it's for Linux or Windows. Also, I don't know exactly how Mesa makes use of this hardware without actually being part of the X server. You will have to investigate the Mesa pages and its links for more information in that area. So, now you should know as much as I do with respect to 3D and X Input support from XFree86/SuSE and Xi Graphics. In summary, most of the 3D work seems to be planned and under development, but no word on when the support (at least for wide spread 3D support) will be available. Neither XFree86/SuSE nor Xi specifically mentioned any 3D boards being supported, although Xi did have the announcement for the ViRGE 3D last month. Xi stated they support the X Input Extension in their Accelerated-X 4.1 release. Although XFree86 didn't mention it, I know that X Input is supported in their product as well. Don't forget: I'll be covering Metro Link's responses to my query next month. I should mention again that I have worked for Xi Graphics in the past, and in fact worked with both Thomas and Jeremy at Dell computer and with Jeremy at Information Foundation (a USL source code licensee back around 1993 or so). I have made every attempt to remove all editorial comments, both my own and any from the respondents, from this article. #### Contact Information XFree86: Announcements: comp.os.linux.announce and other announcement groups Web site: http://www.xfree86.org Support: XFree86@XFree86.Org Business: BOD@XFree86.Org S.u.S.E.: Announcements: comp.os.linux.announce Web site: http://www.suse.de/XSuSE/XSuSE_E.html Support: x@suse.de Business: x@suse.de Dirk reports: In both cases we try to keep the web pages up to date and XFree86 has a FAQ online that contains workarounds for known bugs. Xi Graphics: Announcements: accelx-announce-request@xig.com with the one word message "subscribe" Web: http://www.xig.com User-to-User mailing list: accelx-users-request@xig.com with the one word message "subscribe" Email: sales@xig.com - automated initial response, but a human reader. Phone: +1 800 946-7433 (US), +1 303 298-7478 (Int'l). Fax: +1 303 298-1406 Jeremy added: We keep the web site up to date.

The following links are just starting points for finding more information about computer graphics and multimedia in general for Linux systems. If you have some application specific information for me, I'll add them to my other pages or you can contact the maintainer of some other web site. I'll consider adding other general references here, but application or site specific information needs to go into one of the following general references and not listed here.

Linux Graphics mini-Howto Unix Graphics Utilities Linux Multimedia Page Some of the Mailing Lists and Newsgroups I keep an eye on and where I get much of the information in this column: The Gimp User and Gimp Developer Mailing Lists. The IRTC-L discussion list comp.graphics.rendering.raytracing comp.graphics.rendering.renderman comp.graphics.api.opengl comp.os.linux.announce |

## Future Directions

Next month: Unknown. I've got some prior obligations (paying ones, that is) that I absolutely must get done. And soon.

Let me know what you'd like to hear about!

© 1998 Michael J. Hammel

#### Previous ``Graphics Muse'' Columns

Graphics Muse #1, November 1996
Graphics Muse #2, December 1996
Graphics Muse #3, January 1997
Graphics Muse #4, February 1997
Graphics Muse #5, March 1997
Graphics Muse #6, April 1997
Graphics Muse #7, May 1997
Graphics Muse #8, June 1997
Graphics Muse #9, July 1997
Graphics Muse #10, August 1997
Graphics Muse #11, October 1997
Graphics Muse #12, December 1997
Graphics Muse #13, February 1998

##### Copyright © 1998, Michael J. Hammel
Published in Issue 26 of Linux Gazette, March 1998