© 1998 by
|
© 1998 by |
 |
muse:
 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.
|
his column is dedicated to the use, creation, distribution, and discussion of computer graphics tools for Linux systems. Well, there were quite a few announcements in the past month and I'm finding that not all are being cross posted to both comp.os.linux.announce and to freshmeat.net. It takes a little more diligence on my part to catch all the announcments, but since I visit both places fairly often it really isn't that big of a problem. On the other hand, is it really necessary to repeat those announcements here? I thought about this for a while, and finally decided it is worth the effort since both c.o.l.a and freshmeat are sites for general announcements and the graphics-specific items can easily be overlooked. By gathering them up and reprinting them here, I can let my readers worry less about missing the important stuff through the sea of other announcements at other sites.
I've finally started to catch up on my Musings, too. This month's issue includes discussions on:
Anyway, a review of Blender is a definite future Musing. The last time I tried it, the program seemed to be stable, but the interface is rather complex. A general examination showed that this modeller is quite feature-rich. It's just that the interface is not intuitive to a 3D newbie, perhaps not even to an experienced 3D graphic artist. A better set of documentation is reported to be on the way, due out some time in September. I'll wait and see what this might offer before stepping up for a review of Blender.
You can also keep an eye out for a new and improved Graphics Muse Web site coming soon. I expect to be able to launch the new site sometime in the middle to end of September. It will combine the Linux Graphics mini-Howto with the Unix Graphics Utilities into a single searchable database, provide recommended reading material and allow you to post reviews of software, hardware and texts, plus it will provide more timely news related to computer graphics for Linux systems. And, of course, all the back issues of the Graphics Muse column from the Linux Gazette will be there too, in a semi-searchable format with topics for each month provided next to the links to each month's issue. I'll probably post an announcement about it to c.o.l.a when it's ready.
 |
 |
|||
The ParPov and Pov2Rib HomepageParPov is a free (GNU), object-oriented library written in C++ for parsing Scene Files from the Persistence of Vision (POV-Ray) Ray-Tracer. It will read a scene written using version 1-3 syntax and creates a structure of C++-Objects, representing all details of the original description. You can query those objects and use the information to convert the scene to other formats or many other uses. Pov2Rib is also a freely available progam, which allows you to convert scene files from POV-Ray to a RenderMan Interface Bytestream (RIB). The tool is the first application of libParPov.http://www9.informatik. uni-erlangen.de/ ~cnvogelg/pov2rib/index.html GQview 0.4.0GQview is an X11 image viewer for the Linux operating system. Its key features include single click file viewing, external editor support, thumbnail preview, thumbnail caching and adjustable zoom. GQview is currently available in source, binary, and rpm versions and requires the latest GTK and Imlib libraries.http://www.geocities.com/ SiliconValley/Haven/5235/ |
|
TKMatmanTKMatman is a tool that lets you interactively set and adjust parameters to RenderMan shaders and preview images with the given parameters. It can handle surface, displacement, interior, exterior, atmosphere, light and imager shaders and their combinations. The idea for the program comes from Sam Samai, who wrote the very useful IRIX version. With the availability of the Blue Moon Rendering Tools for different platforms the author of TkMatman thought that a lot more people will use the RenderMan interface and need ways to select their shaders. That's why he published his private LINUX version of MatMan. The program was initially only meant for his own use, but it is in a pretty stable state now. All feedback is appreciated and new versions will be made available at the following site:http://www.dfki.uni-sb.de/ ~butz/tkmatman/ ImPressImPress allows you to create good quality documents using vector graphics. You can use ImPress within a web browser with the Tcl/Tk plugin. It's a reasonable desktop publishing and presentation tool in a small package designed for Linux and for integration with Ghostscript.The GPL'd .03alpha release fixes many bugs and adds better web and presentation functionality. http://www.tcltk.com/tclets/impress/index.html |
|
|
|
||
LibVRML97/Lookat 0.7LibVRML97 is a toolkit for incorporating VRML into applications, and Lookat is a simple VRML browser based on that library. This code is currently being developed and is one of the more complete open source VRML browsers available. All VRML97 nodes except Text/FontStyle and the drag sensors (CylinderSensor, Plane, Sphere) are supported. The Script node supports much of the Javascript API with more on the way.Version 0.7 adds Javascript scripting, MovieTextures, TouchSensors, Anchors, Inlines, and command line arguments -url and -geometry for running under XSwallow as a Netscape plugin. http://www.vermontel.net/ ~cmorley/vrml.html |
SlidedrawSlidedraw is a drawing program in Tcl/tk for presentation slides with postscript output and full-featured. You can see snapshots, get slide collections or the very latest package available from it's new web page.URL: http://web.usc.es/~phdavidl/slidedraw/ Beta testers are welcome. Contributors for slide collections and documentations are also invited. MindsEye 0.5.27MindsEye is a project to develop a free (in terms of the GPL) available 3D modelling program for Linux. It features modular design, Multi-scene/user concept, Kernel-system view instead of Modeler-system view, Object oriented modelling design and network support in a MindsEye-kernel way.http://mindseye.luna.net/ |
||
|
|||
http://developer.netscape.com/docs/examples/dynhtml/visual/index.html
http://developer.netscape.com/software/jsdebug.html
It took a while, but finally a free server for Weitek P9100 based cards is available. XFCom_P9100 is not yet accelerated and has not received as much testing as we would have liked it to, but it should work fine on most P9100 boards.
XFCom_3DLabs-4.12
With this version of XFCom_3DLabs, several problems with earlier versions should be solved. New features and fixes include:
As always, these servers are freely available, the sources to these servers are already part of the XFree86 development source. Binaries for other OSs will be made available, time permitting.
The driver is available from ftp://ftp.suse.com/pub/suse_update/XSuSE/xmatrox/.
Real-time Virtual Worlds are now possible on most workstations and PCs. The challenge is to design user-friendly systems for creating new applications and tools. This special issue of the Visual Computer is dedicated to new algorithms, methods, and systems in Real-time Virtual Worlds. Original, unpublished research, practice, and experience papers are sought that address issues in all aspects of Real-time Virtual Worlds. Topics include, but are not limited to:
| Paper Submission: | October 31, 1998 |
| Acceptance/Rejection Notification: | January 15, 1999 |
| Final Manuscript Submissions: | February 15, 1999 |
| Publication: | Summer 1999 |
Nadia Magnenat-Thalmann
Associate Editor-in-Chief
MIRALab, University of Geneva
Email:
Daniel Thalmann
Computer Graphics Lab
EPFL
Email:
Submission guidelines: Authors may submit their paper either as an HTML URL or by ftp. For ftp, the electronic version of your manuscript should be submitted in PDF (preferred) or Postscript (compressed with gzip) using anonymous ftp to ligsg2.epfl.ch. The paper should be submitted as one file. The file name should be first author's name. Please follow the procedure:
Features include:
For further information (screenshots, download) please consult my homepage at:
Kai-Uwe Sattler
http://www.cs.kuleuven.ac.be/cwis/research/graphics/RENDERPARK/
|
...The computer magazine PC Chip will be publishing an interview with Ton Roosendaal, owner of Not a Number which is the company bringing us the 3D modeller Blender. This interview has been placed online so readers can get an early glimpse at it.
A: I didn't know the answer to this one, but found the following answer on the Gimp-User mailing list (unfortunately I didn't get the responder's name - my apologies to that person):
Try the "Script-fu --> Utils --> ASCII 2 Image Layer" command. This allows you to import a text file as one or more layers of text.Note that this Script is available either from the Image Window menu's Script-Fu option or from the Xtns menu's Script-Fu option.
Q: Mark Lenigan () wrote to the Gimp User mailing list:
I'm trying to create a transparent GIF with a drop shadow for the title graphic on my Web page. I'm pretty much following the cookbook from www.gimp.org/tutorials, except that I'm not including the background color layer and using "Merge Visible Layers" to keep the final image transparent. Everything goes fine until I need to convert the image to an indexed image just before I save it in the .gif format file. At that point the shadow in my image immediately disappears and the text seems to lose its anti-aliasing. Can anyone shed some light on to this?A: responded:
Yes. Gimp can only handle 1-bit transparency in indexed color mode. So when you convert an image to indexed the different levels of transparency will get lost. There is the great "Filters/Colors/Semiflatten" plugin. It merges all partially transparent regions against the current Backgroundcolor. Select a BG-Color (i.e. matching to the BG-Color of your Web-page) and watch the effect of the plugin. Then you can convert your Image to Indexed and save it as GIF. (GIF can also handle just 1-bit transparency).
|
wrote:
One modeller that was not listed in that issue but that looks quite interesting is Blender, which is a commercial package that has only recently been released for free (no source code) to Linux users. I hope to do a review of it soon. However, the last version I tried was not documented sufficiently to allow me to understand how to do even the most basic tasks. The interface is complex and feature rich, but not intuitive to 3D newbies.
|
But that example was extremely simple. Real world examples often have dynamic pages that are built from multiple databases. And each page often links to other dynamically built pages that provide some, or even all, of the same information from those databases. In other words, parts of each page contain the same HTML formatting and data. How can you avoid having to duplicate that HTML in each page?
With older static page development methods, there really weren't any methods for including common regions into multiple pages unless you used frames. The frames allowed you to create a region on the browser display that would be a single page of HTML that could be displayed along with various other pages. In this way, you need only maintain a single copy of that one common page. From a Web developer's point of view, this was an ideal situation - it meant the probability of error in trying to update identical HTML in multiple pages was eliminated. It also meant less work. But to readers of those pages it could mean frustration, since not all browsers at the time supported frames. Even now, frame handling is not consistant between the two main browsers, Netscape Navigator and Microsoft's Internet Explorer. Although frames can be used to produce some terrific Web pages, they are not the ideal solution for supporting different browsers, especially older browsers.
Fortunately, this problem can be overcome with our new friend Perl. The method for inclusion in multiple pages of common formats and data is simple. However, the management of these common regions takes a little thought. Let's first look at how to include Perl code from different files in your main Perl script.
In Perl, a subroutine or other piece of common code would be written in a module, a separate file of Perl code. Modules can be included at any point within a Perl script. By default, Perl looks at a special variable called @INC to determine where to find these modules. Also by default, the current working directly, ".", is listed in the @INC variable as the last directory to search for modules. Note: @INC is a list variable, that is, it is an array of strings with each string being the name of a directory to search for modules.
To include a module into your main Perl cgi script you would use the require function. The format is simple:
When the module is included, the code within it is run at the point of inclusion. You can, if you so desire, write the module to have code that runs right then and there using variables with a global scope (i.e., they are visible to the original program as well as the included module). However, it would probably make more sense to write the module as a subroutine call instead. You can still use globally scoped variables, but by making the module a subroutine call, you can guarantee the code is not run until you specifically request it. You can also run it more than one time if you want.
So how do you make a subroutine? Just wrap the code inside the following construct:
If you want to pass parameters into the subroutine, you can do so as a list. For example:
foreach $arg (@params)
{
# now run through each parameter one at a time
# and process it.
if ( "$arg" eq "" )
{
...
}
}
}
|
 |
|
libgr - A collection of image librariesMany users of graphics tools discussed in this column will find that those tools are dependent on any number of file format specific libraries. For example, the Gimp needs libraries for JPEG, PNG, PNM, MPEG and XPM in order to support these file formats. The Gimp doesn't understand how to read these files directly - it is dependent on the image format libraries for assistance in reading and writing files in these formats. Since the Gimp (and other tools) don't include these libraries in their source distributions, users are often required to retrieve and install these libraries manually.Normally, users would download format-specific libraries and build them separately. Each of the formats mentioned earlier, plus a few others, are available somewhere on the Net in source format. Most are available somewhere on the Sunsite archives. Unfortunately, not all of these format specific libraries are easily built on Linux. The Gimp User Mailing list is often flooded with questions about how to get the JPEG library to build shared libraries. By default this library doesn't build a Linux ELF shared library. In fact, even with the proper configuration it still only builds a.out shared libraries. A better solution is needed. Enter libgr. This is a collection of image format libraries that have been packaged together and organized to easily build and install on Linux systems. The package builds both static and ELF shared libraries automatically. The distribution is maintained by Neal Becker () and is based on the work done originally by Rob Hooft (). The latest version, 2.0.13, of libgr can be retrieved from ftp.ctd.comsat.com:/pub/linux/ELF. Libgr contains the following set of graphics libraries:
FBM is the Fuzzy Pixmap Manipulation library. This package is related to, but not part of, the PBMPlus package by Jef Poskazner. The library can read and write a number of formats, including:
JPEG is actually a standard that defines a suite of encodings for full-color and continuous-tone raster images1. The software for this library, which is essentially the same as the software that comes in the standalone JPEG library package found on the Gimp's ftp site, comes from the Independent JPEG Group and, as far as I can tell, supports the complete JPEG definition. JPEG is a common format for the Web since it is one of the formats listed by the WC3 in the early HTML specifications for Web images. The PBM, PGM, PNM, and PPM formats are all part of the NetPBM/PBMPlus packages. These formats are often used as intermediary formats for processing by the NetPBM/PBMPlus tools. Although these libraries provide the capability of saving image files in these formats, I have not seen this as a common practice. This is probably due to the fact that the files tend to be rather large and the image formats are not generally supported by non-Unix platforms. These formats are widely supported, however, by Unix-based graphics software. The PNG library supports the relatively new Portable Network Graphics format. This format was designed, at least in part, to replace the GIF format which had both licensing as well as a few format limitations. PNG is now an officially supported format by the WC3 although support for these images is not commonly mentioned by either Netscape or MSIE. I'm not sure if either supports PNG yet. RLE is Run Length Encoding, a format from the University of Utah designed for device independent multilevel raster images. Although the format is still in use today, you won't see it referenced often in relation to tools like the Gimp (though the Gimp does support the format) or 3D rendering engines like BMRT or POV-Ray. |
|
More Musings... |
|
||
Finally, the TIFF library is a set of routines for supporting the reading and writing of TIFF files. TIFF files are popular because of their wide support on multiple platforms (Mac, MS, and Unix) and because of their high quality images. However, they tend to be extremely large images since they do not use any form of compression on the image data.
Building the packageOnce you have retrieved the libgr package you can unpack it with the following command:
% tar xvzf libgr-2.0.13.tar.gz
This will create a directory called libgr-2.0.13. Under this directory you will find the format specific directories, Makefiles and a number of text files. In the INSTALL text file you will find instructions on how to build the software. For Linux this is a simple process of typing
% make most
which will build all the software but not install it. I recommend doing this once to test that the build actually completes successfully for all directories before trying to install anything. If the build fails and you attempt to install you may confuse yourself as to what has and hasn't been installed correctly. After the build completes, check each directory and see if the lib*.so files - the shared libraries - have been created. If all appears to have gone well, type
% make install
This will install the libraries for you. There are other options available for building and installing. Read the INSTALL text file in the top level directory for details on the other options.
At this point you're ready to use these libraries with other tools, such as the Gimp. Why use libgr vs the individual libraries?Libgr provides support for a large range of image file formats, but it doesn't support every common and/or popular format. So why use it instead of the individual format libraries? One reason is convenience. Instead of having to retrieve a whole slew of packages you can grab one. Second, as mentioned earlier, not all of the individual packages are setup to build proper ELF shared libraries for Linux. Libgr is specifically designed for building these type of libraries.What libraries does libgr not include that you might want? One fairly common X Windows format is XPM. Libgr does not support this format so you'll need to retrieve the XPM library separately. Fortunately, most Linux distributions already come with this library prebuilt and available to you during installation of the operating system. Libgr also does not support any animation file formats. If you have need to read or write files in MPEG, FLI or FLC formats, for example, you will need to locate and install those libraries individually. CaveatsOne minor caveat to using the libgr package exists with the zlib distribution. According to the documentation for libgr (in the NEWS text file) the zlib release numbers went down at some point. This means it's possible for you to have an older version of zlib installed even though its version number is higher than the one in libgr. How to resolve this is a tricky question but in my opinion it makes sense to install the zlib that comes with libgr because it's known to work with the rest of the image libraries in the libgr package. If you agree with this logic then you will probably want to remove the old version of zlib first, before doing the make install for libgr.SummaryLibgr is not a drop-in replacement for all your image file format needs, but it does offer added convenience to the Linux users by providing a Linux-specific, easy to use build and install environment. Since the libraries included in the libgr package do not change all that often it makes good system management sense to deal with the one distribution than to try to deal with updates to multiple image format packages. And if you're dealing with building the Gimp, which requires many image libraries, libgr is a much simpler solution to get you up and running in the least amount of time and with the least amount of frustration.
1. C. Wayne Brown and Barry J. Shepherd, Graphics File Formats: Reference and Guide, Prentice Hall/Manning, 1995. |
|
 |
|
Online Magazines and News sources C|Net Tech News Linux Weekly News Slashdot.org Digital Video Computer Graphics World 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 |
 |
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
Graphics Muse #15, April 1998
Graphics Muse #16, August 1998
![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
