POV-Ray : Newsgroups : povray.newusers : Scanline rendering? : Re: Scanline rendering? Server Time
5 Sep 2024 16:18:38 EDT (-0400)
  Re: Scanline rendering?  
From: Warp
Date: 28 Jan 2001 10:22:00
Message: <3a743918@news.povray.org>
Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: As is the list of possible features for raytracing. Povray isn't a
: trivial program either.

  My point was that making a simple raytracer, with some minimal features,
is quite easy. Making a working scanline renderer with the same minimal
features is a lot harder.

  Hidden surface removal? In raytracing you get a perfect result with
minimal coding. To get a perfect result (that is, works perfectly with
every possible combination of polygons) with scanline rendering needs quite
a lot of work.
  Lighting? Also easy in raytracing (at least if you use mathematical
objects). With scanline rendering you need complicated algorithms to
interpolate perspective-correctly normal vectors.
  Textures? Very easy in raytracing (for procedural textures it couldn't
be easier; for texture images it certainly needs more work if you want
things like bilinear filtering). In scanline rendering you need at least
perspective correctness calculations (which you don't need in raytracing).
  Shadows? Laughably easy in raytracing. A headache in scanline rendering.
  Reflections and refractions? As with shadows.

: I found my old zbuffer demo on a backup tape. It is about 400 lines of
: C code, about half of which is the z buffer algorithm and half is the
: application (open an X11 window, tesselate a sphere and a cylinder,
: render both using the Z buffer and draw them into the window). Written
: in a single afternoon, if I rememer correctly.

  Does it calculate the depth right? You have to take into account
perspective correctness if you want it to work right with intersecting
polygons and polygons which are very close to each other (almost coincident).
  I know it's easy to do it the easy way, just interpolating linearly the
depth between vertices. This, however, doesn't work perfectly.

  And besides, the amount of code lines doesn't tell much. One could work
a week in 50 lines of code if the algorithm to implement is hard enough.

: BTW, does anyone know where the name "scanline rendering" comes from?
: It is quite wrong. Unlike raytracing (which does generally follow
: the scanlines), these rendering algorithms do not create the picture
: scanline by scanline, but polygon by polygon.

  You are not completely right.
  You can draw the image polygon by polygon, and that's the easiest way.
However, it's not the most efficient way. The most efficient way is to draw the
whole image scanline by scanline, drawing only those parts of each polygon
which is visible (that is, gets into the final image). If you draw polygon
by polygon, you will be drawing a lot of extra data which will not get into
the final image, thus spending a lot of time in parts which do not affect
the image.
  If my memory doesn't fail me, most scanline renderers (such as 3DStudio)
render scanline by scanline, for this exact reason.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.