a976@mindlink.UUCP (Ron Tarrant) (09/10/90)
> jean@pogo.hasler writes: > > Msg-ID: <1529@hslrswi.UUCP> > Posted: 10 Sep 90 05:54:05 GMT > > Org. : Ascom Hasler AG, CH-3000 Berne 14, Switzerland > > > The DKB (ray tracer) software is (slow but) great! I was even > able to compile it for my IBM compatible and happy to see that > the same .dis file was created. > > > When running DumpToIFF from data.dis to data.ham the picture > is displayed (so nice) but when writing to the diskette funny > things happen (sometimes with the L path access) with the system > which finally crashes with the famous GURU message. > The file data.ham has a zero size and the diskette is corrupted > (Diskdoctor message). > > It is really a pity because this package is so nice. But without > IFF conversion ....?!?!? I've run this program several times (about 10) on my A2500 with no problems. Perhaps (and this is just a guess) it was compiled to run on just the '020 by mistake before being packaged. Another possibility is that your stack wasn't set high enough. The docs mention setting a large stack for the actual ray tracer but nothing is said about what stack should be set for any of the utilities. Since Dump2IFF is dealing with 24bit files that are over 300k in size, it might need the extra stack. These are my suggestions, anyway. On the other hand, I was trying to re-compile Sculpt2DKB (using Lattice 5.05) and ran into some crashing problems when I finally got it to compile. During the compile phase, I found that several of the lines of code where missing the odd character, perhaps due to line noise, sloppy file handling during the 'splitting up and putting back together' step, (My fault completely in this case) or some other unknown factor. Has anyone else run into this problem? All in all, I'd say it's a great software package. My hat is off to DKB and AC (and the rest of the gang responsible) for a job well done. I've never seen CLOUDS in a commercial ray trace package! -Ron Tarrant a976@Mindlink.UUCP
jean@pogo.hasler (09/10/90)
The DKB (ray tracer) software is (slow but) great! I was even able to compile it for my IBM compatible and happy to see that the same .dis file was created. Unfortunately I could not manage to run DumpToIFF. I have an A500 with 1 MB and 2 floppies. I try with several types of Workbench diskettes and different setups but I always have the same result and NO IFF file available. When running DumpToIFF from data.dis to data.ham the picture is displayed (so nice) but when writing to the diskette funny things happen (sometimes with the L path access) with the system which finally crashes with the famous GURU message. The file data.ham has a zero size and the diskette is corrupted (Diskdoctor message). It is really a pity because this package is so nice. But without IFF conversion ....?!?!?
dbuck@ccs.carleton.ca (Dave Buck) (09/12/90)
In article <1529@hslrswi.UUCP> jean@pogo.UUCP () writes: > >The DKB (ray tracer) software is (slow but) great! I was even ^^^^^^ Thanks. >able to compile it for my IBM compatible and happy to see that >the same .dis file was created. Yup. It also works on various UNIX systems, Iris's, and even Cray's. >Unfortunately I could not manage to run DumpToIFF... >[stuff deleted] >When running DumpToIFF from data.dis to data.ham the picture >is displayed (so nice) but when writing to the diskette funny >things happen (sometimes with the L path access) with the system ^^^^^^^^^^^^^ Sorry? What are you referring to? >which finally crashes with the famous GURU message. >The file data.ham has a zero size and the diskette is corrupted >(Diskdoctor message). I haven't seen this problem with DumpToIFF. If you have an older version, that may cause problems, but if it came with the 2.01 distribution it's probably the right version. Since it displays the picture on the screen, all the hard stuff has already been done. At that point, the IFF write routines just take a snapshot of the screen. These IFF routines came originally from the versions found on Fish Disk 64 with one or two small mods. I haven't had them fail before. Two suggestions have been made by another poster. The first was that DumpToIFF may use the '881 - not likely since (if I'm not mistaken), DumpToIFF doesn't even use any floating point calculations. The other suggestion is a possibility - the stack is too small. That's probably the first thing you'd want to try. Try writing the IFF file to the RAM disk to see if it makes any difference. Also, if you are rendering at 320x400 (or higher) try rendering at 319x400. To simplify things in Ham, I kept the left border black, so you really only have 319 pixels across. I'd like to hear the outcome of this problem. Feel free to mail me directly at dbuck@ccs.carleton.ca. I'm more than happy to answer questions or problems with DKBTrace. Incidently, I'm putting a file on alfred.ccs.carleton.ca (134.117.1.1) called DKBBugs which summarizes all bug reports to date. That file should be up within a few days. David Buck dbuck@ccs.carleton.ca -- _____________________________________________________________________ | David Buck | My employer is not responsible for| | dbuck@ccs.carleton.ca | my opinions. I'm not even sure | | David_Buck@carleton.ca | I am. |
J-B.Boichat@hslrswi.UUCP (09/17/90)
In article <1529@hslrswi.UUCP> jean@pogo.UUCP () (ME) writes: > >The DKB (ray tracer) software is (slow but) great! ......... > >.......... I have an >A500 with 1 MB and 2 floppies. > >When running DumpToIFF from data.dis to data.ham ........... I could ONLY TWICE produce a data.ham (but great an usable in ^^^^^^^^^^ DigiPaint) with DumpToIFF on the simple1.dat file using a stack of 20.000 (for DumpToIFF) after a 'traceffp -w319 -h400' and later a stack of 300.000 (!!!) after a 'traceffp -w30 -h40' of the same simple1.dat file. I tried from CLI, from initial CLI without Workbench loaded and from Cshell (what I use normally for my work with zoo and messydos). The two successes were from CLI. Unfortunately there is NO WAY !!??!!?? to repeat the same operation (for instance from the CLI) with the same data (stack size, RAM: use for ham output, df1: for program (traceffp and DumpToIFF)!?!. This is very very strange!! It always crashes at the same place after the display of the picture: the power light starts to blink, the screen is then cleared (grey color) and the guru message (horrible!!) is output. I tried 20, 30 times, I cannot remember (very disappointed) and in most of the cases with the -w30 and -h40 (because fast). Did some other A500 1Mb users try DKB? What is the recommended stack size? ^^^^^^^^^^^ Some additional notes: 1) the stack size for traceffp does not seem to be important (works with 4000 bytes on simple1.dat) 2) if I use a stacksize too large (for instance 400 Kb, (500 was rejected on my system)) 'traceffp' hangs after the msg "Click to abort the picture [ABORT]" and I have to reboot (this one can be repeated) 3) if the file BasicShapes.data is not present the program 'taceffp' crashes ?!? (Better error handling and system resources check please!!!!!!) 4) DKB on a slow PC is not recommended (> 5 hours for simple1.dat on a 8086 8 Mhz machine) I will start today to compile it here on UNIX (SUN) 5) My next step (perhaps last?) is to work on a DumpToIFF for UNIX. Perhaps the author could help me by indicating how to bypass the Amiga functions especially the screen interface. 6) What is the format of the *.dis files? Is it something recognizable by Digiview (I will buy soon the package)? 7) How can I use the RGB files (I am still new on Amiga < 6 months). Thanks.
dean@coplex.UUCP (Dean Brooks) (09/18/90)
J-B.Boichat@hslrswi.UUCP writes: >In article <1529@hslrswi.UUCP> jean@pogo.UUCP () (ME) writes: >> >>The DKB (ray tracer) software is (slow but) great! ......... With respect to the source code, DKB is among one of the fastest public domain ray tracers I have seen... >Some additional notes: >4) DKB on a slow PC is not recommended > (> 5 hours for simple1.dat on a 8086 8 Mhz machine) > I will start today to compile it here on UNIX (SUN) Yeech... Ray tracing is slow on a 25MHZ 80386; can't imagine it on an XT. With proper use of the render-quality option "-q" (for previewing) and correct implementation of the BOUNDED_BY keyword, faster ray tracing can be achieved... >5) My next step (perhaps last?) is to work on a DumpToIFF > for UNIX. Perhaps the author could help me by indicating > how to bypass the Amiga functions especially the screen > interface. Definitely. We are runnnig DKB on our UNIX RISC station, and are dependent on FBM to produce our IFF files. Unfortunately, FBM doesn't produce as good results as Dump2IFF. Haven't looked into the reason, but will probably get to it one day (-; >6) What is the format of the *.dis files? Is it something > recognizable by Digiview (I will buy soon the package)? They are either in QRT (another raytracer format) format or in TARGA format. Both are basically 24bit RGB files. If you need conversion utilities, grab a copy of the Fuzzy Bitmap Manipulator package that was posted to comp.binaries.amiga a while back. It has all sorts of conversion utilities that allow you to convert QRT to IFF, HAM, Sun Raster, GIF and others. Also, utilities for color remapping, picture splicing etc. are included as well. -- dean@coplex.UUCP Dean A. Brooks Copper Electronics, Inc. Louisville, Ky UUCP: !uunet!coplex!dean
jerry@truevision.com (Jerry Thompson) (09/19/90)
Dean, if you could send me an image output from DKB, I could tell if it was in TGA (TARGA) format. Also, I would like to get a copy of FBM. Is that on a Fish disk? -- Jerry Thompson | // checks ___________ | "I'm into S&M, "What I want to know is, have | \\ // and | | | | Sarcasm and you ever seen Claude Rains?" | \X/ balances /_\ | /_\ | Mass Sarcasm."