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