"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]

      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

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     https://cspar.uah.edu/~mallozzir/  Source code is available in tgz, bzip2, and rpm formats.  Robert S. Mallozzi  University of Alabama  https://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:  https://www.cg.tuwien.ac.at/research/ca/mrm/  For a few animated GIFs visit the Online manual:  https://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:  https://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?

Q and A

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 * https://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

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

Reader Mail

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 https://www.frozenwave.com/~hixson/projects.html.

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 https://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.

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.

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

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.

I noticed that SuSE https://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.

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?

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.

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.

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.

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

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?

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.

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?

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.

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.

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

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. https://www.geocities.com/SiliconValley/Lakes/7705/

XeoMenu 1.1

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 https://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

   
 
   

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:    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. 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:  https://www.xfree86.org Support:  XFree86@XFree86.Org Business: BOD@XFree86.Org   S.u.S.E.: Announcements: comp.os.linux.announce Web site:  https://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: https://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

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