Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!cornell!batcomputer!saponara
From: saponara@batcomputer.tn.cornell.edu (John Saponara)
Newsgroups: comp.graphics
Subject: Re: Bug in Mark's RayTracer
Summary: Help build NFF (but not too much!)
Keywords: NFF
Message-ID: <6434@batcomputer.tn.cornell.edu>
Date: 30 Sep 88 13:54:14 GMT
References: <190@tachyon.UUCP>
Reply-To: saponara@tcgould.tn.cornell.edu (Eric Haines, actually)
Organization: 3D/Eye Inc
Lines: 30

In article <190@tachyon.UUCP> sch@tachyon.UUCP (Steve Holzworth) writes:
> [...bug in Mark VandeWettering's ray tracer...]
>
>Other than that, its a good raytracer.  Congrats, Mark!  I'm working on
>a better lighting model and a better camera model.  I'll send them on 
>when (if) I finish them.

I'm certainly interested in extending the lighting model (for starters,
positional vs. directional, cosine**power spotlighting, and cone angle cutoff,
not to mention the basics like light color).  Since NFF seems to be getting
used for more than just testing efficiency schemes, these seem important.

As far as a camera model, Mark was thinking about the idea of having a sort
of NFF++ format: uses NFF, but adds extra stuff (modeling matrices, for
example).  A preprocessor would convert NFF++ into NFF.  The idea is that NFF
itself is supposed to be as minimal as is possible, so that anyone can easily
read it in.  It's as raw as can be.  Having a more versatile and user-friendly
extended language is fine, but I want to keep NFF itself as simple as
possible.

Mark and I have been discussing how to define CSG primitives, and I have
been thinking about how to add splines with trimming curves.  Any advice
on these or other extensions you all may have is highly appreciated.  I hope
to write up a quick description of the NFF format today (Renderman it ain't),
and will probably post it this afternoon.

Eric Haines (not John Saponara)

This `saponara' account is going away - please write to me at:
	hpfcla!hpfcrs!eye!erich@hplabs.hp.com