> 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