In article <3edb6259@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> But, hmm... raytracing goes back 35 years.
> Bumpmapping goes back over 20 years.
> Who is it, um, who's using the older paper..?
<snip>
> and left it at that. Better still,
> you could have written or co-written a definitive
> paper on why scanline/REYES is non sequitor and included
> a reference to it in the FAQ.

Excuse me, since when is a whole research area (ray tracing) the same as a
single paper? -- If you just want to continue for the sake of argument,
fine.  I am not going to.

But who knows, maybe such a paper will one days surface, but I don't make
such promises...

> Despite faster hardware, raytracing
> still has difficulty providing realtime performance,
> even for simple scenes, while scanline systems
> do it routinely.

You have it exactly the wrong way.  Ray-tracing will be fast on *complex*
scenes while scanline methods will slow down.  I did actually explain it a
few weeks ago in a thread here somewhere.  Even a first year student knows
that an algorithm that performs very well on a small set of data does not
necessarily work well on a big set of data and vice versa!

> If REYES was doomed, I would imagine Pixar would have fired the Renderman
> staff once the hardware improved. But instead, it seems to have flourished in
> the film industry quite well.

Now, at what point did I say that their approach was slower than ray-tracing
today?

> he felt the matter was of low importance or misinformed

As said, anything said stays and thus undisputed statements are simply taken
for true and correct by many users.  Don't ask me why, it simply has
happened so often in the past <sigh>

> As for facts, I don't see that they have been concluded. Your first reaction
> was not to discuss technical feasibility at all;

Of course, this is povray.general, not povray.programming.  So I have to
assume you are the average user with a completely wrong mental model how ray
tracing works.  A short answer usually scares away non-programmers from
programming topics, which is good because otherwise one has to start
explaining really everything...

> just a statement that it would take a long time to implement. That sounds,
> frankly, more like someone who is afraid of change than someone with a clear
> set of reasons why an approach should not be tried.

Maybe it sounds more like someone who knows the source code of POV-Ray
better than you do?  usually those who work with the source code of a
program on a day to day basis know more about it than the casual observer?

> One would have expected your first reaction to be something along the lines of
> "Nice idea, but it won't work because of a, b, and c." or "That's fine, but
> the problem domain of POV-Ray is specifically x, y, and z."

If it wasn't the 100457th time somebody suggested the need or desire to have
or implement something like this, maybe...

> The facts I do know about are that scanline rendering has no geometry memory
> limit while raytracing does, and scanline rendering can deliver realtime (or
> at least much faster) scene previewing capabilities.

So, you say if you have a function for a geometry, you need to have all its
triangles to represent it in a ray tracer, while you need to only spill them
to the hardware 3d engine.  Your thinking is really very narrow if you think
this.  You fall into the same trap as many, many new users of POV-Ray do
when they want to solve a specific problem and fail:  They have a
preconceived solution in mind and manage to successfully ignore the one
million other ways to solve the problem.  In short: No need to keep the
geometry for ray tracing either.

> Even with all secondary raycasting disabled, a raytracer cannot outperform or
> match a scanline algorithm. If it could, raytracing would be used in video
> games. And the fact is, again, raytracing has not displaced scanline/REYES as
> the preferred CG rendering method in motion pictures. To quote Dr. Gritz, BMRT
> assisted in only 16 scenes in the movie A Bug's Life. I don't know what facts
> you are in possession of, but they certainly can't include the film industry
> falling all over themselves to use raytracing.

Few people have scene of the complexity to make ray tracing worthwhile.
Give me a billion (1000 million) triangles in a million objects, and ray
tracing will beat whatever scanline hardware you throw at the problem on an
average workstation.  Of course, ray tracing isn't limited to triangles...

> And on the topic of efficiency, why does POV-Ray allocate a memory block for
> not only each scanline and color channel of a texture? A simple scene using
> several 128-pixel tall textures wound up generating over 3000 calls to
> POV_MALLOC.

At most POV-Ray will have to touch all image maps together p * n * m times,
where p is the number of pixels in the 2d image, n is the maximum recursion
level and m is the number of image maps that cover the same object surface
(aka layered textures). If you optimise algorithms the way you suggest - all
I can say is that Knuth said something in this regard...

> Caching the row address multiplies into their own array I can
> understand, but why not just have them point to offsets within a single block
> for each texture component plane?

If you want to "optimise" POV-Ray on this level of detail, be my guest. I
neither can nor am I going to stop you!

> Anyway, I've started my modifications to POV-Ray to support the ideas
> mentioned so far, and will let interested persons know the results. In the
> interest of fairness to everyone, I think it is best if I try an
> implementation and let the facts speak for themselves. At the very least, it's
> an idea worth trying, given the potential benefits.

Goodbye!  Call be pessimistic, but I don't expect to ever see this being
even close to finished in a usable state.  Not the way you are approaching
it, anyway...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message