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:  Algrothm complexity
Message-ID: <820@elrond.CalComp.COM>
Date: Thu, 30-Apr-87 13:36:11 EDT
Article-I.D.: elrond.820
Posted: Thu Apr 30 13:36:11 1987
Date-Received: Fri, 1-May-87 06:36:23 EDT
References: <1514@sphinx.uchicago.edu> <804@elrond.CalComp.COM> <312@pembina.UUCP>
Organization: Calcomp, A Lockheed Company, Hudson, NH, USA
Lines: 106

In article <312@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes:
> In article <804@elrond.CalComp.COM> amamaral(Alan Amaral) writes:
> >In article <1514@sphinx.uchicago.edu>, (david lee griffith) writes:
> >> 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! 
> 
> Ok, I guess that since bubble sort is so simple & elegant, I should use
>it to sort random lists of things, no matter how long the list is, and how out 
> of order the list is. We wouldn't want to quicksort, a much better algorithm 
> for big (unsorted) lists, simply due to its complexity. Or something.

If you have a quicksort routine lying around you'd be foolish not to use
it. However, if you need to sort something quickly, and you don't have a
sort routine lying around waiting to be used, it only makes sense to me
that you should use whatever takes the least time to reinvent, and get
it over with.  I believe it would be easily shown that for onesie-twosie
kind of things the simplest algorithm to IMPLEMENT is the best, not the
most efficient. This is because you can spend more time implementing, fixing,
testing, and tweaking a program before you get it right than it would
have taken if you used the easiest/slowest algorithm available. This is
not to say that if you can anticipate doing something a large number of
times that you shouldn't try to optimize it as much as possible.  This
EVEN goes for ray tracers.

Case in point: I wrote the bulk of my ray tracer in less than 3 weeks,
part time, a couple of hours a day.  All totaled, I would estimate that
there are about 80 hours of real time invested in it.  It generates some
nice pictures given the investment.  Now, if you start today, and implement
the fastest, most efficent renderer that your heart desires, and get
back to me.  Oh, yes, It has to handle shadow casting, multiple light
sources, transparency, reflection, refraction, and all the other things
that the average ray tracer (including mine) does with ease.  I'll bet
that I can generate THOUSANDS of pictures before you get done.  Oh, and
while you're working on your renderer, I'll be implementing more features
in my ray trace, like motion blur, depth of field, gloss, translucency,
penumbras, caustics, etc. Then you can go back in put these into
yours...

Look at it this way: Would you rather have a volkswagon that you can
drive today, one that gets you where you want to go when you want to go
there, or, would you like to stay at home and go NOWHERE until you can
save enough for a Ferrari to get you where you want to go quickly?
Me, I'll take the volkswagon. I've got places to go...

You're rational could be used to say that because the volkswagon has no
chance of winning the Indy 500 it's useless as a car.  Nope, sorry.

> >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, 
>     [ ^^^^^ whatever that means]
> >AND do it with easily 1/10 to 1/50 of the code.
> 
> So what. There are two separate issues here, one is code correctness, the 
> other is running time. Correct pictures ~= correct code, fast pictures ~=
> better algorithm. The problem with computer graphics is that there is no
> really objective measure of performance, if people are interested in 
> performance at all.  Any number of NP Complete problems can be coded up and 
> made to work, but the obvious problem is the exponential running time.

When you get out into the real world and have to answer to someone other
than yourself, and you find out that not everyone is as idealistic as
you. You'll also find out that most people would rather have a correct
answer all of the time regardless of time rather than an instantaneous
semi-correct or worse yet, an incorrect answer.  If you disagree try
argueing the point with an engineer doing design on a building, a bridge,
the space shuttle, or your next car.

As I stated in my reply to Mr Griffith (which you failed to include, or
address), If you want GOOD PICTURES, use ray tracing. If you want fast
pictures USE SOMETHING ELSE, and stop complaining about ray tracing
being so slow.

> So leave off with this claim that "simple code is necessarily better, never 
> mind the run time".

It only takes me a few minutes cpu time on my 8600 to generate most of
the pictures that I work on, and I don't particularly GIVE A HOOT about
run time anyway. So don't you DARE to tell me what's important to me!
I'll take my nicely rendered ray traced pictures over NOTHING anyday.

> >> ...ihnp4!gargoyle!sphinx!drco				Dave Griffith
> >uucp:	 ...decvax!elrond!amamaral
> Chris Shaw    cdshaw@alberta

C'mon now. How many people out there (people, NOT Lucasfilm) have really
written working renderers that do everything (or even some of the things)
that a ray tracer can do easily (shadow casting, multiple light sources,
reflection, refraction, transparency, translucency, depth of field,
penumbras, motion blur, etc.)?  How many people out there drive
Ferraris? Volkswagons? (and how many of the Ferrari drivers drive them
because they LOOK good, rather than because they go fast.)

There is one point that I'd like to reiterate.  If you want realistic
pictures with all the things that ray tracing can give to you and you
aren't under a particularly tight time schedule, then use ray tracing.
If you don't have the time to wait for a ray tracer then you'll just have
to settle for what you can get.

-- 
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