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

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
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...
> "Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
> 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

> 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? ...

> 2.1. Geometric Locality.
>...
>
> 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!


I suppose ignorance is bliss...

Well, I'm not sure there's any need to employ
derogatory remarks in this discussion or insinuate
that my intelligence is lower than it should be.
It sounds like you're threatened or uncomfortable
about something. Don't worry; I'm not asking
the POV-Team to do anything. Scanlining is just
one way to accomplish some goals; I'm open to
any idea that will do the same. I'm also surprised
because I'm not asking the raytracing system
to be replaced. Far from it, actually.

Raytracing is certainly elegant. It certainly
produces stunning imagery. But if raytracing is
the solution for production rendering needs,
then it would likely be used by all the studios
already. But the fact is, it's not. The current trend
is to hybridize the two.

If POV-Ray is characterized as a raytracer,
then yes, changing or augmenting its raytracing
system is to change the entire mission statement.
But I think POV-Ray is also seen by some people
as an image/movie creation platform, where the
particulars of image rendering are merely
an implementation detail. Did people get
uncomfortable when Larry Gritz wrote BMRT and
showed that RIB files could be raytraced? No;
they saw that the Renderman system could be
extended to more uses with raytracing. The
initial scanline architecture was treated as
a plumbing detail, not something to get
religious about (the RIB spec even includes
a trace() function, although of course PRMan
doesn't implement it). I think POV-Ray can be seen
in the same manner (but in reverse, of course).

Your points are important but memory bus bandwidth
is not a factor. A CPU has to access memory over that bus
whether raytracing or scanlining, because the scene geometry
simply doesn't fit either way into a data cache. In fact,
with raytracing it's sometimes worse, because the data
for an object can be paged out of the data cache when
a secondary ray hits another object, whereas when scanlining,
the object can remain in cache; memory accesses are not
spread out all over the geometry database.

As for scaling up texture access, a scanline
system can store z-buffer entries to do
texturing in a seperate pass, so only
those pixels that are actually visible
need to be textured. When I make a Z entry,
I can store the surface normal, uv coords,
and texture ID and do the texturing later.
The approaches can even be mixed depending
on what makes more efficient resource use
at the time.

It's also not a point that throws the baby out
with the bathwater. If I want a realtime animation
preview of a moderate POV scene, for example,
scanlining will do it. There are worthwhile
things to gain even if a technology has some faults.


Ray

Post a reply to this message

Ray Gardener wrote:
> 
> > 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.

In your sample the foreground shows not much more than pure noise - no way
to determine the exact geometry.  This noise could easily be done in
POV-Ray though.  The background seems easy to accomplish in POV-Ray as
well, at least similarly.  If you want exactly the same you would have to
implement the used function in POV-Ray.  The whole thing without shadows,
textures and other slow stuff - it is well possible that POV-Ray could
beat the 12 minutes on it.

17 million triangles would of course need quite some memory in POV-Ray as
a mesh but luckily there are other possibilities to generate geometry in
POV-Ray as well...

As an example - this scene was made in 1999 - at a time when most
landscape renders were commonly using no more than 1-2 million triangles:

http://www-public.tu-bs.de:8080/~y0013390/pov/pict/iso_rock_01.jpg

Although this scene was never designed to render fast - in fact by nature
it was quite slow - it renders with plain texture, no aa and no shadows
within 7min44sec (640x480, Athlon 1GHz). Memory use 214k BTW.

http://www.schunter.etc.tu-bs.de/~chris/files/iso_rock_02b.png

The geometry is equivalent to far more than 17 million triangles, of
course you can't really see it at this size.

> [...]
> 
> 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.

You are free to implement such a thing but be warned: there will hardly
anyone be interested in a POV-Ray feature for scanline rendering that only
supports certain specific geometry definitions that are not compatible to
raytracing and therefore are not usable in a 'real' POV-Ray render.

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

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

> Well, I'm not sure there's any need to employ
> derogatory remarks in this discussion or insinuate
> that my intelligence is lower than it should be.
> It sounds like you're threatened or uncomfortable
> about something.

Yes, the fact that someone uses a 16 year old paper that used a CCI 6/32 as
basis does indeed make me uncomfortable seriously question this persons
ability to evaluate "facts" before reaching any conclusion. -- For those not
aware, this system delivers proximately the same computing power as a 4 Mhz
(yes, four Megahertz!) Pentium 4, or in the standard of the time, about six
MIPS (peak) or around a rating of five on the Specmark 89 scale, which is
slightly better than a 386 with FPU or less than half that of a SPARCstation
4/60 (Sparc 1).

(from another of your posts)
> Fair enough. I submit the following picture:
> http://www.daylongraphics.com/products/leveller/tour/ss_scanline.jpg

Lets see, you have an image that has about 275000 pixels, and you render
16.8 million triangles, that yields about 61 triangles per pixel.  More,
actually, somewhere around 70 triangles per pixel, because some part of the
image is the sky.  This suggests very ineffective or nonexistent clipping
and culling algorithms.  I have hardly ever seen a scene with more than one
million triangles that, after clipping and culling well before (!!!) getting
down to a triangle level, reached more than 10 triangles per pixel.  in
short, on any computer you could have bought in the last two years this
should render in a few seconds using scanline rendering.

16 million triangles is peanuts, nothing else, compared to properly clipped
and culled datasets that created (and still create, of course) very good
results when used with POV-Ray even several years ago:
<http://astronomy.swin.edu.au/~pbourke/terrain/mars32/>

> I suppose ignorance is bliss...

No, just a necessity because if I would spend as much time explaining
details every time somebody comes up with completely unresearched,
misinterpreted or just plain random "facts", I would hardly find time to do
anything else.  Yet, few of the users in these groups care (or need to know,
your response to Gilles reply is a good example, but that takes to long to
explain here why) enough about the technical reasons that so clearly show
why your "facts" are plain wrong.  One problem with newsgroups is that false
"facts" tend to come up weeks later when somebody simply accepted everything
that went unchallenged as true "fact".  Especially if that person appears to
have knowledge about the topic being discussed.

In short:

***
I consider it a matter of courtesy, especially in any non-verbal discussion
where writing the reply takes longer than anything else, that people *first*
find out what they are going to talk in a responsible manner about and
*then* speak up rather than depend on others to do the thinking for them.
***

(Rhetorical question)
Now that I wasted over 50 minutes of my time on this, are you happy? :-(

    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" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3eda8ea4$1@news.povray.org...
> Those are interesting pics (and very neat, too).
Thanks!

> 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.

Meshes in POV-Ray have two major benefits:
1) they can be instanciated, i.e. the first copy of the mesh is the only one
that counts. The other copies can be rotated, translated, scaled etc. and
only add the price of the pointer (if I'm telling nonsense, people who
really know the code will correct me). A tree mesh of 100Mb (mesh2) can be
used once or 4000 times with a minimal difference in memory cost. I didn't
record the total RAM use for the but it was well below the 1Gb I have, and,
as I said, these scenes all use radiosity (and other things than meshes).
Without any additional elements, the 4000-tree scene will use the RAM of the
initial tree + 4000 pointers.

2) they render extremely fast

As this applies too to height-fields (static or generated on the fly), the
consequences in terms of landscape generation are huge. A single
height-field tiled properly and 5 different trees can generate an entire
forest, quickly, and within the memory cost of the initial elements (see the
page here for examples (with code) of on-the-fly large height-fields, tiled
or not. http://www.oyonale.com/ressources/english/sources13.htm).
Actually the main limitation of scenes with large meshes and height-fields
is not the render time but the parsing time, as a 100mb meshes need to be
read anyway. To speed up things during tests, I often use dummy props
(simple primitives or low-poly meshes) and low-res height-fields (which can
be done in the code if they're function-based).

The Forester page (http://www.dartnall.f9.co.uk/) has impressive animations
of big POV-Ray generated landscapes, btw. Perhaps he has more insight about
how he did those (render times, memory cost etc.).

This doesn't mean of course that an hybrid engine wouldn't be interesting...

>and also to shorten render times for scenes that
>don't need global illumination effects.
Do such scenes really exist ;-)

Gilles

--

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

Post a reply to this message

> Yes, the fact that someone uses a 16 year old paper that used a CCI
6/32...

But, hmm... raytracing goes back 35 years.
Bumpmapping goes back over 20 years.
Who is it, um, who's using the older paper..?

And I suppose the machine was rather slow, but that
would have been true for a raytracer running
on it as well. I don't see the fairness in
blaming an algorithm on the hardware available
at the time. Despite faster hardware, raytracing
still has difficulty providing realtime performance,
even for simple scenes, while scanline systems
do it routinely. 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.


> Lets see, you have an image that has about 275000 pixels, and you render
> 16.8 million triangles, that yields about 61 triangles per pixel.

Actually, the image is antialiased by drawing a 200% version
of the image and then averaging it down, so there are over a million pixels
originally. Yes, it's a lot of triangles, because the fractal cubes
insert themselves after the heightfield shader draws, and a lot of
the latter pixels get replaced in the z-buffer.


> This suggests very ineffective or nonexistent clipping
> and culling algorithms.

Well, that's the nice thing about a z-buffer. I do perform
frustum and backface culling, but being able to insert
geometry and not worry about memory is useful in terms
of artistic approaches, especially in shader development.
Production runs would be optimized, but it's nice to know
that during development, I'm free to use brute-force
techniques that send any number of polygons. In a
raytracer, that luxury doesn't exist; there's always
a memory limit on geometry. Even if you have the time
to render it, if you don't have the memory, you're stuck.
And the memory I save on geometry I can put towards textures
and shaders.

Let me put it this way: I could have spent more time
optimizing the textures to get them to raytrace well.
But instead, I'm free to brute-force the approach and
also have a general solution that works from other
camera angles (customized textures tend not to).
It's a good system that can offer design-time efficiency
in addition to runtime efficiency. It's good to
have choices. In fact, the scanline system lets me
easily develop textures for the raytracer.


>in short, on any computer you could have bought in the last two years this
> should render in a few seconds using scanline rendering.

I do have some scenes which, in fact, render in only
several seconds. If I omit the fractal cubes, the thing
really rips along. This is also my first attempt at
such a renderer, only a week old or so, so I'm not
claiming it's optimized.


> > I suppose ignorance is bliss...
>
> No, just a necessity because if I would spend as much time explaining
> details every time somebody comes up with completely unresearched,
> misinterpreted or just plain random "facts", I would hardly find time to
do
> anything else.

Well, no one forced you to spend your time
participating in this discussion, so don't
blame me if you feel your time is wasted. A true
professional would simply have stated that
he felt the matter was of low importance
or misinformed 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.

As for facts, I don't see that they have
been concluded. Your first reaction was
not to discuss technical feasibility at all;
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. 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."

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. 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.

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. 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?

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.

Ray

Post a reply to this message

> You are free to implement such a thing but be warned: there will hardly
> anyone be interested in a POV-Ray feature for scanline rendering that only
> supports certain specific geometry definitions that are not compatible to
> raytracing and therefore are not usable in a 'real' POV-Ray render.

I didn't plan on supporting any scanline-only
primitives, if that's what you meant. My prototype
will support a subset of existing POV primitives,
so that whatever the scanline system can render,
the raytracer can render.

In that spirit, however, I agree that there
will be those who will not use a renderer that
cannot reproduce all of POV-Ray's existing
effects (i.e., true drop-in renderer substitution).
This is understandable for those who have
existing scene files and are looking to improve
render times on them in their final rendered sense.
Improving the existing raytracer provides more
return for that audience.

The first benefit, I think, will be in previewing.
Unlike VOP, my previews will be integrated directly
into WinPOV's render window and be available
by simply choosing a menu command. The preview
will render during parsing, so best case, a scene
could render in as much time as it takes to parse.
A camera object will, however, need to be
defined ahead of all other objects. I could preflight
the .pov file looking for the last camera statement,
but that would lengthen parsing times.

Shaders for the scanline system pose a greater
raytracer-compatability challenge (although BMRT
proves it can be met). I'm personally interested
in deploying shaders as DLLs, for performance
reasons, but that would understandably be a
philosophical departure for POV-Ray.

Ray

Post a reply to this message

On Mon, 2 Jun 2003 08:00:51 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> I could preflight
> the .pov file looking for the last camera statement,
> but that would lengthen parsing times.


Are you aware that:

  #macro C()camera#end
  #declare c=C(){}
  C(){c}

is valid for parser ? The same applies to:

  #include "strings.inc"
  Parse_String("camera{}")

Are you sure it isn't simpler to you to write completly new application ?

ABX

Post a reply to this message

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

> Are you aware that:
>
>   #macro C()camera#end
>   #declare c=C(){}
>   C(){c}
>
> is valid for parser ? The same applies to:
>
>   #include "strings.inc"
>   Parse_String("camera{}")
>
> Are you sure it isn't simpler to you to write completly new application ?


I have considered that. I was about to write
or modify a RIB renderer, for example.
But I wasn't aware of the camera statement
flexibility per se; thanks. If the POV-Team
didn't mind me copying their parser code,
the argument for doing a new app would
certainly be better advanced. POV also
has all the other infrastructure, such
as texture file loading, in one nice spot.

I believe POV's future lies in being
a more powerful platform for creating
3D graphics in general, not just as
a raytracer. For all I know, this experiment
may one day lead to POV-Ray becoming the dominant
film production tool for CG effects, and enable
a whole new population of movie producers.

VOP already went the "new application" route.
The problem is, its .pov parser is now out of date
and cannot handle many scene files.

For now, I'll probably just require that a
camera be defined up front. It's not a
huge requirement at this stage, and many
people tend to declare cameras early.
If a cam is missing, I could also have
the preview window make its own, which
the person could relocate with the mouse.
Hmm... if it copied the cam data to the
clipboard in .pov format, that would be
an interesting take on NavCam. It would
certainly make defining cameras as easy
as point and click. :)


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"

Post a reply to this message

Ray Gardener wrote:
> 
> I didn't plan on supporting any scanline-only
> primitives, if that's what you meant. My prototype
> will support a subset of existing POV primitives,
> so that whatever the scanline system can render,
> the raytracer can render.

Quoting from your original post:

> 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.

Sorry but i simply don't get it.  Your original motivation for considering
implementing scanline rendering in POV-Ray is to allow something that is
not possible in POV-Ray as you state (i.e. efficient rendering of scenes
with many objects).  But now you write you will only support a subset of
those shapes already available in POV-Ray - how does this fit together?

I think this whole thread suffers from one serious problem - You never
made a clear and open statement of your objectives and you don't seem to
be willing to discuss whether your idea for a solution (i.e. scanline
rendering) will meet your objectives.  All people who replied to you in
this thread have a good deal of experience with POV-Ray in various fields
but i have the impression that you either ignore or don't understand most
of the arguments we have given.

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

In article <3EDB7CED.99BA1222@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Sorry but i simply don't get it.  Your original motivation for considering
> implementing scanline rendering in POV-Ray is to allow something that is
> not possible in POV-Ray as you state (i.e. efficient rendering of scenes
> with many objects).  But now you write you will only support a subset of
> those shapes already available in POV-Ray - how does this fit together?

I also don't understand yet why a scanline render mode should be added to
POV-Ray for the stated purpose and yet the same person shows an example made
with a scanline renderer.  But hey, I don't think we are supposed to
understand :-(

    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

> Sorry but i simply don't get it.  Your original motivation for considering
> implementing scanline rendering in POV-Ray is to allow something that is
> not possible in POV-Ray as you state (i.e. efficient rendering of scenes
> with many objects).  But now you write you will only support a subset of
> those shapes already available in POV-Ray - how does this fit together?

Sorry for the confusion. For my purposes,
I don't require all primitives, at least in
the short to mid-term. Further along, it
would be desirable to have as many POV
primitives supported as possible. I need
the "lots of shapes" capability to implement
shaders, and most of the time they get
by with simple primitives like triangles,
boxes, spheres, etc. This is natural since
the shapes tend to occupy a fairly small
number of screen pixels when projected.
For shapes like hair strands and grass blades,
however, supporting a spline (rope?) primitive
should be done.


> I think this whole thread suffers from one serious problem - You never
> made a clear and open statement of your objectives and you don't seem to
> be willing to discuss whether your idea for a solution (i.e. scanline
> rendering) will meet your objectives.  All people who replied to you in
> this thread have a good deal of experience with POV-Ray in various fields
> but i have the impression that you either ignore or don't understand most
> of the arguments we have given.

I'm pretty sure I stated I was open to
any ideas to meet the goal, but I admit
there was some sidetracking into that
talk with Mr. Froehlich about the
merits of scanline vs. raytracing.
I should have tried harder to stay on course.

Your isosurface pictures are neat. I don't
know if I mentioned that my pic was antialiased
(over a million sampled screen pixels)
and done on a 633Mhz Celeron. But regardless
of how close in performance the two are,
I'm not much of an isosurface designer.
I also don't see how an isosurface would
be able to plant lots of trees or independant
rocks on the terrain and maintain the
same memory/rendering performance. If I
was limited to raytracing, I would definitely
brush up on isosurfaces, but otherwise...

Like I mentioned, I think I have to try
a prototype scanline implementation in POV to
see how it goes. The jury is kind of out
on conclusions just yet, and I don't
want to endorse anything until I have
accurate benchmarks. By Mr. Froehlich's
own admission, raytracing speed doesn't
compete with scanlining until you have
billions of objects, so there's definitely
room for exploration under that limit.

Ray

Post a reply to this message

On Mon, 2 Jun 2003 10:53:44 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> I also don't see how an isosurface would
> be able to plant lots of trees or independant
> rocks on the terrain and maintain the
> same memory/rendering performance.

With trace? 
http://www.irtc.org/ftp/pub/stills/2002-02-28/tmworld.jpg

ABX

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> wrote in
news:3edb8f1d@news.povray.org: 

>> I think this whole thread suffers from one serious problem - You
>> never made a clear and open statement of your objectives 

> 
> I'm pretty sure I stated I was open to
> any ideas to meet the goal, 


So what is your goal?  Quick previews of movies in POV-Ray?

Post a reply to this message

Hi Ray Gardener, you recently wrote in povray.general:

> 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 would be a great feature to have in POV-Ray, be it simply
for 3D hardware supported previewing :-) So, I would definitely
support any undertaking you do.

And I know you have a good grip on the depth of the task, but I would
like to reply to the above quoted paragraph that it is not quite that
simple, at least as far as POV-Rays primary modelling paradigm (CSG)
is concerned. It is extremely hard to tesselate (triangulate) an
arbitrary CSG object. I have seen OpenGL code that renders CSGs using
stencil buffers and such, but I'm not sure if that actually works for
complex, nested CSG objects made out of more than just a couple of
boxes and speheres.
I evaluated a lot of the same things when thinking about how to
display a scene in Moray....

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

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

> By Mr. Froehlich's own admission, raytracing speed doesn't compete with
> scanlining until you have billions of objects, so there's definitely room for
> exploration under that limit.

That is not what I said!  We were talking about video game realtime usage
using triangles.  And some fuzzy argument about the film industry that you
mentioned.

You wrote:
>> 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.
And I replied:
> 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...

As you notice, I am very explicitly talking about a scene with triangles!
Not "objects", and there is a ***very*** big difference between objects and
triangles.

And apart from that, what good is shooting primary rays only?  Not useful
for anything but previews.  And it looks like a preview you already have...

    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

in news:as7ndvkenr4ku0uienvc66tu2jmckhvcol@4ax.com Lutz Kretzschmar wrote:

> It is extremely hard to tesselate (triangulate) an
> arbitrary CSG object.

Just for my understanding; Everytime I see a statement simular to this I 
wonder, does it mean building a CSG from POV-Ray primitives and then 
tesselate it, or tesselate the "POV-Ray primitives" to a certain level and 
then do the CSG (as I saw it in a very old version of 3D-studio)?

Ingo

Post a reply to this message

> > By Mr. Froehlich's own admission, raytracing speed doesn't compete with
> > scanlining until you have billions of objects, so there's definitely
room for
> > exploration under that limit.
>
> That is not what I said!  We were talking about video game realtime usage
> using triangles.  And some fuzzy argument about the film industry that you
> mentioned.

I stand corrected. A billion triangles, then.
I would imagine there's also room for exploration
under that limit.

Ray

Post a reply to this message

> I think it would be a great feature to have in POV-Ray, be it simply
> for 3D hardware supported previewing :-) So, I would definitely
> support any undertaking you do.

Thanks, I appreciate that.

> And I know you have a good grip on the depth of the task, but I would
> like to reply to the above quoted paragraph that it is not quite that
> simple, at least as far as POV-Rays primary modelling paradigm (CSG)
> is concerned. It is extremely hard to tesselate (triangulate) an
> arbitrary CSG object. I have seen OpenGL code that renders CSGs using
> stencil buffers and such, but I'm not sure if that actually works for
> complex, nested CSG objects made out of more than just a couple of
> boxes and speheres.
> I evaluated a lot of the same things when thinking about how to
> display a scene in Moray....

Well, CSG is undoubtedly a challenge.
As long as "extremely hard" doesn't
wind up becoming "intractable" I'm
willing to forge ahead. In the reverse
direction, I would love to see Moray
display POV CSG objects.

In REYES, which tesselates down to
micropolygons, one can consider the
3D location of the polygon to be
inside or outside another primitive, and
thus cull it at render time. So all the
primitives comprising the CSG object
need to be in memory (not a heavy requirement)
and they must be iterated and volume tested
during micropolygon rendering (possibly heavy).

That also suggests a brute force solution
to obtaining triangle meshes from a CSG object:
Tesselate to micropolygons, insert the visible
polys as points into a 3D point cloud, and
then convert the point cloud into a mesh.

Ray

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> 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.

  There are several things here which are not completely accurate.

  The reason given above about why all geometry needs to be retained
on memory is related exactly to what raytracing can do *more* than
scanline-rendering (ie. reflections, refractions and shadow-testing).
  There's nothing in raytracing that *forces* you to use these extra
features. If it's enough to get the same result as you would get with
scanline-rendering, you can use simple raycasting (ie. don't calculate
any reflected nor refracted rays) without shadows. This way the necessity
of having all the objects in memory at once is removed in the exact same
way as in scanline-rendering.
  (If you want to use scanline-type reflections and shadows, there's nothing
in raytracing which would not allow using the same techniques.)

  Of course one would ask: If the result is the same as with
scanline-rendering, then why don't do it with scanline-rendering?
  There are two reasons:
  1. It's a lot simpler. Rendering and texturing a mesh is a lot simpler
with a raytracing algorithm than with a scanline-rendering algorithm.
  2. With very complex meshes raytracing can be even faster (because
triangles which are not visible are automatically skipped due to
octree optimizations).

  Also, even if full raytracing done, keeping the whole scene geometry
in memory at once is not strictly necessary.
  If the bounding box of a mesh object is never hit, there's no reason
to even load that mesh into memory. It should be possible to develop
a load-at-demand scheme, where meshes are loaded only when needed. It
could also be a cache scheme, where meshes which have not been hit in
longest time can be freed from memory.

> In a scanline renderer, each object is considered
> only once, so an object only exists in memory
> while being drawn.

  This has the drawback that if a hundred triangles cover a certain
pixel, that pixel is recalculated a hundred times (including texturing
and lighting).
  In raytracing the closest intersection point for the pixel is
calculated and then texturing and lighting is calculated for that
triangle only.

-- 
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

Hi Ray Gardener, you recently wrote in povray.general:

> ... Don't worry; I'm not asking the POV-Team to do anything.
Ray, Thorsten is not posting on behalf of the POV-Team, those are
purely his own thoughts. 

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Another point to make is that most games don't use raytracing since until 
relatively recently the hardware architecture needed to implement a true 
raytracer in a graphics cards would have required something 3 times the 
size of a normal card. There is only one that I have even heard rumored 
to have been made and it is used in movie production, cost tens of 
thousands of dollars to buy and was nearly the size of a laptops entire 
motherboard. With the number of component we could fit into a new card 
the result would be no bigger than an existing NVidia card, however the 
development time needed to produce the chip, make sure it was stable and 
then pray that game companies that are used to using the cheats supplied 
through OpenGL and DirectX will actually use it makes the odds of anyone 
seeing such a card on the market any time soon very unlikely. The irony 
being that in many cases you have to upload large chunks of additional 
geometry and pre-made textures every few seconds in a game, while a true 
raytrace engine would only have to upload terrain geometry and those 
textures you couldn't produce using procedural systems (which for most 
games would be maybe 10% of them...) If you couldn't get a jump in speed 
and frame rate from have 90% of your data remain in-place throughout most 
of the game then you may as well not even bother trying. lol And most 
experts believe that short of a major increase in the size or speed of 
data transfer, the latest generation of cards are close to the physical 
limit of what they can improve on.

Hmm. Maybe there is a market for a true raytracing based card after 
all...

Not that any of the above addresses the central issue, which as everyone 
else has said, is that there is not likely to be a major improvement in 
speed or memory use from what you are planning to do. Or which in the 
case of memory couldn't be accomplished by a method of trading out stuff 
that POVRay doesn't specifically need at any given moment.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

>   There's nothing in raytracing that *forces* you to use these extra
> features. If it's enough to get the same result as you would get with
> scanline-rendering, you can use simple raycasting (ie. don't calculate
> any reflected nor refracted rays) without shadows. This way the necessity
> of having all the objects in memory at once is removed in the exact same
> way as in scanline-rendering.

Not quite. Hidden surface removal is accomplished in
raytracing by using the nearest intersection. If an
eye ray does not intersect other objects/bboxes along its vector,
it cannot be sure that it has hit the nearest one.

Even if it were so, POV-Ray doesn't give
you the choice. It retains all the geometry regardless.



>   1. It's a lot simpler. Rendering and texturing a mesh is a lot simpler
> with a raytracing algorithm than with a scanline-rendering algorithm.

Is it? With a (arbitrary) mesh, you need to determine the intersection
of a ray with some kind of octree. This means knowing the ray-plane
intersection algorithm and how to create, populate, and search octrees.
Then you need to forward the ray to intersect the particular triangle
in the mesh, and get its ST coords. You may also need to check other
parts of the octree to be sure your intersection is nearest the eye.

In scanline, you just go through the triangles in the mesh
and draw them. ST coords are easy because you get them
from vertex and edge interpolation. If one does not have
a triangle rasterizer handy, however, I can see how
the raytracing approach can be desirable.

I would characterize the relative difficulties as being
the tasks involved in adding new primitive types.
In raytracing, one must provide an intersection function.
In scanline, one must provide a tesselator. Having
written both a simple raytracer and scanliner, I
would say both consume about equal development time.
For the heightfield primitive, however, it was
challenging getting the last row/column to intersect
correctly -- the slab system and DDA traversal are
prone to easy-to-make off-by-one errors. For scanline,
it was just a matter of pulling triangles.



>   Also, even if full raytracing done, keeping the whole scene geometry
> in memory at once is not strictly necessary.
>   If the bounding box of a mesh object is never hit, there's no reason
> to even load that mesh into memory. It should be possible to develop
> a load-at-demand scheme, where meshes are loaded only when needed. It
> could also be a cache scheme, where meshes which have not been hit in
> longest time can be freed from memory.

Not true in full raytracing, unless you know in advance
the direction of every secondary ray. An object behind
the camera, for instance, can appear reflected in another
object in front of the camera. The trouble is, you don't
know if an object is never hit until you try to hit it,
hence you must bring it into memory.

Granted, some culling cases are possible. A reflective
flat opaque sphere, for example, can only cast secondary rays
in a half-sphere centered around the point that is
nearest to the eye. If no other objects lie nearer
than the plane parallel to the half-sphere's flat part,
and no other objects cast secondary rays, then those
objects behind the plane can be unloaded. The cull
search goes up exponentially with additional
reflective objects, however.



> > In a scanline renderer, each object is considered
> > only once, so an object only exists in memory
> > while being drawn.
>
>   This has the drawback that if a hundred triangles cover a certain
> pixel, that pixel is recalculated a hundred times (including texturing
> and lighting).

Not true. Texture and lighting can be deferred in scanline rendering
until after the z-buffer is populated. One needs a larger z-buffer, however.
In fact, I will implement this in my existing renderer to see
what the performance increase is, since my z-buffer already has
the necessary structure.

Ray

Post a reply to this message

> Ray, Thorsten is not posting on behalf of the POV-Team, those are
> purely his own thoughts.

Okay. I wasn't sure, because his sig mentioned
he was on the POV-Team.

Ray

Post a reply to this message

I finished benchmarking my new z buffer
which defers texturing and lighting until
after all the pixels have been depth sorted.
Each render was preceded with an srand(0) call
to ensure that all random number dependant
shading generated the exact same triangles.
Times for deferred rendering include iterating
through the light cache and computing the
final appearance of the scene. The scene was
a typical landscape using an ~ 500 x 500 pixel
heightfield. These results are preliminary
and I will be doing more tests as time goes on.

For a window size of 900 x 250, the difference
in speed was small, between 2 and 8 seconds on jobs
that ran between 1 and 2 minutes depending on LOD.
The texturing code in this case is very simple,
being just a colormap lookup; it represents a
small percentage of the total render pipeline.

Increasing the window size to 1800 x 500
changed things quite a bit:

    900 x 250        1800 x 500
  --------------   ---------------
   2m10s normal     6m05s normal
   2m02s deferred   5m35s deferred
      8s better       30s better

The time savings scaled proportionally
with the window size, but the render
time scaled less, resulting in greater
percentage time savings at the larger size.
With more screen pixels, the benefits of
deferred texturing increase.

I will be recompiling the Leveller Viewer
up to version 2.3 including the scanline
renderer for those who wish to evaluate
this particular scanline renderer implementation
with their own data.

Ray

Post a reply to this message

I thank everyone for their input.
I am documenting the scanline work at
http://www.daylongraphics.com/products/leveller/render/


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

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> Not quite. Hidden surface removal is accomplished in
> raytracing by using the nearest intersection. If an
> eye ray does not intersect other objects/bboxes along its vector,
> it cannot be sure that it has hit the nearest one.

  You didn't understand what I meant.

  Your scanline algorithm renders all meshes separately, one by one.
There's nothing in raytracing which would disallow this: You can first
raytrace one mesh and then another (using the same z-buffer method for
surface removal as in scanline rendering). Of course this means that the
same pixels need to be raytraced more than once, but that's exactly what
the scanline method is doing (except that with two meshes the raytracer
calculates each pixel twice, but the scanline method can calculate
many pixels tens of times, depending on the meshes).

> Even if it were so, POV-Ray doesn't give
> you the choice. It retains all the geometry regardless.

  The original question was memory usage of the raytracing and scanline
algorithms.

>>   1. It's a lot simpler. Rendering and texturing a mesh is a lot simpler
>> with a raytracing algorithm than with a scanline-rendering algorithm.

> Is it? With a (arbitrary) mesh, you need to determine the intersection
> of a ray with some kind of octree. This means knowing the ray-plane
> intersection algorithm and how to create, populate, and search octrees.
> Then you need to forward the ray to intersect the particular triangle
> in the mesh, and get its ST coords. You may also need to check other
> parts of the octree to be sure your intersection is nearest the eye.

  If the ray hits a triangle in a nearer octree node, there's absolutely
no way that a triangle in a farther octree node would be nearer. The octree
optimization works in such way that the first time the ray hits a triangle,
it's surely the closest one.

> In scanline, you just go through the triangles in the mesh
> and draw them.

  If your mesh has 100 million triangles and 10 of them are visible (so that
the rest get hidden behind them), you don't want to do that. Of course unless
render time is not critical.
  If you want any speed, you will need to perform a spatial tree optimization
to your scanline rendering algorithm as well. AFAIK commercial high-end
renderers do this.

  Besides, you say "draw them" as if it was trivial (or at least more trivial
than calculating the intersection of a ray and a triangle). I tend to
disagree.

> ST coords are easy because you get them
> from vertex and edge interpolation.

  You need perspective-correct interpolation (linear interpolation will
give you awful results), which is less trivial.

> Not true in full raytracing, unless you know in advance
> the direction of every secondary ray.

  You didn't understand this either. Please read my text again.

  You don't need to load meshes to memory, you only need to know their
bounding box. When a ray hits the bounding box, you load the mesh. If a
ray never hits the bounding box of a mesh, that mesh is never loaded.
Understand?

-- 
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

Patrick Elliott wrote:
>With the number of component we could fit into a new card
>the result would be no bigger than an existing NVidia card, however the
>development time needed to produce the chip, make sure it was stable and
>then pray that game companies that are used to using the cheats supplied
>through OpenGL and DirectX will actually use it makes the odds of anyone
>seeing such a card on the market any time soon very unlikely.

Cheats? Was there ever a 30fps algorithm free of them? :-)

>The irony being that in many cases you have to upload large chunks of
>additional geometry and pre-made textures every few seconds in a game,
>while a true raytrace engine would only have to upload terrain geometry
>and those textures you couldn't produce using procedural systems (which for
>most games would be maybe 10% of them...)

Why won't a raytracing card have to load new geometry regularly? It's not
necessarily going to know ahead of time which objects will be needed during
a game, and they are not all going to fit in memory at the same time for a
modern game.

Procedural textures will have to be calculated by the graphics card, which
surely has enough to do already (if you get the CPU to do it and send it to
the graphics card, you might as well send an image). I thought anyway that
procedural textures are not specific to raytracing?

Whilst I'm sure that, given sufficient time, you could reproduce 90% (or
100%) of game image textures with procedural textures, the question surely
is whether it is worth the extra time taken to generate the textures in the
first place, every frame. I can especially see problems producing things
like text at speed.

Post a reply to this message

>  If the ray hits a triangle in a nearer octree node, there's absolutely
no way that a triangle in a farther octree node would be nearer.

Well, there's that word, "if". If it doesn't hit
the nearer octree node, then another one has to be tested.


>   If you want any speed, you will need to perform a spatial tree
optimization
to your scanline rendering algorithm as well. AFAIK commercial high-end
renderers do this.

Yes, I agree that's a given. Using POV-Ray as
infrastructure is good in this respect
since it has raycasting in which to help build
such trees. Games of course do this (BSP, portals, etc.).
I think the attraction of scanline in film was
that many scenes are in rooms, where setting
up spatial culls is less demanding.


>  You need perspective-correct interpolation (linear interpolation will
give you awful results), which is less trivial.

True, except for micropolygons. My particular prototype
does draw macropolygons, so I will need to do that.
In REYES, it's not necessary.


>   You don't need to load meshes to memory, you only need to know their
> bounding box. When a ray hits the bounding box, you load the mesh. If a
> ray never hits the bounding box of a mesh, that mesh is never loaded.
> Understand?

Yes, I see what you're saying. So you would
load the bboxes of the geometry by themselves,
and then they would fill with the actual
respective geometry as initial hits occurred.
Yes, that's doable. You eventually wind
up with only the necessary geometry.
For some reason I thought you meant trying to
load/unload. Sorry about that.

I guess a developer might reason that, worst case,
you need to have enough memory for all objects,
so why bother adding the (albeit slight) overhead
of doing the first-time hit test. But I can see
this being a win on distributed or shared resource
systems when rendering movies or different view
angles of stills, because statistically more RAM
would be available to other tasks. POV would
definitely benefit, because when it animates
it reparses the .pov file for each frame. So as
you zoom in on a scene, less and less geometry
would get loaded (assuming no reflected rays that
wind up hitting the off-camera objects, at least).

I don't want to get into a scanline vs. raytracing
debate (except to collect the pros and cons of
each approach) because I want to augment POV-Ray, not replace
its raytracer. Hybrid renderers offer a compelling
wealth of strengths. Maybe a person doesn't need
to scanline anything most of the time, but
it's nice to know that he could if he wanted to.
For me, it's about having choice. I don't want
to invest lots of time learning POV and then
be forced to always raytrace when scanlining
might offer a big speed benefit on a particular job
or various parts of a job.

Thanks,
Ray

Post a reply to this message

> You can first
> raytrace one mesh and then another (using the same z-buffer method for
> surface removal as in scanline rendering).

Yes, that's true. That can be an efficient way
in some cases, like when a heightfield presents
a slim or small profile. What I particularly
like is that it provides a fine-grained way
to mix scanlining and raytracing.

One difficulty I have with doing that is that
sometimes its easier to drive a shader using
some stepped coordinate system of the primitive rather
than the world locations a raytracer returns.
For example, when scanlining a heightfield,
I do it cell by cell, so rocks can be distributed
based on how likely a cell is to be occupied.
With raytracing, I have to derive the cell
coords, and then maintain some kind of map
to keep track of which cell was painted with what.
I realize it's not good form to write primitive-specific
shaders, but they can be much easier to do sometimes,
especially when prototyping.

Displacement shading is also easier when scanlining.
At least, I haven't figured an easy way to do it
when raytracing.

Hmm.. this thread has been a good exploration
of the pros and cons of the two rendering techniques.
I'll make a digest of them and add it to my website.

Ray

Post a reply to this message

In article <Xns### [at] povrayorg>,
 ingo <ing### [at] tagpovrayorg> wrote:

> Just for my understanding; Everytime I see a statement simular to this I 
> wonder, does it mean building a CSG from POV-Ray primitives and then 
> tesselate it, or tesselate the "POV-Ray primitives" to a certain level and 
> then do the CSG (as I saw it in a very old version of 3D-studio)?

It generally refers to doing CSG with meshes. Making sure you don't end 
up with gaps or odd seams where the formerly separate meshes touch is 
not an easy problem to solve. Unions are easy, but merge, difference, 
and intersection are not.

There are algorithms for tessellating arbitrary objects, but they are 
never optimal. You end up with huge amounts of triangles in places where 
you don't need them, and you can still lose small details, the point of 
a cone or edges of a box for example. You can tessellate a box with 12 
triangles, but with one of these algorithms you are likely to end up 
with hundreds of thousands just to get rid of the faceting artifacts. 
CSG of multiple meshes is really the best way to go, it's just really 
hard.

One possible compromise would be to just avoid the problem of joining 
the seams by using solid geometry CSG on the meshes, like what POV does 
now with other primitives and meshes with an inside_vector specified. 
This is not really the best possible solution, but could give some 
improvements.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Hi ingo, you recently wrote in povray.general:

> wonder, does it mean building a CSG from POV-Ray primitives and then 
> tesselate it, 
Well, you can't really do that.... I mean, what would you build?

> or tesselate the "POV-Ray primitives" to a certain level and 
> then do the CSG (as I saw it in a very old version of 3D-studio)?
Yes, this is how you do it. You have to do CSG on triangle meshes and
that just gets very ugly. It is doable, Moray does this. But the
result is not pretty. If (in Moray) you've ever evaluated a CSG and
then converted it to mesh and went to edit that mesh, you'll know what
I mean. 

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Hi Ray Gardener, you recently wrote in povray.general:

> Well, CSG is undoubtedly a challenge.
> As long as "extremely hard" doesn't
> wind up becoming "intractable" I'm
> willing to forge ahead. In the reverse
> direction, I would love to see Moray
> display POV CSG objects.
Well, it can display them (after you do evaluate), but it doesn't
always work and the result, while displaying nicely on the screen, is
actually quite ugly once you look at it :-) But if all you want is
screen display, then yes, it's not intractable.
 
> In REYES, which tesselates down to
> micropolygons, one can consider the
> 3D location of the polygon to be
> inside or outside another primitive, and
> thus cull it at render time. 
That would be a nice way, but you're running into boundary conditions
as well that you need to be aware of. Because you're often going to
end up testing polygons against the boundary of the object... but if
you kept track to which object the polygon belonged, you could avoid
testing against it... sounds promising.
I guess the problem can be solved differently at rendering time.

Regards,

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

In article <web.3edc9d6bc13294582ff34a90@news.povray.org>, 
tom### [at] compsocmanacuk says...
> Patrick Elliott wrote:
> >With the number of component we could fit into a new card
> >the result would be no bigger than an existing NVidia card, however the
> >development time needed to produce the chip, make sure it was stable and
> >then pray that game companies that are used to using the cheats supplied
> >through OpenGL and DirectX will actually use it makes the odds of anyone
> >seeing such a card on the market any time soon very unlikely.
> 
> Cheats? Was there ever a 30fps algorithm free of them? :-)
> 
True enough, but in this case I mean 'cheat' as in faking real geometry 
like boxes and spheres using triangles. I consider it a cheat because it 
takes advantage of the existing hardware capability to produce something 
that only looks real by using so many triangles that you can't place 
anything else in the scene with it. That is the nature of most cheats, 
something that looks good enough for you purpose, but doesn't really 
reproduce the result accurately.

> >The irony being that in many cases you have to upload large chunks of
> >additional geometry and pre-made textures every few seconds in a game,
> >while a true raytrace engine would only have to upload terrain geometry
> >and those textures you couldn't produce using procedural systems (which for
> >most games would be maybe 10% of them...)
> 
> Why won't a raytracing card have to load new geometry regularly? It's not
> necessarily going to know ahead of time which objects will be needed during
> a game, and they are not all going to fit in memory at the same time for a
> modern game.
> 
True, but some things don't need to be fed back into in continually and 
those bases on primitives would take less room to store, meaning you can 
leave more of them in memory than normal. This should cut in half the 
amount of stuff you have to cram into the card in each frame, possibly 
more.

> Procedural textures will have to be calculated by the graphics card, which
> surely has enough to do already (if you get the CPU to do it and send it to
> the graphics card, you might as well send an image). I thought anyway that
> procedural textures are not specific to raytracing?
> 
Think some new cards may use them, but the same issue existed for them as 
for a true card based engine, the methods used to produce them where 
simply too complex to 'fit' in the existing architecture.

> Whilst I'm sure that, given sufficient time, you could reproduce 90% (or
> 100%) of game image textures with procedural textures, the question surely
> is whether it is worth the extra time taken to generate the textures in the
> first place, every frame. I can especially see problems producing things
> like text at speed.
> 
Kind of hard to say, since the option isn't exactly common or if it does 
exist is not used from what I have seen.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Lutz Kretzschmar wrote:
> If (in Moray) you've ever evaluated a CSG and
> then converted it to mesh and went to edit that mesh, you'll know what
> I mean.

Perhaps a triangle beautification process would be an idea :)

-- 
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

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

> Sorry for the confusion. For my purposes,
> I don't require all primitives, at least in
> the short to mid-term. Further along, it
> would be desirable to have as many POV
> primitives supported as possible.

What *are* your purposes? You still haven't explained this.


> I need the "lots of shapes" capability to implement shaders,

What do shaders have to do with the number of shapes?


> For shapes like hair strands and grass blades,
> however, supporting a spline (rope?) primitive
> should be done.

And what does this have to do with scanlining?


> I also don't see how an isosurface would
> be able to plant lots of trees or independant
> rocks on the terrain and maintain the
> same memory/rendering performance. If I
> was limited to raytracing, I would definitely
> brush up on isosurfaces, but otherwise...

Simple: Make a few dozen variations of tree meshes and plant a few tens 
of thousands (or more if you like) on the landscape. Blobs and 
isosurfaces can make good rocks, or you could use meshes for those too. 
And when viewed from a sufficient distance, a noisy isosurface can make 
a good bush.


> Like I mentioned, I think I have to try
> a prototype scanline implementation in POV to
> see how it goes. The jury is kind of out
> on conclusions just yet, and I don't

I haven't seen anyone but you suggest this is a good idea. Personally, I 
agree with Thorsten: adding scanline rendering to POV-Ray is silly and 
not that useful.


> want to endorse anything until I have
> accurate benchmarks. By Mr. Froehlich's
> own admission, raytracing speed doesn't
> compete with scanlining until you have
> billions of objects, so there's definitely
> room for exploration under that limit.

That's not what he said. Scanlining can compete with rendering triangles 
when memory is limited for the data, but you're ignoring other 
primitives. Your only reason given for thinking scanline would be better 
is an old paper for a computer system vastly different from modern 
computers, and your messages show extremely poor understanding of 
optimization.

Basically, POV doesn't need it, can't really benefit from it, it would 
be extremely limited compared to the raytracer, and it would be a huge 
amount of work to implement. You've given memory use as one reason, but 
raytracing can be optimized similarly. The fact that POV doesn't 
currently use these doesn't mean it never will. Speed as another, but 
you haven't compared a scanline rendering with an analogous raytracing. 
The speed advantages of scanlining are much less once you include all 
the work to make it do what raytracing does automatically. You've used 
video games as an example...POV isn't a video game, it is designed under 
entirely different constraints. If you want a preview, a much simpler 
and more effective solution would be an OpenGL preview.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

> I have considered that. I was about to write
> or modify a RIB renderer, for example.
> But I wasn't aware of the camera statement
> flexibility per se; thanks. If the POV-Team
> didn't mind me copying their parser code,
> the argument for doing a new app would
> certainly be better advanced. POV also
> has all the other infrastructure, such
> as texture file loading, in one nice spot.

A simple look at the license would tell you that you can only use the 
source for a custom version of POV-Ray, and it must only add to the 
functionality of the program (you can't remove the raytracer). Aside 
from this, the parser would not be that useful to you: it builds the 
entire scene in memory for the raytracer to render, changing it to do 
something else for your scanliner would require rewriting huge amounts 
of it (like pretty much all the code handling objects).


> I believe POV's future lies in being a more powerful platform for 
> creating 3D graphics in general, not just as a raytracer.

The future of the Persistance Of Vision Raytracer is to be a scanline 
renderer?


> For all I know, this experiment
> may one day lead to POV-Ray becoming the dominant
> film production tool for CG effects, and enable
> a whole new population of movie producers.

Why? That's not the goal of POV, and there are already tools for those 
jobs. POV is primarily a hobbyist tool, and is oriented more for complex 
stills with extremely realistic effects.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> What *are* your purposes? You still haven't explained this.

I have several. Myself, I just want to draw landscapes
how I want. My company would like to provide end users
with a standalone renderer (preferably one they already
know and use) that can do landscapes more efficiently
and with procedural shaders.

I like displacement mapping, and it appears to be a
lot easier and faster with scanline rendering. Or at
least, I know how to do it that way here and now,
which is more expedient than trying to figure out
how to get a raytracer to do it. Besides, POV doesn't
handle procedural shaders anyway... that's another
thing I'd add. That'll make it a totally custom patch,
but that's alright. And down the road, I'd like
to get into film production, but I don't feel
like shelling out for PrMan when I'm perfectly
willing to study and write code, and perhaps there are
others who feel the same. And making something like
that available to everyone has a nice feel to it.
Maybe it won't be based on POV in the end, but
right now, to have something I can experiment with,
using POV saves me a ton of time. If it also happens
to let people test what POV would be like with
such features, that's a useful bonus, even if in
the end the majority thinks it isn't worthwhile.


> What do shaders have to do with the number of shapes?

It's the way I write some of my shaders. I generate lots of geometry.
e.g., a fractal cubeflake has lots of cubes in it. It's a crude
approach, I guess, but it works, and it's way easy to do.
The same reason some people use shadeops in Renderman
instead of SL.


> > For shapes like hair strands and grass blades,
> > however, supporting a spline (rope?) primitive
> > should be done.
>
> And what does this have to do with scanlining?

They'd draw faster scanlined and take less memory.


> Simple: Make a few dozen variations of tree meshes and plant a few tens
> of thousands (or more if you like) on the landscape. Blobs and
> isosurfaces can make good rocks, or you could use meshes for those too.
> And when viewed from a sufficient distance, a noisy isosurface can make
> a good bush.

Cool. But I'd rather not take up the memory,
even if it's just pointers, and, well --
I just don't like using isosurfaces. I think they're
very neat, but they're not my cup of tea.

Ray

Post a reply to this message

> The future of the Persistance Of Vision Raytracer is to be a scanline
> renderer?

No, I wouldn't dream of replacing the raytracer
functionality. Having both raytracing and scanline
code is more desirable.


> Why? That's not the goal of POV, and there are already tools for those
> jobs. POV is primarily a hobbyist tool, and is oriented more for complex
> stills with extremely realistic effects.

What are POV's goals, actually? Does the
POV-Team have a specific mission statement
in mind, or do they incrementally review
and adjust the code on a as-things-crop-up basis?
Is POV a renderer (method unimportant) or
a raytracer? Is the goal to produce graphics
or specifically to raytrace?

It does have an animation feature. The thing
to ask is, does that feature exist solely
to do raytraced animations, was it an after-thought
to placate people who wanted to make short clips,
is it there just to augment film producers'
other footage generators, or is it a core
feature to let POV evolve towards doing
full production film work?

When one considers the scripting and anim features
combined, it's pretty powerful. For something
that isn't meant to do movies, it's also
pretty compelling in that sense. It seems almost
a shame not to leverage that.

Ray

Post a reply to this message

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

> One difficulty I have with doing that is that
> sometimes its easier to drive a shader using
> some stepped coordinate system of the primitive rather
> than the world locations a raytracer returns.

What stops you from doing the same thing with raytracing? What makes you 
think you can only compute world coordinates?


> For example, when scanlining a heightfield,
> I do it cell by cell, so rocks can be distributed
> based on how likely a cell is to be occupied.
> With raytracing, I have to derive the cell
> coords, and then maintain some kind of map
> to keep track of which cell was painted with what.

No you don't...why would you do this? You're just scattering rocks 
around. Just use trace() to place them on the surface at random 
locations. If you want an uneven distribution, use some function to 
control the probability of a rock landing.


> Displacement shading is also easier when scanlining.
> At least, I haven't figured an easy way to do it
> when raytracing.

Sounds like you're talking about something like this:
http://www.cs.utah.edu/~bes/papers/height/paper.html

There is a landscape example with the equivalent of 1,000,000,000,000 
triangles. And instead of generating and discarding millions (or 
billions) of unused microtriangles, it generates them as needed.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message