Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!savax!elrond!amamaral
From: amamaral@elrond.UUCP
Newsgroups: comp.graphics
Subject: Re: AmigaWorld Ray-Tracing Article
Message-ID: <804@elrond.CalComp.COM>
Date: Thu, 23-Apr-87 14:44:45 EST
Article-I.D.: elrond.804
Posted: Thu Apr 23 14:44:45 1987
Date-Received: Sat, 25-Apr-87 05:35:09 EST
References: <1514@sphinx.uchicago.edu>
Organization: Calcomp, A Lockheed Company, Hudson, NH, USA
Lines: 102
Summary: It's no so unrealistic...

In article <1514@sphinx.uchicago.edu>, drco@sphinx.uchicago.edu (david lee griffith) writes:
> This is my first posting ever so please be patient.
> 
>      As written, the program will test for each pixel and each
> sphere in the universe whether the line from the observer to the
> patch of the perspective plane corresponding to the pixel intersects that 
> sphere.  With 50 - 100 spheres in the universe, and 320x400 pixels
> (or however many there are) that is a whole bunch of comparisons. 
> If each comparison requires two floating-point multiplications and
> a subtraction, no wonder the program takes so long!

Yes! It may be slow, but it's so very elegent and simple to program and
maintain that way.  That's one of the big reasons raytracing is SO
attractive in the first place! Most "conventional" graphics packages
that do hidden surface elimination are HORRENDOUS pieces of code with
all sorts of special case tests and bounds and such and usually can be
broken in several ways.  I'll just about guarantee that my ray tracer
that will render a correct picture 99.999% of the time, and look as
good or better than just about ANY "conventional" renderer, AND do it
with easily 1/10 to 1/50 of the code.

> Some sort of pre-
> processing (a simplified Z-buffering comes to mind) should be included
> so that only necessary comparisons are done and !!NO!! line-sphere 
> intersection tests should be done on pixels that turn out to be 
> background. Of course your programs are going to take hours if you use
> such brute force techniques as using ray-tracing to do hidden surface
> elimination.  

Z buffering is great if you only generate a ray tree one generation
deep, but if you do you shouldn't be doing ray tracing because you
would be ignoring most of the benefits of the technique.  As soon as
you start generating reflection and refraction rays you have to
regenerate your Z buffer from a new perspective, or more likely
just forget it.  This means that you've got code around that tests
what to do depending on how old the ray it is, and the Z buffering
adds another level of complexity that doesn't add at all to the picture
quality.  There are better ways of doing these kind of things in a
ray tracer, oct-trees for one, but they add incredibly to the complexity
of the program.

Also, in your last sentence you basically state that "ray tracing will
take a long time to do if you use ray tracing techniques".  I agree with
that. If you want ray tracing, use ray tracing. If you want fast use
something else.  Besides, slow is relative...

>      Other problems with the code are less obvious. Little things
> like the fact that the color of a mirrorred sphere is irrelevent
> (I want my jugglers to have golden balls to work with :-) ), and
> that if a bright red light reflects off of a shiny surface the 
> highlights turn out white. I won't even talk about the really 
> unrealistic model of specular reflection.  

Uh uh... Everything that I have read on reflection models, including
some of the more advanced ones, state that the color of a purely
specular reflection is the color of the LIGHT, NOT THE OBJECT!  Now
above you're describing apples and criticizing oranges.  You say that
the color of a mirrored SPHERE is irrelevent, and then talk about a
colored LIGHT...  Which is it? If the object is green and the light
is blue, the specular reflection is blue, NOT green, black, OR some
subtle mixing of the two.  There may be some diffuse reflection
that will bias the TOTAL color of the object, but that's another story.

The only problem with the highlights is that the lights are restricted to
WHITE. If instead of having "for(k=0; k<3; ++k) brite[k]=1.0;" he would
have used "for(k=0; k<3; ++k) brite[k]=color_of_light[k];" (assuming
the variable existed, etc...) that problem would be rectified.

My personal opinion is that if you have problems with the program FIX IT
and submit the fixes to the net.  It didn't cost more than the $3.95 that
you spent for the magazine so don't complain.  Mr Graham apparently spent
a good deal of his personal time creating it, and was nice enough to
submit it for publication so if you can't appreciate it for what it is
TOUGH.  GEEZ, I bet you complain when friends invite you for a free meal.
:-)

>      In short, what we have so nicely listed in the article is 
> some really slow and sloppily conceived code.

Have you ever tried to write a ray tracer?  Try it, then criticize.
You're right, it's not the best ray tracer that I've seen, but it's
relatively readable and understandable.  I bought the magazine at
lunch and was able to find the fix above in about 5 minutes.  If a
couple of people type it in and make some pretty pictures GREAT.
If not, it's no skin off my, or your, nose.

Again, slow is relative.  I believe it was Jim Kajiya, one of the
foremost authorities on computer graphics and raytracing, at the last
SIGGRAPH conference that said "Ray tracing is not slow, computers 
are slow. Some day someone will build a $99.00 zillion mflop machine
and EVERYONE will be doing ray tracing in real time."

I can't wait... ;-)

> ...ihnp4!gargoyle!sphinx!drco				Dave Griffith


-- 
uucp:	 ...decvax!elrond!amamaral		I would rather be a
phone:	 (603) 885-8075				fool than a king...
us mail: Calcomp/Sanders DPD (PTP2-2D01)
	 Hudson NH 	03051-0908