daniel@unmvax.unm.edu (Tommie Daniel) (05/27/89)
Has anyone converted the public domain ray trace program called DBW_render to run on a SUN workstation? If so would you be willing to send me a copy ? Thanks, Tommie Daniel daniel@unmvax.cs.unm.edu
cooper@uicbert.eecs.uic.edu (05/30/89)
/* Written 6:22 pm May 26, 1989 by daniel@unmvax.unm.edu in uicbert.eecs.uic.edu:comp.graphics */ /* ---------- "DBW_render for SUN 3 ?????" ---------- */ Has anyone converted the public domain ray trace program called DBW_render to run on a SUN workstation? If so would you be willing to send me a copy ? Thanks, Tommie Daniel daniel@unmvax.cs.unm.edu /* End of text from uicbert.eecs.uic.edu:comp.graphics */ I would also like a copy! - Wendy Cooper cooper@uicbert.eecs.uic.edu Z
tadguy@cs.odu.edu (Tad Guy) (06/03/89)
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 <ofer@gandalf.berkeley.edu> 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
dan@rna.UUCP (Dan Ts'o) (06/08/89)
In article <9029@xanth.cs.odu.edu>, writes: > 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 <ofer@gandalf.berkeley.edu> has done just that. His > modified DBW_Render is available via anonymous ftp from > xanth.cs.odu.edu as /amiga/dbw.zoo. I picked this program up and started playing with it. I don't claim to know much about it. However, it seemed designed for the Amiga (obviously) and only wanted to output 4bits per color. I decided I wanted a full 8-bits and started to probe into it. I don't know if the calculations are performed to at least 8 bit accuracy, although I'd be surprised if they weren't, so I just arranged to dump out more bits per color per pixel. In ray.h: #define BPP 4 /* Bits per pixel */ should be changed to #define BPP 8 /* Bits per pixel */ Unfortunately, this was not enough. It seems that some code in main() also assumes 4bits/color: In ray.c, line 458: modulo = (((modulo >> 2) + 1) % PPW) << 2; should be changed to something like i = 8 * sizeof (short); modulo = (modulo + (i/PPW))%i; Unfortunately, the code also seems to use 0xFF (decimal 255) as a marker for unknown pixels. But MAXGRAY-1 at 8bits is now also 255. The proper change would be to choose another marker such as 32768 (or eliminate markers). I punted and set MAXGRAY-1 to be 254: In ray.c, line 294: d_maxgray = (float) MAXGRAY; was changed to if (MAXGRAY == (0xFF + 1)) d_maxgray = (float) (MAXGRAY - 1); else d_maxgray = (float) MAXGRAY; Now it seems to produce 8-bit/color. Of course the format of the output file *.tmp is now different, having twice as many bytes. The difference in image quality is apparent, even on 8-bit FB's (not 24bit FB's) with dithering such that each color only gets 6 values. Must be the extra info to dither with. Cheers, Dan Ts'o 212-570-7671 Dept. Neurobiology dan@rna.rockefeller.edu Rockefeller Univ. ...cmcl2!rna!dan 1230 York Ave. rna!dan@nyu.edu NY, NY 10021 tso@rockefeller.arpa tso@rockvax.bitnet
dan@rna.UUCP (Dan Ts'o) (06/08/89)
In article <631@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: >In article <9029@xanth.cs.odu.edu>, writes: >> 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 <ofer@gandalf.berkeley.edu> has done just that. His >> modified DBW_Render is available via anonymous ftp from >> xanth.cs.odu.edu as /amiga/dbw.zoo. > > I picked this program up and started playing with it. I don't claim >to know much about it. However, it seemed designed for the Amiga (obviously) >and only wanted to output 4bits per color. I decided I wanted a full 8-bits >and started to probe into it. I don't know if the calculations are performed >to at least 8 bit accuracy, although I'd be surprised if they weren't, so >I just arranged to dump out more bits per color per pixel. Correct me if I'm wrong... it also seems to me that the code in ray.c packs bytes little endian style. Thus if run on a SUN3 or SUN4, pixels are reversed. But funny that no-one has noticed. Maybe their re-formatting program takes care of it. I punted on this one as well, and inserted: In file ray.c, line 464: #ifdef BIGENDIAN if (modulo == 0) { j = blueline[i]; blueline[i] <<= 8; blueline[i] |= (j >> 8)&0377; j = greenline[i]; greenline[i] <<= 8; greenline[i] |= (j >> 8)&0377; j = redline[i]; redline[i] <<= 8; redline[i] |= (j >> 8)&0377; } #endif if (didguess) cache[4][col][0] = 0xFF; A better fix would be to change the scan line buffers from (short) to (char) (why make them (short) ??). Also the scan line number is written out in native (short) and may need to be byte-swapped. BTW, does any have other interesting scene files for DBW_render ?