I don't know if this has been done before,
but I couldn't find any material on the topic, so...

(I think someone had made an OpenGL renderer
based on POV-Ray, but I'm not sure).

I'm currently investigating development of a
scanline renderer, because the scenes I need
to support (landscape scenes) typically contain
too many objects for efficient raytracing.

To save development time and effort, I've
looked at various existing programs. One of
these programs, of course, is POV-Ray, although
at first glance I didn't consider it because
POV is a raytracer.

However...

POV-Ray is also more. Unlike RIB, it implements
a scripting language, which is ideally suited
to the creation of large numbers of objects
without having to link in external code.
It supports a good set of primitives, and
handles animation. It does CSG. It has a large
texture library. Lots of people know, use,
and support POV-Ray. From the perspective
of specifying scenes, POV-Ray is robust.
For any renderer (regardless of how they render),
these "front-end" attributes are desirable.

I realize, of course, that certain effects
will not be directly supportable (e.g., true reflections,
refractions, shadows, etc.). However, that still
leaves a lot of cases where the objects I need
to draw look alright. There is also the possibility
of combining scanline and raytracing (more on that below).
The idea may even have merit purely on utility
grounds: previewing a scene could be done both
fairly well, with great speed, and conveniently
within the same program.

My next step is a test case whereby POV-Ray
is modified to support scanline rendering.
The approach is basically:

  - Initialize a z-buffer (POV's existing
    'hf_gray_16' keyword may already do this).

  - Skip the building of the bounding slabs
    hierarchy and any other data structures
    relating to the scene geometry database.

  - Route all primitive creation to the
    scanline renderer for immediate rasterization
    and z-buffer updating (some of the more
    exotic primitives may not be supportable).

  - Invoke the texturing code from the scanline's
    polygon rasterizer, providing it with
    whatever coordinates are necessary to
    handle texel lookup and perspective correction.

  - (In the future) Add other keywords to
    simplify the creation and use of shadowmaps and
    other entities required to support global
    effects in scanline systems.


Instead of forking POV-Ray, however, it shouldn't
be hard to add a mode keyword to the script language
so that rendering could be switched dynamically
between raytracing and scanlining. The raytracer,
however, would need to update the z-buffer so
that scanlined objects would be composited
properly into the output image.

I'm interested in knowing if anyone has already
tried this, what the challenges were, etc.


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

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

> I'm interested in knowing if anyone has already
> tried this, what the challenges were, etc.

You do realise that the changes your are talking about are several hundred
hours of work just to get started, not even to mention bringing them into a
"completely working" state?

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ray Gardener wrote:
> 
> [...]
> 
> I'm currently investigating development of a
> scanline renderer, because the scenes I need
> to support (landscape scenes) typically contain
> too many objects for efficient raytracing.

While reading your post this paragraph really made me laugh.  Without
doubt raytracing is far more efficient when rendering complex geometry
than a scanline renderer.  The reason scanline renderers are often
considered faster is not their suitability for complexity but the fact
that a lot of things (like shadows, reflections etc.) are calculated in
advance (when they are calculated at all).

Concerning landscapes - i have seen and rendered far more complex
landscapes with POV-Ray than you usually see being made with scanline
renderers.  I really wonder if you could show me a landscape render you
could say 'this would not have been possible in POV-Ray because of the
detailed geometry'.

And AFAIK there has not been a serious effort to implement scanline
rendering in POV-Ray.  Technically this will be next to impossible because
a lot of features of POV-Ray are not compatible to scanline rendering
techiques.  One try that has been made some time ago can be found on:

http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

> You do realise that the changes your are talking about are several hundred
> hours of work just to get started, not even to mention bringing them into
a
> "completely working" state?


That's definitely a good point.

I'm basically looking at it from a
"what does it ultimately cost to provide
the end solution" perspective. When I
consider my options, modifying POV-Ray
appears to be a good one. If there must
be considerable effort, then it should
be invested into something that returns
a strong multiplier effect.

I already have a simple scanline renderer
up and running inside my own product,
for example. I could just keep extending it.
However, to bring it to the same feature
level as POV-Ray in terms of scriptability,
support, and those other things I mentioned,
would take even longer. So even if modifying
POV takes effort, it's the lesser of
two evils, so to speak. I have to consider
all the time that will be saved as well.
I also have to keep in mind that if the
idea is popular with other people, then
the work will be divided amongst several
developers. If I do a separate project,
it is far less likely to receive the
help of others.

There are benefits even from implementing
minimal functionality. For example, even if
texturing is not engaged, a scanline system
can rapidly preview the geometric size,
position, and diffuse lighting of objects.
So it is possible to break the work into
rewarding milestones.

I think the difficulty of implementing
scanline renderers has been historically
overstated, looking at some older posts.
Although they're certainly not as
simple as raytracers, once one has a
working triangle rasterizer, the rest
is straightforward. If one wants a REYES
algorithm using primitive splitting,
that's certainly more work, but splits
are not mandatory. And a triangle rasterizer
itself is not difficult: it's just a matter
of bresenham'ing the projected vertices
into right and left edgelists, and then
iterating between the edges.

I think it brings a bright future to
POV-Ray, in terms of being used for
more work in the film industry, where
scanline solutions are necessary to
help meet deadlines. It also means
"the rest of us" would have access
to these tools. Scanline systems can
also exploit video card hardware,
making certain scenes even faster to render.

Ray

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> I'm currently investigating development of a
> scanline renderer, because the scenes I need
> to support (landscape scenes) typically contain
> too many objects for efficient raytracing.

  Could you profundize on this? What exactly is the difference between
scanline rendering and raytracing which makes the former better for
rendering a huge amount of objects?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   Could you profundize on this? What exactly is the difference between
> scanline rendering and raytracing which makes the former better for
> rendering a huge amount of objects?

This was answered well in Catmull et al's original
paper on REYES in SIGGRAPH 87, but I'll explain.

In a raytracer, all of the scene's geometry must
be retained in memory because secondary rays due
to reflection, refraction, shadows, etc. could
be aimed anywhere, thus random access to the geometry
database must be possible. Since memory is
getting more plentiful and cheaper, this is
not as big a deal as it was before, but for
scenes that approach reality, the hardware
is not quite there yet. The memory requirement
is also not a simple aggregate of the scene
objects; an octree or other bounding hierarchy
is needed to make searches take practical time,
and this adds considerable storage overhead.

In a scanline renderer, each object is considered
only once, so an object only exists in memory
while being drawn. POV-Ray is actually well-named;
it is indeed a "persistence" of vision. :)

There is also the "many textures" problem -- if you
want to use lots of different textures, they
must, like scene geometry, be preloaded in
a raytracer, because textures will be arbitrarily
accessed. Thus you get a lot of trashing as
textures are paged in and out. In a scanline
renderer, an object's texture is loaded and
used for all of the drawing of that object.
The artist can also arrange objects to be
provided in "texture order" so that each
texture is loaded only once.

There's also the accelerated video possiblity,
especially now that 3D cards are getting
so fast and cheap. In raytracing, one usually
adds more computers in a cluster or farm
(although this drives up one's electricity bill).

Ray

Post a reply to this message

> Concerning landscapes - i have seen and rendered far more complex
> landscapes with POV-Ray than you usually see being made with scanline
> renderers.  I really wonder if you could show me a landscape render you
> could say 'this would not have been possible in POV-Ray because of the
> detailed geometry'.

Fair enough. I submit the following picture:
http://www.daylongraphics.com/products/leveller/tour/ss_scanline.jpg

It contains almost 17 million triangles. The rocky lumps
in the foreground were drawn using a fractal cube geometry
insertion. The rest of the ground is done using fractal
displacement subdivision. There is no bumpmapping; every
lighting effect is done with actual geometry.

Not only would fitting that many triangles bog down
my PC, it is not even what I consider a large scene;
others have contained over a billion triangles.

The argument then is often "Oh, you could organize
your geometry better, or use bumpmaps". But as an artist,
I often find it's easier to create certain effects
by generating lots of geometry. And bumpmapping just
really isn't the equal of displacement shading, in the end.
To me, computers should be in the service of people,
to do things so that people can work the way they prefer.


> And AFAIK there has not been a serious effort to implement scanline
> rendering in POV-Ray.  Technically this will be next to impossible because
> a lot of features of POV-Ray are not compatible to scanline rendering
> techiques.  One try that has been made some time ago can be found on:
>
> http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

Thanks, I'll have a look.

I'm not worried about feature non-support
as much as whether the renderer is available at all.
The goal of supporting every primitive type,
every option, etc. is laudable but I see it
as something that can be grown towards.

Ray

Post a reply to this message

3eda7985@news.povray.org...
> Fair enough. I submit the following picture:
> http://www.daylongraphics.com/products/leveller/tour/ss_scanline.jpg

http://www.oyonale.com/ldc/english/dark.htm
370 millions of triangles, rendered on my laptop at 6000*8000 in a couple of
days, using radiosity.

Other complex pictures I've done recently are in that range (see also
http://www.oyonale.com/ldc/english/chevys.htm and
http://www.oyonale.com/ldc/english/family_night.htm ).

OK, to be fair, these images make a generous use of instanciation, as 370
millions of non instanciated triangles would certainly bog down my computer
so that doesn't invalidate what you said (I think the people of VRay claims
billions of non instanciated ones).  Still, in POV-Ray, a smart combination
of primitives and meshes can be extremely efficient. In fact, some of these
pics will be shown at the next SIGGRAPH by the people (XFrog) who have
created the plants used here.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Those are interesting pics (and very neat, too).

Your experience with complex scenes is
of great help in this discussion.

I'm curious as to what the memory usage
is like on your computer when rendering
these scenes, and how you would handle
getting previews of such scenes
(either stills or test animations)
and how long they would take.

I should also clarify that I'm not
necessarily beholden to scanline rendering
as the goal per se, but rather to just
find the best way to handle complex scenes
and achieve fast previews (and also to
shorten render times for scenes that
don't need global illumination effects).
I think getting fast animation previews
was the driving factor behind Renderman,
for example, because for any given
film scene one has to rehearse it
a few times.

When you say that your triangles are
non-instantiated, are you saying that
they are merely pointers to a master triangle?
If so, do I assume correctly that their
transforms are also in common (because
if they weren't, then each triangle would
have to store a 16 element matrix)?

Ray


"Gilles Tran" <git### [at] wanadoofr> wrote in message
news:3eda88ae@news.povray.org...

> 3eda7985@news.povray.org...
> > Fair enough. I submit the following picture:
> > http://www.daylongraphics.com/products/leveller/tour/ss_scanline.jpg
>
> http://www.oyonale.com/ldc/english/dark.htm
> 370 millions of triangles, rendered on my laptop at 6000*8000 in a couple
of
> days, using radiosity.
>
> Other complex pictures I've done recently are in that range (see also
> http://www.oyonale.com/ldc/english/chevys.htm and
> http://www.oyonale.com/ldc/english/family_night.htm ).
>
> OK, to be fair, these images make a generous use of instanciation, as 370
> millions of non instanciated triangles would certainly bog down my
computer
> so that doesn't invalidate what you said (I think the people of VRay
claims
> billions of non instanciated ones).  Still, in POV-Ray, a smart
combination
> of primitives and meshes can be extremely efficient. In fact, some of
these
> pics will be shown at the next SIGGRAPH by the people (XFrog) who have
> created the plants used here.
>
> G.
>
>
> --
> **********************
> http://www.oyonale.com
> **********************
> - Graphic experiments
> - POV-Ray and Poser computer images
> - Posters
>
>
>
>

Post a reply to this message

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

>>   Could you profundize on this? What exactly is the difference between
>> scanline rendering and raytracing which makes the former better for
>> rendering a huge amount of objects?
>
> This was answered well in Catmull et al's original
> paper on REYES in SIGGRAPH 87, but I'll explain.

You are talking about "The Reyes image rendering architecture", I guess?
And taking a four sentence paragraph that says little if anything to justify
your argument?  Lets see, well, I have to type this because the ACM digi lib
has this only scanned:

>>>
2.1. Geometric Locality.
When ray tracing arbitrary surfaces that reflect or refract, a ray in any
pixel on the screen might generate a secondary ray to any object in the
model. The object hit by the secondary ray can be determined quickly
[references omitted - trf], but that object must then be accessed from the
database. As models become more complex, the ability to access any part of
the model at any time becomes more expensive; model and texture paging can
dominate the rendering time. For this reason, we consider ray tracing
algorithms poorly suited for rendering extremely complex environments.
<<<

And this is all.  As you are aware that this was 16 years ago, a single
author's analysis, and the context of the paper is rendering feature-film
length animations?  I am not even going to start to reason here how
nonsensical it is to base your argument on this paper.

And the lengthy "argument" that follows in your post, well, you don't want
to keep the whole scene in memory and that is why you want to use a (even
"more" memory limited) 3d accelerator to draw that model?  Carefully
transmitting all the geometry and texture data over a rather slow bus for
every frame?  And as far as textures are concerned, you do know that number
of texture samples to be taken by a ray tracer grows linearly with the image
size, while for a scanline renderer is grows linearly with the polygon
number and size?

I am not going to laugh, I am surprised you didn't know better (also you
should), and I am just going to ignore the rest of this thread ... sorry!

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message