cdshaw@alberta.UUCP (Chris Shaw) (04/26/87)
In article <804@elrond.CalComp.COM> amamaral(Alan Amaral) writes: >In article <1514@sphinx.uchicago.edu>, (david lee griffith) writes: >> 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! 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. >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. So leave off with this claim that "simple code is necessarily better, never mind the run time". >> ...ihnp4!gargoyle!sphinx!drco Dave Griffith >uucp: ...decvax!elrond!amamaral -- Chris Shaw cdshaw@alberta University of Alberta CatchPhrase: Bogus as HELL !
amamaral@elrond.UUCP (04/30/87)
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
upl@puff.WISC.EDU (Future Unix Gurus) (05/04/87)
In article <820@elrond.CalComp.COM> amamaral@elrond.CalComp.COM (Alan Amaral) writes: > >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... Come on, you're being facitious aren't you? A slight extension of your own argument defeats this point. IF I have a LONG way to go, then obviously there will be a break even point, after which the time to buy the Ferrari is LESS than the time to drive there with the volkswagon. In my original article (which started all this) I was talking about movie making techniques, I presume we still are. In such a case, the raytracer is the center of a HIGHLY reiterated set of loops. (24 frames/sec * 60 sec/miniute * however many minuits of footage you need.) This is the equivalent of a VERY long journey indeed. In such a case it CERTAINLY makes sense to spend time striving for effeciency! >> >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. >> But not fast enought to be of ANY use to me. (Honestly, however, I don't think it is POSSIBLE to ray trace fast enough on a 68000 for movies.) Jeff Kesselman upl@puff.cs.wisc.edu
amamaral@elrond.UUCP (05/06/87)
In article <750@puff.WISC.EDU>, upl@puff.WISC.EDU (Future Unix Gurus) writes: > In article <820@elrond.CalComp.COM> amamaral@elrond.CalComp.COM (Alan Amaral) writes: > > > >Look at it this way: Would you rather have a volkswagon that you can > > ... > >Me, I'll take the volkswagon. I've got places to go... > > Come on, you're being facitious aren't you? A slight extension of your own > argument defeats this point. IF I have a LONG way to go, then obviously > there will be a break even point, after which the time to buy the Ferrari > is LESS than the time to drive there with the volkswagon. Of course. I agree with you totally, but you have to agree that the break even point is NOT minimal. Of course if the Ferrari is limited to 55... :-) > In my original article (which started all this) I was talking about > movie making techniques, I Yes, I understand that todays computers aren't appropriate for rendering very high quality images (i.e. ray traced, rendering equation, radiosity, etc.) for movie purposes. Neither, for that matter, are todays storage media. A 100 minute fully rendered movie would consume (at 1kx1k) approximately 1.5x10^11 bytes, or 144 gigabytes. At 4kx4k which is a little more realistic that figure comes out to 2.4x10^12 bytes, or 2.3 TERAbytes. That's roughly 5053 RA81 drives!!! However, in the future (really the present if you look around a little) you will be able to buy a highly parallelized matrix processor that will render a ray traced scene in real time, or close enough to real time to be usefull. I say the present because there is company that sells a system with something like 300 transputers that will ray trace a simple 1kx1k scene in under 10 seconds. Ray tracing and the rendering equation both lend themselves quite elegantly and easily to this kind of solution. > >> >I'll just about guarantee that my ray tracer... > But not fast enought to be of ANY use to me. (Honestly, however, I don't think > it is POSSIBLE to ray trace fast enough on a 68000 for movies.) It also probably wasn't possible to play PACMAN on the ENIAC because it was too slow, but it's possible today on a jillion different computers that you can buy with pocket change. (Geez, you can buy a Timex/Sinclair for $15.00 and it would probably run rings around the ENIAC! What's this world coming to? ;-) ) As I have said on several occaisions, If you have the time and the CPU use ray tracing, if not, then use what you can. I never said that ray tracing is the be-all and end-all of computer graphics, just that it has it's place, and that I wish that people would stop bashing on it. > Jeff Kesselman -- 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