Path: utzoo!utgpu!attcan!uunet!super!udel!mmdf
From: kvancamp@ardec.arpa (Ken Van Camp)
Newsgroups: comp.sys.amiga
Subject: Re:  Sculpt-4D Upgrade
Message-ID: <4919@louie.udel.EDU>
Date: 17 Oct 88 16:39:49 GMT
Sender: mmdf@udel.EDU
Lines: 61

Stuart H. Ferguson writes:

 >The writer obviously doesn't shop around.  VideoScape 3D version 2.0,

Right - I spoke without thinking.  I have not checked out the new
versions of VideoScape and FIF.  I needed more fiber in my diet, anyway
(munch, munch :-).

 >I beg to differ.  Sculpt-3D's file format is not IFF, regardless of the
 >fact that it's composed of FORMs and chunks and things.  It is not an
 >"Interchange File Format" because it's not documented and therefore
 >cannot be used for data _interchange_.  For the same reason, Sculpt's
 >"movie" files are not ANIMs.

Well, I'm not going to stick foot in mouth again and get into an 
argument over IFF, but I'll just point out that the Sculpt-3D scene 
file format *is* documented.  I have a copy of the file format and so 
do hundreds of other people who sent for Grahams's Ray Tracing 
Newsletters.  I assume you are complaining because it was not officially 
registered with Commodore, in which case you are correct that it is 
not IFF.  But it is documented (correctly), and Interchange and my own 
software have demonstrated that the format is reliably readable and 
writable.  

Meanwhile, Peter da Silva (I spelled it right!) writes:

 >Sculpt is not a good example of a ray-tracer.
 >
 >Why not? Simple... it has only one object: a triangle.

If you want a ray tracer of the type you say Sculpt should be, check 
out C-Light.  It is limited to a small set of primitive solids, such 
as you are suggesting.  The results I have seen out of C-Light (based 
only on the 2 demo disks) are not nearly as impressive to me as 
Sculpt's results.  Why?  Because most real-world objects can simply 
not be broken down into cones, spheres, cylinders, cubes and derived 
solids.  C-Light's pictures look boxy and unrealistic, as the original 
Juggler did.  If you're going to write a solids modeler, you also have 
to include some kind of arbitrary polyhedron primitive to take care of 
things that just can't be rendered otherwise.  And then to make it 
powerful enough to handle complex objects, you have to offer boolean 
operations to handle all the special cases.  And in the end, your user 
interface is twice as complex (which doubles your code size, since 
let's face it user interface is 90% of the code anyway) and the 
results aren't any better.  As you say, though, rendering times can be 
reduced dramatically for simple objects like the peacock.  But the 
trend nowadays is toward greater realism in rendering -- what if 
somebody wanted to ray trace a real peacock?  (See this month's issue 
of IEEE CG&A for some surprisingly realistic ray tracings of natural 
objects.) For many complex objects that require arbitrary polyhedra, 
rendering times would increase, not decrease.  That's why I think Eric 
Graham went with triangles, and I think it was a valid tradeoff.  

OK, let the flames begin.  

                            --Ken Van Camp 
ARPANET:  kvancamp@ARDEC.ARPA   -or-   kvancamp@AC4.PICA.MIL
BITNET:   (use above through normal gateways, like UBVM.CC.BUFFALO.EDU)
USENET:   uunet!ardec.arpa!kvancamp@UUNET.UU.NET

                   "Tis better to Send than to Receive"