 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3EDB7CED.99BA1222@gmx.de> , Christoph Hormann
<chr### [at] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
|
|
