Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!xanth!cs.odu.edu!tadguy From: tadguy@cs.odu.edu (Tad Guy) Newsgroups: comp.graphics Subject: Re: DBW_render for SUN 3 ????? Summary: xanth.cs.odu.edu:/amiga/{dbw,distpro}.zoo Message-ID: <9029@xanth.cs.odu.edu> Date: 3 Jun 89 01:33:57 GMT References: <93@unmvax.unm.edu> <62500002@uicbert.eecs.uic.edu> Sender: news@cs.odu.edu Reply-To: tadguy@cs.odu.edu (Tad Guy) Organization: Old Dominion University, Norfolk, VA Lines: 106 In-reply-to: cooper@uicbert.eecs.uic.edu daniel@unmvax.unm.edu writes: >Has anyone converted the public domain ray trace program called DBW_render >to run on a SUN workstation? Ofer Licht has done just that. His modified DBW_Render is available via anonymous ftp from xanth.cs.odu.edu as /amiga/dbw.zoo. It is also designed to use ``DistPro'' to distribute the computations between many machines (this is available as well as /amiga/distpro.zoo). I haven't tried any of these, but the README is included below... ...tad ************************************************************************ * * * Copyright (c) 1987, David B. Wecker * * All Rights Reserved * * * * This file is part of DBW_Render * * * * DBW_Render is distributed in the hope that it will be useful, but * * WITHOUT ANY WARRANTY. No author or distributor accepts * * responsibility to anyone for the consequences of using it or for * * whether it serves any particular purpose or works at all, unless * * he says so in writing. Refer to the DBW_Render General Public * * License for full details. * * * * Everyone is granted permission to copy, modify and redistribute * * DBW_Render, but only under the conditions described in the * * DBW_Render General Public License. A copy of this license is * * supposed to have been given to you along with DBW_Render so you * * can know your rights and responsibilities. It should be in a file * * named COPYING. Among other things, the copyright notice and this * * notice must be preserved on all copies. * ************************************************************************ * This update written by Ofer Licht 3/7/89 * * This document tries to explain the minor changes * * and modifications of the workings of DBW_Render v1.x * ************************************************************************ The modified DBW_Render will has been tested on sun3/50M's, sun4/280's and vax11/750's. I make no guarantees about it working on any other system, but it should PROBABLY work ok. The only files in ray_source that have been modified are ray.c ray.h fil.c The new "ray" has one minor bug fix: If the program can't open your xxx.dat script file, it will correctly display an error and exit. The new "ray" understands command-line specification of a scan line range. For example: ray glass.dat 100 140 will compute scanlines 100 to 140 and put the output in "glass100.tmp". In general, if you specify a command-line scanline range, the output file will have the begin-scanline number before the ".dat" extension. This was implemented to differentiate between output files of the same picture begin written to the same directory, possibly by a job distributed across the nework with distpro (see distpro.doc). If you want to set up your own naming conventions for input and out files look at the end of the source file "fil.c" The new "ray2" produces an ILBM picture file without using an amiga screen by mimiccing (sp?) the amiga bitmap structures in memory and using the standard run-length encoding algorithms. Therefore, "ray2" is now amiga-independent. Of course, to view the ILBM picture you need an amiga, unless you have implemented ILBM picture formats on your other machine. The new "ray2" also provides a pallete lock mechanism to be used for generating a set of pictures with the same pallete (for an animation). This feature is very primitive right now: For Example, say I have a series of tmp files named "frame00.tmp", "frame01.tmp", ... , "frame20.tmp" and suppose I think "frame06.tmp" represents the best "mean" of colors between all the frames. (How could I know this? Most of the time I guess; sometimes, I can make a prediction based on what I think the pictures should look like (this is especially the case when my animation has objects that are changing colors or moving from light to shade). Now I type "ray2 -po pal frame06" This processes frame06.tmp in the normal way and additionally outputs its colormap to the file "pal". To process "frame00.tmp" using the same pallete from frame06.ilbm type "ray2 -pi pal frame00". In a C-Shell you can do a "foreach" to do all the rest of the tmp files in the same way. I have tried to implement the '-pi' option by just reading the CMAP from any ilbm file, but I failed. So I went back to my pallete debugging code and that is the way the current version is implemented: the output pallete file is just a text file with lines of pen numbers ranging from 0-4095. If anyone succeeds with the other method, please let me know. I have not tried compiling the new "ray" or "ray2" on the amiga because I have no need for them on the amiga when I can run them on sun4's. They should, however, work on the amiga too. -Ofer Licht (ofer@gandalf.berkeley.edu) 1807 Addison St. #4 Berkeley, CA 94703 (415) 540-0266