|
muse:
|
I also got not just a few letters that were a little less than friendly. So to them, I'll put it plainly - convince the commercial X server vendors GGI is a good idea and I'll believe it. I trust them. That said, I should also point out that as a reader of this column you should make your own decisions. Go to the GGI Web site and read their material. Don't trust it simply because you read it here. Writers make mistakes too. The web makes it very easy to distribute information, but there are very few checks in place to force writers to be accurate. The morale: verify your information with more than one source.
One other thing: one responder very politely suggested that I
should know more about what I write before distributing it in a place that
carries such "authority" - the Linux Gazette. He is correct:
I need to try to be as accurate as possible. But to those who were
not so polite, try to remember: this is just a hobby. I'm not
really a graphics expert and I do get things wrong. If you're going
to nudge me in the right direction, please do so politely. And please,
no more email on GGI. The kernel team is better qualified to decide
GGI's fate in Linux than I. I'm not even certain any of the kernel
developers read this column!
Ok, on to the work at hand. This month I conclude the two part
status update on X servers with information on Metro Link. Last month,
if you recall, I covered XFree86/S.u.S.E and Xi Graphics. Also in
this months issue of the Muse is a little bit of information I gathered
while trying to find some decent offline storage media. I'll kill
the ending - I ended up with an Iomega Jaz drive. But you'll still
want to read about why I chose it and what it takes to install the beast.
Finally, I do a little review of XFPovray. This is an XForms based front end to POV-Ray, the 3D raytracing engine. I used it recently in working on another cover for the Linux Journal.
Enjoy!
XFree86 3.3.2 is releasedXFree86 version 3.3.2 is now available. The XFree86 3.3 distribution is available in both source and binary form. Binary distributions are currently available for FreeBSD (2.2.2+ and 3.0-CURRENT), NetBSD (1.2 and 1.3), OpenBSD, Interactive Unix, Linux (ix86 and AXP), SVR4.0, UnixWare, OS/2, Solaris 2.6 and LynxOS AT.The XFree86 documentation is available on-line on their Web server. The documentation for 3.3 can be accessed at http://WWW.XFree86.org/3.3/. The XFree86 FAQ is at http://WWW.XFree86.org/FAQ/. The XFree86 Web site is at http://WWW.XFree86.org |
Moonlight Creator - 3D modellerThere's a relatively new GPL modeller available. It's call moonlight creator and can be found at http://www.cybersociety.com/moonlight/This modeller generated almost as much email as my comment on GGI - and I didn't even say anything about it last month!
Pad++The NYU Center for Advanced Technology has released a new drawing tool with some object placement and scaling features possibly worthy of attention as they continue to extend The Gimp.Precompiled binaries for several flavors of UNIX.
Click on Pad++.
|
||
LParser Source Code ReleasedLaurens Lapré has released the source code for his popular LParser tool. LParser creates 3D forms using a descriptive language called an L-System. It can be used to produce 3D trees, plants and other organic items. Output formats include VRML, POV-Ray, and DXF.On his web page Larens writes:
|
SART - 3D Rendering Library for GuileSART is a 3D rendering library for Guile. It supports zbuffering, raytracing and radiosity, with advanced textures, and image processing and other features. This is the first public release announcement, as the 0.5a2 version is in the developers opinion sufficiently stable and simple enough to compile to meet a wider circle of developers (and even users).SART is freely distributable under GPL. To read more, visit the webpage: http://petra.zesoi.fer.hr/~silovic/sart The develper asks:
|
||
BMRT 2.3.6 is finally officially shipping. Er, well, you know what I mean -- it's on the FTP site.
Please get the latest and replace the beta, if you had it. I managed to squash many bugs in the beta, and also reduced both time and memory by about 15% for large scenes!
Other News: Tony Apodaca and I are co-organizing a course for this summer's
Siggraph conference. The course is titled "Advanced RenderMan: Beyond
the Companion", and will taught by myself and Tony, Ronen Barzel (Pixar),
Clint Hanson (Sony Imageworks), Antoine Durr (Blue Sky|VIFX), and Scott
Johnston (Fleeting Image Animation).
Hope to see some of you there!
Enjoy the software,
-- lg
...a description of the Kodak DC120 .KDC File Format can be found at http://www.hamrick.com/dc120/. This format is the one used by the popular Kodak DC120 digital camera. There is Windows command line source there for converting the files to JPEG or BMP formats. Anyone looking for a project might look into porting this to Linux for use with, for example, NetPBM, ImageMagick, or the GIMP.
...and speaking of digital cameras, did you know there is a small software package called PhotoPC for Linux that supports a number of digital cameras, including: Agfa, Epson PhotoPC models, Olympus Digital cameras line, Sanyo, and Sierra Imaging. Take a look at the PhotoPC Web page at http://www.average.org/digicam/.
...there is a good editorial on the future of games on Linux at Slashdot.org. The editorial was written by Rob Huffstedtler. It's a good piece, and I have to say I agree with Rob's sentiments about commercial software - it isn't evil and shouldn't be viewed that way. Any development on Linux - free or commercial - helps spread the word. Linux isn't just about free software. It's about having a choice, whether you are a developer or a user.
...the address for the AMAPI modeller has changed (I don't know how long ago this happened, but I was just notified by a reader):
Tristan Savatier ([email protected]) wrote:
Glenn McCarter <[email protected]> wrote to the IRTC Discussion List:
David R. Heys originally asked the GIMP Discussion List (or possibly the IRTC-L list, I think I may have logged this incorrectly):
David Robertson <[email protected]> from the Computer Science Department of the University of Otaga wrote:
Alejandro <[email protected]> wrote:
You're problem, assuming the file you downloaded was a newer version of the GIMP than what you already had on your system, is probably that the version of GIMP you downloaded doesn't work with the GTK libraries you have. In that case, you need to get a compatible version of the GTK libraries.
Larry S. Marso ([email protected]) wrote to the GIMP User list:
Where are such patches?
But I had some problems with pressure sensitivity, like random pointer lockups and such, and generally did not like the feel of that much, so although I still use the patched version of gimp -.99.18 - I turned pressure sensitivity off.. I have ArtPad II.
Well, I wish it was faster ... and had more options. But I've never experienced "pointer lockups and such". The gsumi app available on the same web site provides a bitmap drawing capability at extremely high resolution (the default is 4000x4000) with pressure sensitive drawing (including caligraphic tips). Great for creating postscript signatures, and also for high resolution drawings suitable for subsequent manipulation by Gimp.
Last year I attempted to address the problem by installing a 450Mb floppy tape drive on my file server. Once installed, this worked fairly well with the zftape driver and the taper backup software, but initially I had quite a time getting the zftape driver installed. From the point of view of cost the floppy tape drive is a good solid solution. A floppy tape drive currently runs less than $150US. From the point of view of convenience, well, it takes a long time to backup 1G of data onto a tape drive running off of a floppy controller. Taper does provide a fairly convenient curses based interface for selecting the files to be backed up or retrieved, but my needs were less administrative. I simply wanted to copy over a directory tree to some offline media and then clean up that tree. Later, if I needed them, I wanted to be able to copy them back in. I'm wasn't quite at the point where offline media management was a real problem - I didn't need special tools for keeping track of what I had on the offline media. What I needed was a removable hard disk.
Fast forward to this year. Technology once again has heard the cry of the meek and a flurry of removable hard disk solutions are now hitting the shelves. One of the first, and currently the most popular if you believe the noise in the trade magazines, is the Iomega Zip drive. This is a drive with a cartridge that looks somewhat like a fat floppy disk. The cartridge holds 100Mb of data, good enough for 3 or 4 of my smaller projects or one large project. The drives are running under $130US (I've seen them as low as $119) and the cartridges are about $20 each, cheaper if bought in bundles of 3 or more. The drives are available as either parallel or SCSI connected devices.
The problem with this solution is simply size. 100Mb of data can be generated fairly fast using the GIMP - I've had swap files from this tool larger than that. I also had a hard time finding an external drive. Most of the drives I could find locally were internal drives. This was probably just a local distribution or supply problem, but then I didn't look very hard for these drives once I'd decided they simply were too small.
The next step up from this for Iomega is the Jaz drive. The first versions of these drives, which is what I purchased, hold about 1G of data. The latest versions will support the old 1G cartridges and the newer 2G cartridges. An external SCSI version is available so I was able to connect the drive to my recently purchased Adaptec 2940 (which is what I hooked my scanner to) without having to dig into the innards of my hardware. Again, convenience is a key here - I was willing to pay a little more for ease of use.
There are a number of removable hard drive solutions on the market today, however I wasn't able to find information on support for any of these devices except the Iomega drives. This information is available at the Jaztool page. Jaztool is a package for managing the drive, which I'll discuss in a moment. Strangely, the Jaz Drive Mini-Howto does not appear to be on the Linux Documentation Project pages, although a Mini-Howto for the Zip drive can be found there.
Since the drive is connected to a SCSI controller there aren't any Jaz-specific
drivers necessary. You just need to find a SCSI card with supported
drivers. I chose the Adaptec 2940 because the driver for it (aic7xxx)
was a loadable module that was precompiled in the Red Hat 4.2 distribution
that I currently use. In other words, I was able to simply plug the
card in, run insmod aic7xxx,
and the card was running. The 2940 has a high density SCSI connector
which is the same sort of connector used by the Jaz drive. I had
previously purchased a high density to 25 pin cable converter to connect
my 2940 to the UMAX scanner (which has the 25pin connector), so I simply
stuck the Jaz driver between the scanner and the adapter. The Jaz
drive comes with a converter, if you need it (the UMAX scanner did not).
Total time for hardware install - about 20 minutes.
As mentioned earlier, there is a tool for managing the Jaz drive called
Jaztool. This package provides a software means to eject, write protect
or read/write enable, and retrieve drive status. Password protection
is available but not officially supported. The man page gives information
on how to use this feature if you wish to give it a try. Mode
5 (password protected write and read) is not supported by jaztool,
even though the Jaz drive supports it. You cannot access the
cartridge that comes with the drive in write mode, so you'll need to use
the jaztool program to allow you write access to that cartridge.
The Jaz Drive Mini-Howto explains how to do this quite clearly. The
disk can be mounted as delivered using the VFAT filesystem type, which
means that long file names can be used. This removes the need to
reformat disk with native Unix filesystem. However, the disk that
comes packaged with drive is nearly full. It contains a large number
of MS-related tools for DOS, Win3.1, Win95 and WinNT. Since I didn't
need these I simply mounted the drive and used rm -rf
* on it to clean it up. Once I'd done that, I decided
to go ahead and just place an ext2 filesystem on the driver. This
is simple enough following the information provided in the Jaz Driver Mini-Howto
on the Jaztools page at http://www.cnct.com/~bwillmot/jaztool/.
Speed on the drive is quite good - the Jaz drive has an average of 12ms seek times, compared to the 29ms of the Zip drive. This provides the sort of file management I was looking for by allowing me to simply copy files to and from the drive and at a speed comparable to my regular disk drives. It's certainly faster than the floppy tape solution.
As I was writing this article I started to consider if I had gotten my moneys worth. The Jaz drive runs about $299US for an external SCSI drive, about $199US for internal drives. Compared to the floppy tape I got about twice the storage space for about twice the price. At least I thought I had, until I added in the cost of the SCSI card and the media. The cost for the SCSI card I can significantly reduce by making full use of the 7 devices I can connect to it, but it still ran about $240US. The media, on the other hand is significantly higher. Travan 3 tapes (which are what you use with the floppy tape drive) run about $30US or so (I think - it's been awhile since I purchased them). The Jaz cartridges are $125US each! You can save a little by purchasing them in packs of 3 for about $300US. The good news here is that recent court rulings have allowed another company (whose name escapes me right now) to sell Zip and Jaz compatible media here in the US. The result should be a drop in the price of the media over the next 6 months to a year. The one cartridge I have now will hold me for another couple of months at least. By then, keeping my fingers crossed, I'll be able to get a 3 pack for $250 or less.
So, adding the Iomega Jaz drive was simple enough. The information
and software provided by Bob Willmot (the Jaztools author) made getting
the cartridge running almost a no-brainer. And I now have over a
Gigabyte of external storage that I can access nearly as fast as my regular
hard drives. All things considered, it's been one of my better investments.
X Server Update Part II - Metro LinkLast month I provided the first part of an update on 3D support available in X Servers and from other places. I had gotten a number of emails from readers asking where they could find drivers for various 3D video cards. I also wanted to find out to what extent the X Input Extension is supported. Since I hadn't done so in the past, I decided to contact the various X server vendors and see what they had to say on the subject.I sent out a query to the 4 X server vendors I knew of: Xi Graphics, Metro Link, XFree86 and S.u.S.E. The query read as follows: Do you have any information which I may use in my column related to your current or planned support for 3D hardware acceleration (specifically related to OpenGL/Mesa, but not necessarily so)? What about support for alternative input devices via the X Input Extension. The GIMP, and its X toolkit Gtk, both make use of X Input if available and I expect many other tools will do so as well in the near future. Last months article covered 3 vendors, Xi Graphics and XFree86/S.u.S.E, plus the Mesa package. This month I'll cover Metro Link. Due to a bit of poor time managment on my part, I wasn't able to cover Metro Link at the same time as the others. My apologies to all parties for this. While reading this article please keep in mind that my intent was to simply query for information about X Input and 3D hardware support. It is not intended for this to be a comparison of the vendors products nor do I offer any editorial on the quality of their products. I have tried to remove some of the marketing information both from last months article and this months, but I also want to be fair to the respondents and provide as much of the information that they provided that is relevent to the topic. My first contact with Metro Link was through the assistance of Dirk Hohndel at S.u.S.E., who forwarded my request to Garry M. Paxinos. Garry was quite helpful and offered information on his own and had Chris Bare contact me with additional information. Garry first provided me with a few dates:
|
||
Not long after my first contact with Garry, Chris Bare provided a more detailed description of what is in the works. Chris is the engineer responsible for Metro Link's X Input Support.
Our graphical configuration tool provides a fast and accurate on-screen calibration procedure for any supported touch screen. Future plans include support for the Wacom tablet as a loadable X Input module and support for 3D input devices like the Space Orb. We are interested in supporting any device there is a reasonably demand for, so if there are any devices your readers have asked about, please let me know. Contact Information
|
Online Magazines and News sources
C|Net Tech News Linux Weekly News Slashdot.org General Web Sites
Some of the Mailing Lists and Newsgroups I keep an eye on and where
I get much of the information in this column:
|
Let me know what you'd like to hear about!
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
Graphics Muse #14, March 1998