In article <3ee4e321$1@news.povray.org> , sascha 
<sas### [at] userssourceforgenet>  wrote:

> Then you explain how the raytracing algorithm could be optimized and
> compare it again with the (unoptimized!) scanline algorithm. Hmmm...

I knew somebody would ask, but answering it right along would have made a
long post even longer :-)

No, the problem is, you cannot optimise the scanline algorithm further than
what I outlined (at least not bringing down the complexity).  In fact, the
complexity I outlined holds for the first implementations 30 or so years ago
and it still holds in the 3d hardware accelerators of today.  The main
benefit of the scanline algorithm is that you can make the constant time
factor very, very small compared to ray-tracing.

> But couldn't the same (or other - e.g. octree) optimizations be applied
> to the scanline algorithm too?

No, because the scanline algorithm requires you to draw everything in the
viewing area to determine its visibility.  You can cull backfacing
triangles, but that only divides to constant factor by about two.

> Maybe I'm completely wrong, but doesn't your posting suggest that a
> raytracer will always outperform a scanline-renderer if just the number
> of objects is large enough?

Yes, it does.  The problem is, the one million to one difference of the
constant factors.  And due to the simplicity of the scanline algorithm, it
is, compared to ray-tracing, much easier to implement it in hardware (you
need only a few thousand gates, most of the logic on today's accelerator
chips is used for texture and geometry computations.

    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