On Tue, 3 Jun 2003 17:28:29 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> 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.

To be clear: you mean your company would sell your modified POV ?

ABX

Post a reply to this message

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

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

POV textures *are* procedural. Image maps are relatively rarely used.


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

Uh, you may want to look at the POVMAN patch, which lets you use 
Renderman shaders on top of the existing procedural texture system.


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

I don't think you're going to save any time by building a scanline 
renderer on POV. Instead, you'll be spending lots of time figuring out 
how to hack your renderer into a system that was never designed with it 
in mind. I don't think you have any idea what you're getting into. 
You're free to try, of course, but I honestly don't expect to ever see 
anything substantial out of this. You'd be far better off staying with a 
separate program than trying to wedge a scanline renderer with those 
features into POV.


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

I'm not familiar with Renderman, so...what are you talking about? Some 
kind of procedural geometry? That can be raytraced, within certain 
limits. Either generate and store it beforehand or use a specialized 
algorithm to do it at render time (as was used in that paper I mentioned 
in another reply).


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

You like procedural geometry but don't like isosurfaces?

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

On Tue, 3 Jun 2003 21:55:41 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> > 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?

The registered trademark is 'POV-Ray', not 'POV'. I suppose '-Ray' exist there
for some reason.

ABX

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

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

Ah, look, one billion triangles rendered in 43 hours* for 1080 Kpixels.
Scaling your previously reported result of 16.8 million triangles drawn in
12 minutes as 275 Kpixels, your scanline method would take over 47 hours.
And their scene render time includes global illumination and shadows.

    Thorsten


* Note that they give time in CPU hours, not actual runtime - they used a
shared-memory supercomputer, but each node is not faster than a desktop
processor at all.  So runtime is probably a few minutes.  BTW, all existing
scanline algorithms do have problems scaling well on supercomputers or
clusters when working on the same image.  This is not the case for ray
tracing...

____________________________________________________
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 article <3edda353$1@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> your

This response was to Ray Gardener, not to you Chris...

    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

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3edd7bbf$1@news.povray.org...
> What are POV's goals, actually?

The real question is, is there presently another free graphic application
that does what POV-Ray accomplishes already, with the same level of
popularity and user support? And how many apps have we seen that started up
with a bang only to die in silence few years later? POV-Ray's development
model is certainly bizarre in some ways, but, with all its shortcomings, it
has been working for more than 10 years now.
If you really want a "goal" in POV-Ray, it is to be what its users want it
to be. It's self-evolving. I'm not really sure that stating an ambitious
goal, while laudable and a normal procedure for commercial software where
one has to convince financial backers, is the way to go: it's a little like
putting the cart before the horse in that case.
In these forums, we seen a lot of very well-minded, talented people offer
help of this sort, but in the end it all comes down to this: do users really
care? Do I want to see POV-Ray used in commercial movies? No interest. A
fast preview? Some interest, but the one I have is fast enough already so it
has a rather low priority. But do I want better, faster, artefact-free
global illumination and volumetrics? Programmable shaders? Full HDRI
support? A usable atmospheric (clouds and sky) model? You bet!

G.



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

Post a reply to this message

Patrick Elliott wrote:

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

You can exactly reproduce a mathematical box with 12 triangles. The sphere
is a better example, but where does this approach end? You end up with a
plethora of "fundamental" objects (including triangles!) to avoid
impersonating one geometry with another. This is great for many purposes
(see: POV), but I assert that it's not too good for games - being able to
manufacture anything out of a single shape (especially one with the
projection properties of a triangle) is valuable.
Nobody is going to bother with perfect spheres if conventional
triangle-based characters slow to a comparative crawl.

As for real geometry, I have yet to see a perfect triangle, sphere or box
in the real world :-)

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

I don't see why a raytracing card can retain an object but a scanline card
cannot, *if* both know in advance that an object will persist from frame to
frame (which they most likely won't).

Looking at typical objects that appear in games, a fast triangle is very
valuable. There once was a game that built characters from ellipsoids, but
they too are an approximation and the concept could not obviously benefit
from improving system speed. Objects in games are often not simple spheres.

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

I thought some modern cards implement things like pixel shaders, and even
small shading languages, which fit in nicely. I don't think that procedural
textures (or textures generated on the fly) are unique to raytracing, or
are intrinsically harder in scanline than raytracing (or vice versa). I've
seen some raytracers that rely entirely on image mapping.

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

I think some games companies are still getting used to programmable shaders
on cards (and also have the problem that on some platforms, a lot of cards
are not modern enough to have them). Perhaps that's another point - a new
raytracing card for games would have to be compatible with already-released
games, or nobody would buy it. It would need to support the existing OpenGL
or DirectX interfaces.

Procedural textures (or programmable textures on these cards) are
increasingly useful, but they do take time to compute and hence seem mainly
restricted to special effects. When you need to output 800x600 pixel frames
at >24fps, almost every trick becomes useful.

Post a reply to this message

Ray Gardener wrote:

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

I think you may be surprised to learn that the goal of the POV-Team is not
so much POV-Ray itself as much as it is the programming challenges involved
in making it, which are many and varied. The core developers of the program
are either professional programmers who work on if for fun in their spare
time or are computer science students working on it to help develop their
programming skills. That we as a public get to enjoy the fruits of their
labor is secondary to that goal. With that in mind, the development model
of POV-Ray is not clearly defined and is pretty much at the whim of the
developers and whatever tickles their fancy at the time. For a commercial
application that would be a disaster. For a hobbyists toy, and student
learning tool, it is an amazing success.

The above is based solely on my own personal observations and does not
necessarily represent the views and opinions of the POV-Team.

-- 
Ken Tyler

Post a reply to this message

In article <web.3eddb93bc1329458541c87100@news.povray.org>,
 "Tom York" <tom### [at] compsocmanacuk> wrote:

> You can exactly reproduce a mathematical box with 12 triangles. The sphere
> is a better example, but where does this approach end? You end up with a
> plethora of "fundamental" objects (including triangles!) to avoid
> impersonating one geometry with another. This is great for many purposes
> (see: POV), but I assert that it's not too good for games - being able to
> manufacture anything out of a single shape (especially one with the
> projection properties of a triangle) is valuable.

And why is being able to manufacture things out of many shapes worse 
than only having one shape to use?
(Actually, more than one shape, at least in OpenGL: points, lines, 
line-loop, line-strip, triangles, triangle-strip, triangle-fan, quads, 
quad-strip, polygon. And utilities to make disks, cylinders, spheres, 
other quadrics, NURBSs, etc...though those are tessellated. GLUT even 
includes a *teapot* primitive!) 


> Nobody is going to bother with perfect spheres if conventional
> triangle-based characters slow to a comparative crawl.

Nobody will use the faster option if the slower option is slower? Or 
nobody will use the raytracing card if it is slower, even if it gives 
better quality?


> As for real geometry, I have yet to see a perfect triangle, sphere or box
> in the real world :-)

Well, a triangle doesn't model anything in the real world, you need at 
least 4 of them to get a decent approximation of a real-world object, 
and you don't see many tetrahedrons lying around. There are many things 
that a box models quite closely, to a level that would be invisible on a 
typical camera image with comparable resolution.


> I don't see why a raytracing card can retain an object but a scanline card
> cannot, *if* both know in advance that an object will persist from frame to
> frame (which they most likely won't).

Both can, and there are have been ways to do so for quite some time. The 
difference is that a few thousand primitives can be stored in the space 
of a few thousand triangle mesh.


> Looking at typical objects that appear in games, a fast triangle is very
> valuable. There once was a game that built characters from ellipsoids, but
> they too are an approximation and the concept could not obviously benefit
> from improving system speed. Objects in games are often not simple spheres.

Marathon 1, an old Mac first-person shooter, had some left-over bits and 
pieces for a sphere renderer in its code...wasn't ever used in the game, 
though, and this predated 3D accelerator cards for home computers. But 
why couldn't a game benefit from a sphere primitive? With procedural 
shaders, you could do a lot with a sphere, like virtually any kind of 
energy bolt or blast effect. With more complex CSG available, you could 
build a complex room with primitives and procedural shaders and still 
have space available on the card for character meshes and skins.


> I think some games companies are still getting used to programmable shaders
> on cards (and also have the problem that on some platforms, a lot of cards
> are not modern enough to have them). Perhaps that's another point - a new
> raytracing card for games would have to be compatible with already-released
> games, or nobody would buy it. It would need to support the existing OpenGL
> or DirectX interfaces.

That is the primary problem: R&D would cost money and resources that 
could be used on a better but more conventional card, and at release 
there would be nobody ready to make use of the card, and no guarantee 
that there ever would be. It requires a card supporting those features, 
software to use the new features of the card, and game designers to use 
the new features of the software.


> Procedural textures (or programmable textures on these cards) are
> increasingly useful, but they do take time to compute and hence seem mainly
> restricted to special effects. When you need to output 800x600 pixel frames
> at >24fps, almost every trick becomes useful.

There is no limit on how long they can take, but that doesn't mean they 
are too slow to be useful. Dedicated hardware should be able to evaluate 
procedural textures extremely quickly, more quickly than an image map if 
it has to drag the image data back from main memory. Here you have that 
size issue again: image maps are big, and video card memory is limited, 
so things often have to be shuffled between video card memory and main 
system memory, which is surprisingly slow.

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

Christopher James Huff wrote:
>And why is being able to manufacture things out of many shapes worse
>than only having one shape to use?
>(Actually, more than one shape, at least in OpenGL: points, lines,
>line-loop, line-strip, triangles, triangle-strip, triangle-fan, quads,
>quad-strip, polygon.

Complexity (and so cost) of the card. And the primitives that the 3D API
gives you are not necessarily the same as the primitives that get passed to
the card (for instance, DirectX now deals in pixel-sized triangles instead
of points, and seems to have done away with the 2D DirectDraw stuff).

>And utilities to make disks, cylinders, spheres,
>other quadrics, NURBSs, etc...though those are tessellated. GLUT even
>includes a *teapot* primitive!)

The card isn't going to see any of these.

>Nobody will use the faster option if the slower option is slower? Or
>nobody will use the raytracing card if it is slower, even if it gives
>better quality?

Nobody will use the raytracing card for games if the quality gain is
insufficient given the speed drop. I (emph.) assume that there will be a
speed drop because I have seen many real-time scanline-based engines that
didn't use a 3D card. I have seen one real-time raytracer, and that was one
of the highly hand-optimised demos that used to be popular in the '90s. The
resolution was very low, the framerate was very low, and the reflection at
that resolution was indistinguishable from a reflection map. I would be
very happy for someone to prove me wrong with a realtime raytracer that can
compete on equal terms with a good realtime scanline renderer (in software,
of course - no 3D accelerator).

>Well, a triangle doesn't model anything in the real world, you need at
>least 4 of them to get a decent approximation of a real-world object,
>and you don't see many tetrahedrons lying around. There are many things
>that a box models quite closely, to a level that would be invisible on a
>typical camera image with comparable resolution.

I don't see a single box convincing anyone nowadays. You must use groups of
them, just as you must use groups of triangles to resemble anything useful.
And triangles certainly have their uses - what about terrain?
I think the ability to deform/split up objects in realtime using a triangle
mesh has quite a few advantages in games. Can you explode a box? Not as
easily as you can explode a few triangles. If you model an object using
more and more complex primitives, you necessarily have problems if at some
point you want to treat the object as a collection of smaller items.

>Both can, and there are have been ways to do so for quite some time.

In a game, an object may be removed at almost any time, either due to player
action directly or to something else. Surely unpredictable, especially
given trends towards destroyable/interacting scenery.

>The
>difference is that a few thousand primitives can be stored in the space
>of a few thousand triangle mesh.

But who's going to construct a game with thousands of sphere or box
primitives but no triangles? Room games maybe, but games in the open or set
in space? Surely you're not proposing the isosurface as a practical
realtime primitive shape? :-)

>Marathon 1, an old Mac first-person shooter, had some left-over bits and
>pieces for a sphere renderer in its code...wasn't ever used in the game,
>though, and this predated 3D accelerator cards for home computers. But
>why couldn't a game benefit from a sphere primitive? With procedural
>shaders, you could do a lot with a sphere, like virtually any kind of
>energy bolt or blast effect. With more complex CSG available, you could
>build a complex room with primitives and procedural shaders and still
>have space available on the card for character meshes and skins.

Yes, the game I mentioned also predated 3D cards (part of the reason they
were impelled to try ellipsoids, perhaps). For things like energy bolts, a
player will usually insufficient time to see the difference between a
sphere and a couple of crossed texture-mapped polygons (or a more
complicated model). For blast effects, I have seen textures mapped to a
sphere used as a kind of blast, and it generally looks terrible IMO. The
edge is too sharp, too uniform (same problem as in Quake 2-style blasts,
which were done with a sort of simple polygonal explosion model). I think
some sort of volumetric method would be far better here. With polygons, you
can have the procedural shader and a flexible type that doesn't have to
enforce spherical or elliptical symmetry, or be a closed surface.

For CSG applied to rooms, it would need to be as fast as the BSP-style
methods used for static geometry at the moment (although I guess BSPs are
not used for interactive scenery).

>That is the primary problem: R&D would cost money and resources that
>could be used on a better but more conventional card, and at release
>there would be nobody ready to make use of the card, and no guarantee
>that there ever would be. It requires a card supporting those features,
>software to use the new features of the card, and game designers to use
>the new features of the software.

Yes. I think you could get away with introducing a new card, even if nobody
used the new features, but it would have to support existing games,
performing at least as well as the conventional cards. This would be
difficult, particularly since it would inevitably be more expensive.

>There is no limit on how long they can take, but that doesn't mean they
>are too slow to be useful. Dedicated hardware should be able to evaluate
>procedural textures extremely quickly, more quickly than an image map if
>it has to drag the image data back from main memory.

Why? The procedural must be calculated using a (probably) user-specified
formula for every pixel that uses it. The image map must certainly be
projected every pixel (a single unchanging operation), but the
time-consuming step of actually acquiring the bitmap from system memory
hopefully occurs only once for a scene.

>Here you have that
>size issue again: image maps are big, and video card memory is limited,
>so things often have to be shuffled between video card memory and main
>system memory, which is surprisingly slow.

I think 3D card time is more limited. Bitmaps have the advantage that
texture loading time is independent of surface texture complexity. A flat
grey texture will take no more time to apply than a weathered texture with
"hello world" scrawled on it of the same resolution. Obviously, there's
going to be a significant difference with a procedural approach. Procedural
shaders are certainly going to be useful for particular effects, but I
don't believe they're going to dominate any time soon, if ever.

Post a reply to this message

> To be clear: you mean your company would sell your modified POV ?

No, it would be free, with source code also.

Ray

Post a reply to this message

In article <web.3ede2562c1329458bd7f22250@news.povray.org>, 
tom### [at] compsocmanacuk says...
> Christopher James Huff wrote:
> >And utilities to make disks, cylinders, spheres,
> >other quadrics, NURBSs, etc...though those are tessellated. GLUT even
> >includes a *teapot* primitive!)
> 
> The card isn't going to see any of these.
> 
But it will see the triangles that make them up, which takes lots of 
space.

> >Nobody will use the faster option if the slower option is slower? Or
> >nobody will use the raytracing card if it is slower, even if it gives
> >better quality?
> 
> Nobody will use the raytracing card for games if the quality gain is
> insufficient given the speed drop. I (emph.) assume that there will be a
> speed drop because I have seen many real-time scanline-based engines that
> didn't use a 3D card. I have seen one real-time raytracer, and that was one
> of the highly hand-optimised demos that used to be popular in the '90s. The
> resolution was very low, the framerate was very low, and the reflection at
> that resolution was indistinguishable from a reflection map. I would be
> very happy for someone to prove me wrong with a realtime raytracer that can
> compete on equal terms with a good realtime scanline renderer (in software,
> of course - no 3D accelerator).
> 
POV-Ray has a built in example of real time raytracing. It is small, but 
then you are dealing with an engine that is running on top of and OS and 
can't take full advantage of the hardware, since it will 'never' have 
100% total access to the processor. A card based one would likely be far 
more optimized, support possible speed improvements that don't exist in 
POV-Ray and have complete access to the full power of the chip running 
it. This would be slower why?

> I think the ability to deform/split up objects in realtime using a triangle
> mesh has quite a few advantages in games. Can you explode a box?

That is a point, but nothing prevents you from making explodable objects 
from triangles. In facts, the increase in available memory by using 
primitives in those things that are not going to undergo such a change 
means you can use even more triangles and make the explosion even more 
realistic. Current AGP technology it reaching its limits as to how much 
you can shove through the door and use. Short of a major redesign of both 
the cards and the motherboards, simply adding more memory or a faster 
chip isn't going to cut it.

> >The
> >difference is that a few thousand primitives can be stored in the space
> >of a few thousand triangle mesh.
> 
> But who's going to construct a game with thousands of sphere or box
> primitives but no triangles? Room games maybe, but games in the open or set
> in space? Surely you're not proposing the isosurface as a practical
> realtime primitive shape? :-)
> 
Again. Why would anyone design one that 'only' supported such primitives? 
That's like asking why POV-Ray supports meshes if we all think primitives 
are so great. You use what is appropriate for the circumstances. If you 
want a space ship that explodes into a hundred fragments use a mesh, if 
you want one that gets sliced in half by a beam weapon, then use a mesh 
along the cut line and primitive where it makes sense. Duh!

> Yes. I think you could get away with introducing a new card, even if nobody
> used the new features, but it would have to support existing games,
> performing at least as well as the conventional cards. This would be
> difficult, particularly since it would inevitably be more expensive.
> 
Well, that kind of describes most of the new cards that come out. lol 
Yes, it would need compatibility with the previous systems, but that 
isn't exactly an impossibility.

> >There is no limit on how long they can take, but that doesn't mean they
> >are too slow to be useful. Dedicated hardware should be able to evaluate
> >procedural textures extremely quickly, more quickly than an image map if
> >it has to drag the image data back from main memory.
> 
> Why? The procedural must be calculated using a (probably) user-specified
> formula for every pixel that uses it. The image map must certainly be
> projected every pixel (a single unchanging operation), but the
> time-consuming step of actually acquiring the bitmap from system memory
> hopefully occurs only once for a scene.
> 
There is nothing to prevent using a second chip dedicated to processing 
such things and having it drop the result into a block of memory to be 
used like a 'normal' bitmap. This assumes that the speed increase gained 
by building the rendering engine into the card wouldn't offset the time 
cost of the procedural texture. In any case, there are ways around this 
issue, especially if such methods turn out to already be in use on the 
newer DirectX cards.


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

Post a reply to this message

In article <web.3ede2562c1329458bd7f22250@news.povray.org>,
 "Tom York" <tom### [at] compsocmanacuk> wrote:

> Christopher James Huff wrote:
> >And why is being able to manufacture things out of many shapes worse
> >than only having one shape to use?
> >(Actually, more than one shape, at least in OpenGL: points, lines,
> >line-loop, line-strip, triangles, triangle-strip, triangle-fan, quads,
> >quad-strip, polygon.
> 
> Complexity (and so cost) of the card. And the primitives that the 3D API
> gives you are not necessarily the same as the primitives that get passed to
> the card (for instance, DirectX now deals in pixel-sized triangles instead
> of points, and seems to have done away with the 2D DirectDraw stuff).


> >And utilities to make disks, cylinders, spheres,
> >other quadrics, NURBSs, etc...though those are tessellated. GLUT even
> >includes a *teapot* primitive!)
> 
> The card isn't going to see any of these.

True, as I said, they were reduced to triangles. The API could probably 
hook up to built-in primitives if they were available, though.


> Nobody will use the raytracing card for games if the quality gain is
> insufficient given the speed drop. I (emph.) assume that there will be a
> speed drop because I have seen many real-time scanline-based engines that
> didn't use a 3D card. I have seen one real-time raytracer, and that was one
> of the highly hand-optimised demos that used to be popular in the '90s. The
> resolution was very low, the framerate was very low, and the reflection at
> that resolution was indistinguishable from a reflection map. I would be
> very happy for someone to prove me wrong with a realtime raytracer that can
> compete on equal terms with a good realtime scanline renderer (in software,
> of course - no 3D accelerator).

Real-time involves several simplifications in computation and geometry, 
which does push the advantage to scanline. But do you need 200FPS? If 
the raytracing card is *fast enough*, its advantages could outweigh 
those of a scanline card.
(There was some RTRT...Real Time Ray-Tracing...demo called something 
like Heaven 7, you may want to look at it. It was quite impressive on my 
PC.)


> I don't see a single box convincing anyone nowadays. You must use groups of
> them, just as you must use groups of triangles to resemble anything useful.
> And triangles certainly have their uses - what about terrain?

I didn't say they were useless. Triangles are definitely useful for 
things like terrain, though I wonder if a hardware isosurface solver 
could compete...
And the advantage of a box is memory: one box takes up less memory than 
one triangle. You *can* use groups of them, nobody has said you would be 
limited to single primitives.


> I think the ability to deform/split up objects in realtime using a triangle
> mesh has quite a few advantages in games. Can you explode a box? Not as
> easily as you can explode a few triangles. If you model an object using
> more and more complex primitives, you necessarily have problems if at some
> point you want to treat the object as a collection of smaller items.

There was a POV-Ray include that used CSG to "explode" objects. If that 
method wasn't suitable, an animated mesh would probably be the best way 
to go. Again, I'm not saying meshes are useless, just that there are 
often better things to use.


> >Both can, and there are have been ways to do so for quite some time.
> 
> In a game, an object may be removed at almost any time, either due to player
> action directly or to something else. Surely unpredictable, especially
> given trends towards destroyable/interacting scenery.

This is pretty much irrelevant. I just said you can add and remove 
geometry. What you are talking about would be more switching between 
different models for different frames of the animation.


> But who's going to construct a game with thousands of sphere or box
> primitives but no triangles? Room games maybe, but games in the open or set
> in space? Surely you're not proposing the isosurface as a practical
> realtime primitive shape? :-)

Who said no triangles? "More primitives" != "Ban triangles"!


> Yes, the game I mentioned also predated 3D cards (part of the reason they
> were impelled to try ellipsoids, perhaps). For things like energy bolts, a
> player will usually insufficient time to see the difference between a
> sphere and a couple of crossed texture-mapped polygons (or a more
> complicated model).

With a raytracing engine, the sphere would likely be faster than the 
crossed polygons.


> For blast effects, I have seen textures mapped to a
> sphere used as a kind of blast, and it generally looks terrible IMO. The
> edge is too sharp, too uniform (same problem as in Quake 2-style blasts,
> which were done with a sort of simple polygonal explosion model). I think
> some sort of volumetric method would be far better here. With polygons, you
> can have the procedural shader and a flexible type that doesn't have to
> enforce spherical or elliptical symmetry, or be a closed surface.

I was not talking about texture-mapped spheres. I was specifically 
talking about using procedural shaders: something volumetric or based on 
angle of incidence to the surface, or something more like the glow patch.


> Why? The procedural must be calculated using a (probably) user-specified
> formula for every pixel that uses it. The image map must certainly be
> projected every pixel (a single unchanging operation), but the
> time-consuming step of actually acquiring the bitmap from system memory
> hopefully occurs only once for a scene.

You're assuming all the texture maps and models fit in the card memory. 
Yes, when the image map is already local, using it would be faster than 
all but the simplest shaders. That doesn't mean procedural shaders are 
too slow. If a specific shader is too slow, you use a faster one, maybe 
resorting to an image map if it will do the job and there is memory for 
it.

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

> POV textures *are* procedural. Image maps are relatively rarely used.

Sorry, I meant 'procedural' in the user-definable sense.
POV-Ray's procedural textures are predefined.

To be fair, I thought I remembered reading
somewhere that POV 3.5 let textures use
user-defined functions, although just going
through the docs again I can't find
references to that. There's definitely
no displacement shading, at any rate,
except with isosurfaces (more below).


> Uh, you may want to look at the POVMAN patch, which lets you use
> Renderman shaders on top of the existing procedural texture system.

Thanks. It's a great hack, but it appears
limited to surface shading. Using POVMAN with
scanlining would make displacement shading easy.



> You like procedural geometry but don't like isosurfaces?

Well, isosurfaces have a sampling function interface
analogous to regular shading in Renderman. For some
shapes, this is preferable -- e.g., a sphere is
just x^2 + y^2 + z^2. But for other shapes,
determining from (x,y,z) whether the point is
inside or outside gets complicated.

Gritz had a good explanation in one of his
Rman papers -- he used drawing a line on a
surface as an example. One way is to iterate
all points (x,y) on the surface and determine
if a given point was on the line. This amounts
to hit testing within the rectangle formed
by the line's endpoints and thickness.
Another way to draw the line is to just
rasterize the rectangle directly. The latter
approach is also more intuitive for most
people, because it parallels the way
artists draw in the real world. If you want
to draw a line, you touch a pen to one point,
and drag the pen to the other point.

I like having both approaches available.
For the particular set of shaders I'm currently
working on, I find using procedural geometry
easier.

POV-Ray might benefit from including a
procedural geometry keyword, which would
have an option of emitting the geometry
to the scene's object tree (for raytracing
along with the other objects) or to be
rendered immediately using a z buffer.
In fact, I may take this approach, since
the scanliner can reside outside POV-Ray.
I'd have to let POV pass information about
objects (for shading), lights, and camera.
So one would have something like this
in an example script:

  global_settings
  {
     geometry_processing
     {
        enable=true

        overrides
        {
           raytrace=false   // if true, force processors
                            // to add created objects to object tree
                            // for raytracing.

           scanline=false   // If true, processors always
                            // render immediately into zbuffer.

           scanline_method=triangle
             // Force processors to allow macropolygons.
             // If method is 'reyes', then they are forced
             // to use REYES algorithm and dice to micropolygons.
        }
     }
  }
  // Zbuffer allocates and initializes here if necessary.

  ...

  height_field
  {
     png "hf.png"
     process_geometry "landscape_detail" true
  }

There would be a DLL (on win32) named landscape_detail.dll
that would be passed the object, along with a reference
to the zbuffer, the object tree, and cam/lighting.
The DLL could then proceed to create whatever geometry
it wanted, adding it to the tree or rasterizing it
into the zbuffer (the bool arg after the DLL name indicates which).

The geometry_processing keyword would also be available
outside global_settings, so that one could easily change
the rendering manner for sections of a script in specific ways.

Ray

Post a reply to this message

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

> > POV textures *are* procedural. Image maps are relatively rarely used.
> 
> Sorry, I meant 'procedural' in the user-definable sense.
> POV-Ray's procedural textures are predefined.

No...they are quite user-defined. The system is a bit more structured 
than a shader programming language, but still extremely flexible, and 
far from anything like predefined textures.


> To be fair, I thought I remembered reading
> somewhere that POV 3.5 let textures use
> user-defined functions, although just going
> through the docs again I can't find
> references to that.

You can use functions as patterns, and pigments as vector functions. By 
combining three functions with the average pattern, you can specify a 
function for each color channel of a pigment, though this isn't as 
flexible or convenient as a full shading language. Adding such a 
language would certainly be possible, though.


> There's definitely
> no displacement shading, at any rate,
> except with isosurfaces (more below).

If "displacement shading" means displacement done at render-time, then 
no, there isn't. It could be added without requiring a scanline renderer 
however, in fact there's probably a few people working on it.


> Well, isosurfaces have a sampling function interface
> analogous to regular shading in Renderman. For some
> shapes, this is preferable -- e.g., a sphere is
> just x^2 + y^2 + z^2. But for other shapes,
> determining from (x,y,z) whether the point is
> inside or outside gets complicated.

For insideness testing, just use the inside() function...coming up with 
a custom function for it is overkill. I don't know what this has to do 
with isosurfaces though. If you're talking about the difficulty of 
making specific shapes with isosurfaces, there are functions and macros 
to make it more convenient.

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

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


That is very neat. It has some restrictions on
how the displacements can be expressed, but still,
offers a compelling option over bumpmapping.

Would you know if this algorithm is being considered
for inclusion in POV-Ray?

Thanks,
Ray

Post a reply to this message

> Ah, look, one billion triangles rendered in 43 hours* for 1080 Kpixels.
> Scaling your previously reported result of 16.8 million triangles drawn in
> 12 minutes as 275 Kpixels, your scanline method would take over 47 hours.
> And their scene render time includes global illumination and shadows.

That scene I submitted did generate a lot of
geometry that was ultimately occluded by nearer geometry.
Here is another scene,
http://www.daylongraphics.com/products/leveller/render/testimg_001.jpg

which took 67 seconds.

When rendering, after a few seconds, the image looks like this:
http://www.daylongraphics.com/products/leveller/render/testimg_004.jpg

Sometimes it's nice to scanline to see the object draw
that way, instead of having the render window draw
line by line (or mosaic into smaller and smaller squares).

Has anyone implemented displacment shading in POV-Ray
using that algorithm? If not, I'd volunteer.


Ray

Post a reply to this message

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

> That is very neat. It has some restrictions on
> how the displacements can be expressed, but still,
> offers a compelling option over bumpmapping.

As the paper mentions, it is more restrictive than REYES, but is the 
same type used in Maya, so in practice it may not be as restrictive as 
it first seems.


> Would you know if this algorithm is being considered
> for inclusion in POV-Ray?

In a near-term official version, it is unlikely. 3.5 is near the end of 
life for this code-base, there are plans for a redesign and rewrite. 
There's several patch writers interested in it though, and the POV Team 
is aware of it. I'm going to try to implement it in my own raytracer, if 
I succeed I will get to work on a POV patch. This and Schaufler and 
Jensen's point geometry raytracing algorithm both look quite 
interesting. (In fact, I've been wondering if the point geometry 
rendering could be extended with a similar feature, generating 
additional displaced points on the fly.)

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

Program ended abnormally on 6/4/03 4:32 AM, Due to a catastrophic Gilles
Tran error:
> But do I want better, faster, artefact-free
> global illumination and volumetrics? Programmable shaders? Full HDRI
> support? A usable atmospheric (clouds and sky) model? You bet!
> 
> 

In your hands, these weapons would be deadly.

;)

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> ... The core developers of the program
> are either professional programmers who work on if for fun in their spare
> time or are computer science students working on it to help develop their
> programming skills. That we as a public get to enjoy the fruits of their
> labor is secondary to that goal. With that in mind, the development model
> of POV-Ray is not clearly defined and is pretty much at the whim of the
> developers and whatever tickles their fancy at the time.

Hmm... I understand, but what I now wonder is
what happens when a critical mass of users have
made large investments in using POV-Ray.

Speaking hypothetically, let's say that all copies of POV-Ray
somehow vanished, along with any source code versions, and the
developers got tired of the whole thing as well. Essentially,
no more POV-Ray.

But there would be terabytes of POV-Ray scene files still left,
and tons of POV-Ray experience in its user base. So how much
time would elapse before someone would recreate it? I would
guess that a new POV-Team would spring up in a few days.

It's a weird extreme scenario, but I think it demonstrates
that at a certain point, a program's existence isn't
confined tightly to its development team. Intermediate
scenarios (e.g., the POV-Team decides on a radical change
that breaks half of all scene files, but another group instantly
springs up forking POV-Ray to preserve compatability, or
the backlash is so strong the POV-Team changes their minds)
would also demonstrate the same effect. It's similar to
what people notice about political leaders: yes, the people
at the top technically have absolute power, but in practice,
they do not.

Let's imagine another case: an outsider develops a really
popular patch. Nearly everyone loves it, but (again, hypothetically)
the POV-Team doesn't. What would happen? The code would be
forked and the majority of the user base would follow
whatever group managed the fork.

Here's a really disturbing thought: Like they did with
C/C++ and web browsing, Microsoft clones POV-Ray and
does the usual embrace and extend. They do a good enough
job that most of the user base eventually migrates all of its
files to use MS-POV (arrgh, I actually get queasy just
thinking about it :). As the years go by, the POV-Team is
left maintaining an increasingly incompatible and
not-as-powerful program. To most users, whatever code
the POV-Team is maintaining is no longer POV-Ray, because
they're not using that code anymore.

I'm not trying to sound weird or anything, but I
thought it would be interesting to ponder the
deeper nature of project ownership when the project
has reached a critical mass of users and legacy data.
I would say that it really does rest with the users; the
developers basically have no choice but to keep
doing what the users want, or risk having their
leadership given to others.

Ray

Post a reply to this message

On Thu, 5 Jun 2003 00:49:56 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> Hmm... I understand, but what I now wonder is
> what happens when a critical mass of users have
> made large investments in using POV-Ray.

They have it, they use it.

> Speaking hypothetically, let's say that all copies of POV-Ray
> somehow vanished, along with any source code versions, and the
> developers got tired of the whole thing as well. Essentially,
> no more POV-Ray.

This is only case of whole universe disaster.

> Intermediate
> scenarios (e.g., the POV-Team decides on a radical change
> that breaks half of all scene files, but another group instantly
> springs up forking POV-Ray to preserve compatability, or
> the backlash is so strong the POV-Team changes their minds)
> would also demonstrate the same effect. It's similar to
> what people notice about political leaders: yes, the people
> at the top technically have absolute power, but in practice,
> they do not.

Your are blowing this problem out of proportions.
I do not need any Team to play with scenes with existing binaries. I do not need
any Team to make own extensions I need. But that's the Team who initialized my
interest, start my fun, released application for me. I love it. I use it. 

> Let's imagine another case: an outsider develops a really
> popular patch. Nearly everyone loves it, but (again, hypothetically)
> the POV-Team doesn't. What would happen? The code would be
> forked and the majority of the user base would follow
> whatever group managed the fork.

Excuse me, how long are you with POV? Have you noticed differences in features
betwen POV-Ray 3.1, MegaPOV 0.7, POV-Ray 3.5 and MegaPOV 1.0 and some
announcements about MegaPOV 1.1?

ABX

Post a reply to this message

Patrick Elliott wrote:
>But it will see the triangles that make them up, which takes lots of
>space.

I think the textures take up rather more. Games often minimise geometry when
they can get away with better texture maps.

>POV-Ray has a built in example of real time raytracing. It is small, but
>then you are dealing with an engine that is running on top of and OS and
>can't take full advantage of the hardware, since it will 'never' have
>100% total access to the processor. A card based one would likely be far more
>optimized, support possible speed improvements that don't exist in POV-Ray and
>have complete access to the full power of the chip running it. This would be
>slower why?

Neither will a software-only (I emphasize software only - no card support)
scanline renderer (under windows), yet they can work in realtime at higher
resolution. Surely there is an example that is optimised for game-style
geometry, rather than being the raytracing equivalent of lightwave?
I emphasize that I'm not denying your argument on strong evidence, but I
have not seen a realtime raytracer do what a decent realtime
scanline/S-buffer based system can do. I'd really like to, mind.

>That is a point, but nothing prevents you from making explodable objects
>from triangles. In facts, the increase in available memory by using
>primitives in those things that are not going to undergo such a change
>means you can use even more triangles and make the explosion even more
>realistic. Current AGP technology it reaching its limits as to how much
>you can shove through the door and use. Short of a major redesign of both
>the cards and the motherboards, simply adding more memory or a faster
>chip isn't going to cut it.

Until it actually happens I remain unconvinced. We've always been on the
edge of running out of bandwidth since the first 3D cards. Of course,
there's a
limit, but I hear convincing speculation each way on when we'll reach it.
If a competitive realtime raytracer on a chip is possible, why would it
require favours in terms of the competition running out of room for
triangles? It should be able to do better at any time.

>Again. Why would anyone design one that 'only' supported such primitives?
>That's like asking why POV-Ray supports meshes if we all think primitives
>are so great. You use what is appropriate for the circumstances. If you
>want a space ship that explodes into a hundred fragments use a mesh, if
>you want one that gets sliced in half by a beam weapon, then use a mesh
>along the cut line and primitive where it makes sense. Duh!

Speed and complexity (hence cost). Current cards (at the high end for games)
can cost a couple of hundred dollars. Any simplification that can be made
can save cost, and having a card that doesn't need to switch over from
using triangles to drawing boxes halfway through a scene is good for
efficiency. Your particular example seems to require conversion between
triangles and other primitives (the spaceship is at one point a mesh, and
then it's half a mesh and half something else), which is not exactly rapid
in many cases. Aside from that, what's POV got to do with it? Cards don't
support NURBS as primitives either, despite them being popular in
non-realtime scanline renderers. I don't think a raytracer on a card
designed for realtime game use has to solve exactly the same problems as a
top-level raytracer for non-realtime use. In the same way that the Quake
engine and 3D Studio aren't kin.

>Well, that kind of describes most of the new cards that come out. lol
>Yes, it would need compatibility with the previous systems, but that
>isn't exactly an impossibility.

It is more difficult when you have completely changed the philosophy behind
the card, but want it to remain compatible with the previous philosophy.
You don't agree?

>There is nothing to prevent using a second chip dedicated to processing
>such things and having it drop the result into a block of memory to be
>used like a 'normal' bitmap. This assumes that the speed increase gained
>by building the rendering engine into the card wouldn't offset the time
>cost of the procedural texture. In any case, there are ways around this
>issue, especially if such methods turn out to already be in use on the
>newer DirectX cards.

Then aren't you going to lose the advantage of generating textures on the
card? If I generate a bitmap by procedure or by artist and subsequent
loading, I must still store it. Newer cards do procedural shading on a
pixel as it's rendered (or so I thought), so no extra storage is required.

Post a reply to this message

On Wed, 4 Jun 2003 13:32:10 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> Sorry, I meant 'procedural' in the user-definable sense.
> POV-Ray's procedural textures are predefined.
>
> To be fair, I thought I remembered reading
> somewhere that POV 3.5 let textures use
> user-defined functions, although just going
> through the docs again I can't find
> references to that.

http://www.povray.org/search/?s=user-defined

> There's definitely
> no displacement shading, at any rate,
> except with isosurfaces (more below).

I think, you are mistaking texturing ang geometry in SDL syntax (thought they
are connected in reality). You can use the same informations for create both but
you will not find information about changing geometry in chapters about creating
textures.

> > You like procedural geometry but don't like isosurfaces?
>
> Well, isosurfaces have a sampling function interface
> analogous to regular shading in Renderman. For some
> shapes, this is preferable -- e.g., a sphere is
> just x^2 + y^2 + z^2.

That's not equation of f_sphere but of f_r internal function.
And becouse you do not see difference you wrote next sentence.

> But for other shapes,
> determining from (x,y,z) whether the point is
> inside or outside gets complicated.

Actually test for inside/outside is far simpler then looking for intersection. 
Inside are all points where value of function for given point is below value of
threshold. Outside are all points where value of function for given point is
over value of threshold. On surface are all points where value of function for
given point is equal value of threshold.

> POV-Ray might benefit from including a
> procedural geometry keyword

Adding one keyword does not change functionality. That's internall support of
keyword which makes feature useful ;-)

> which would
> have an option of emitting the geometry
> to the scene's object tree (for raytracing
> along with the other objects)

If permanently, why this can't be done by script?

> There would be a DLL (on win32) named landscape_detail.dll
> that would be passed the object, along with a reference
> to the zbuffer, the object tree, and cam/lighting.
> The DLL could then proceed to create whatever geometry
> it wanted, adding it to the tree or rasterizing it
> into the zbuffer (the bool arg after the DLL name indicates which).

You can read about adding support for dlls for example in this thread
http://news.povray.org/povray.programming/31596/

> The geometry_processing keyword would also be available
> outside global_settings, so that one could easily change
> the rendering manner for sections of a script in specific ways.

Two side notes, since number of your post increases can I ask you kindly about
making your lines longer? Is there any particular reason for you to use
sometimes less than 50 characters? It would make reading your long posts easier
for those who do not have wheel in mouse and use only keybord. Thanks.

And before you will start discuting all features you want discuss I just want to
told you about existence of povray.unofficial.patches and povray.programming
groups. Their existence is well described at
http://news.povray.org/povray.announce.frequently-asked-questions/

ABX

Post a reply to this message

Christopher James Huff wrote:
>True, as I said, they were reduced to triangles. The API could probably
>hook up to built-in primitives if they were available, though.

Oh, no doubt. You might be able to implement an OpenGL-conformant interface,
so that the teapot really does go through as a primitive to the card... :-)

>Real-time involves several simplifications in computation and geometry,
>which does push the advantage to scanline. But do you need 200FPS? If
>the raytracing card is *fast enough*, its advantages could outweigh
>those of a scanline card.

I expect most people would be happy with 30 fps or above (some people need
higher in multiplayer games, but they turn off detail). If the card cannot
match other cards on scenes of similar complexity at that rate, it will be
visually annoying.

>(There was some RTRT...Real Time Ray-Tracing...demo called something
>like Heaven 7, you may want to look at it. It was quite impressive on my
>PC.)

Yes, and Rubicons 1 and 2, and Fresnel 1 and 2. The Rubicons did the
raytracing at low resolution and used interpolation. Fresnel 2 (and 1?)
actually took advantage of a 3D card to accelerate the raytracing,
apparently. Heaven 7 looks incredibly good (it only needed one light source
and no shadow checking!). All of these did no space subdivision (no octrees
or BSP methods). Are there then only RTRT *demos*? No equivalent of the
various toy engines that you can find on places like the 3D Engine List?

>I didn't say they were useless. Triangles are definitely useful for
>things like terrain, though I wonder if a hardware isosurface solver
>could compete...

It takes long enough on an Athlon to solve those things...

>And the advantage of a box is memory: one box takes up less memory than
>one triangle. You *can* use groups of them, nobody has said you would be
>limited to single primitives.

Sure, but people tend to minimise geometry in favour of textures in games. I
know it's often the other way round on non-PC graphics systems (hence
OpenGL being caught behind the times when DirectX started supporting all
these fancy texturing methods), so perhaps a primitive rich card would
reverse this.

>There was a POV-Ray include that used CSG to "explode" objects. If that
>method wasn't suitable, an animated mesh would probably be the best way
>to go. Again, I'm not saying meshes are useless, just that there are
>often better things to use.

I know, I've used it (and very useful it is too :-) However, isn't
differencing famously slow? Also, wouldn't a differenced object be doing
calculations for all the empty "subtracted" pixels as well?

>This is pretty much irrelevant. I just said you can add and remove
>geometry. What you are talking about would be more switching between
>different models for different frames of the animation.

I see.

>Who said no triangles? "More primitives" != "Ban triangles"!

I'm guessing that triangles would remain the most popular shape, except in
the simplest room-based games (irrespective of technical arguments, it
would take a while for programmers/artists to start using the other
primitives extensively).

>With a raytracing engine, the sphere would likely be faster than the
>crossed polygons.

I've no idea whether that's true, but I imagine it's unlikely to be true
with a volumetrically shaded sphere.

>I was not talking about texture-mapped spheres. I was specifically
>talking about using procedural shaders: something volumetric or based on
>angle of incidence to the surface, or something more like the glow patch.

Aren't atmosphere/volumetric effects often faster with scanline methods (I
don't know)?

>You're assuming all the texture maps and models fit in the card memory.
>Yes, when the image map is already local, using it would be faster than
>all but the simplest shaders. That doesn't mean procedural shaders are
>too slow. If a specific shader is too slow, you use a faster one, maybe
>resorting to an image map if it will do the job and there is memory for
>it.

They usually do, because the programmers know what sort of minimum memory
requirements on the card they're prepared to tolerate. When they don't, you
really notice. However, using predominantly procedural shaders you throw
the bottleneck on the card's processor, and card memory is cheaper.

Post a reply to this message

Christopher James Huff wrote:



> (There was some RTRT...Real Time Ray-Tracing...demo called something
> like Heaven 7, you may want to look at it. It was quite impressive on my
> PC.)

If I remember correctly, Heaven 7 is an OpenGL demo, not RTRT?

Andreas

-- 
http://www.render-zone.com

Post a reply to this message

Ray Gardener wrote:
> scenarios (e.g., the POV-Team decides on a radical change
> that breaks half of all scene files

Wasn't there some thread a while back about completely ditching all
the POV primitives and using isosurfaces for everything instead? :)

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

> Your are blowing this problem out of proportions.

What problem? I was just responding to Ken's assertion that
"the development model of POV-Ray was pretty much at the whim
of the developers", when that is not actually true. I'm not making any
connection between this particular subject and the scanline stuff;
I'm just pondering it independantly as an interesting socioeconomic
phenomenon in its own right.

Roughly speaking, whoever supports a file format best gains the
majority of the user base and relegates other supporters to the sidelines,
or even displaces them entirely. But the users decide what constitutes
"best", so whatever feeling of control developers have is illusory.

The only point I can make relating that and the scanline feature
is that *if* the majority of users decided scanlining was desirable,
then it wouldn't matter what the developers thought; the feature
would inherently find its way in. OTOH, sometimes users don't know
what they want, and they realize only in retrospect that they badly needed
a certain feature (it explains those "How did I ever live without X?"
sayings).
Software is prone to that phenomenon because myths build up easily about
software, and the only way to change thinking is to just develop working
code and demo it. So I risk failure to demo scanlining just in case
it can only be desirable retroactively.

The point about the different unofficial POVs is interesting too,
actually. They demonstrate what happens when a large but minor part
(say 30% or 40%) of the user base prefers a feature. A parallel fork
winds up being separately maintained. A scanlining feature could
end up like that too.

As for my narrow lines of text, I find reading long lines difficult
(it's why newspaper columns are narrow -- imagine if newspaper articles
ran their text all the way across a page. It's also why all the
main news sites like Salon, ABC, MSNBC, etc. use columns). I'd rather
scroll (I just hit the down arrow key) than keep losing track of
which line is next.

Ray

Post a reply to this message

On Thu, 5 Jun 2003 07:32:58 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> > Your are blowing this problem out of proportions.
>
> What problem?

Importance of listed possibilities of the future.

ABX

Post a reply to this message

> Adding one keyword does not change functionality. That's internall support
of
> keyword which makes feature useful ;-)

Well, duh. Obviously there has to be code implementing
what the keyword does. I wouldn't be digging into
the POV source otherwise.


> > which would
> > have an option of emitting the geometry
> > to the scene's object tree (for raytracing
> > along with the other objects)
>
> If permanently, why this can't be done by script?

Because the SDL is not always the preferred language.
A person might have legacy code in another language,
or prefer to use C++ because it's object oriented,
or compiled code runs faster when object generation
involves some complex process, etc. All else being
equal, I'd rather write in C/C++ just because... I'm
tired of having to type "#declare" every time I
want to assign a value to a variable in SDL.

Ray

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3edf5487$1@news.povray.org...
> Roughly speaking, whoever supports a file format best gains the
> majority of the user base and relegates other supporters to the sidelines,
> or even displaces them entirely. But the users decide what constitutes
> "best", so whatever feeling of control developers have is illusory.

The point you're missing is that in the case the Povray, the users are also
the developers. It's not a users vs developers game. The two latest members
of the POV-Team (Nathan Kopp and Ron Parker) started out as patchers, took
it on their own to add features that became extremely popular, maintained
and supported complex multipatches for a while (thus demonstrating their
goodwill and ability to interact with users) and were quickly "promoted" as
developers.
The fact is, if you're a proven talented developer, create POV-Ray code that
1) works 2) is actually useful and 3) doesn't turn into a support headache,
your work will find its way into a future POV-Ray. I too was wondering about
the forking problem a few years ago (I've been using patches since 1996) but
it just didn't happen and the system self-regulated very nicely... which is
an amazing socioeconomic phenomenon indeed...

>Software is prone to that phenomenon because myths build up easily about
>software, and the only way to change thinking is to just develop working
>code and demo it.

That's certainly true, and could be the case for a scanline alternative.
But beware of developer's hubris, something we've seen a lot in this groups,
i.e. announcements/proposals from programmers about radical features
supposed to change the future of Pov-Ray, but that eventually came to nought
for various reasons, the main one being that the developers weren't familiar
enough with POV-Ray itself and how it is actually used.
My only advice would be for you to start using POV-Ray yourself to create
complex scenes and animations (I'm not talking about demo scenes, but images
created for the IRTC or another real-life purpose) and then rethink your
patch from this experience.

G.

--

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

Post a reply to this message

In article <3edf43f5@news.povray.org>,
 Andreas Kreisig <and### [at] gmxde> wrote:

> > (There was some RTRT...Real Time Ray-Tracing...demo called something
> > like Heaven 7, you may want to look at it. It was quite impressive on my
> > PC.)
> 
> If I remember correctly, Heaven 7 is an OpenGL demo, not RTRT?

You remember incorrectly, it is RTRT.
http://www.acm.org/tog/resources/RTNews/demos/overview.htm

-- 
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 <web.3edf118dc1329458bd7f22250@news.povray.org>,
 "Tom York" <tom### [at] compsocmanacuk> wrote:

> >I didn't say they were useless. Triangles are definitely useful for
> >things like terrain, though I wonder if a hardware isosurface solver
> >could compete...
> 
> It takes long enough on an Athlon to solve those things...

Primarily because an Athlon is not designed to solve them. I was 
specifically talking about a hardware solver...no function VM overhead, 
the functions would execute natively, and as much as possible hard-wired 
into the logic circuits. And remember that raytracing doesn't have the 
same kind of CPU constraints as scanlining, it can be made very parallel.


> >And the advantage of a box is memory: one box takes up less memory than
> >one triangle. You *can* use groups of them, nobody has said you would be
> >limited to single primitives.
> 
> Sure, but people tend to minimise geometry in favour of textures in games. I
> know it's often the other way round on non-PC graphics systems (hence
> OpenGL being caught behind the times when DirectX started supporting all
> these fancy texturing methods), so perhaps a primitive rich card would
> reverse this.

Geometry is minimized because it is expensive, most of it has to be sent 
to the card for each frame. Cheaper geometry == more geometry possible.


> I know, I've used it (and very useful it is too :-) However, isn't
> differencing famously slow?

No. It is slower than a plain primitive, that doesn't automatically mean 
"too slow to be useable".


> Also, wouldn't a differenced object be doing
> calculations for all the empty "subtracted" pixels as well?

No, that's what bounding is for.


> >With a raytracing engine, the sphere would likely be faster than the
> >crossed polygons.
> 
> I've no idea whether that's true, but I imagine it's unlikely to be true
> with a volumetrically shaded sphere.

Unless you're doing scattering media in the thing, it can be done very 
quickly. If you're doing a simple surface shader, even faster. You're 
picking the slowest possible way to do it with raytracing and comparing 
it to the fastest possible scanlining method, which is ridiculous.


> >I was not talking about texture-mapped spheres. I was specifically
> >talking about using procedural shaders: something volumetric or based on
> >angle of incidence to the surface, or something more like the glow patch.
> 
> Aren't atmosphere/volumetric effects often faster with scanline methods (I
> don't know)?

You can fake them quickly using multiple layers of transparent surfaces, 
but getting anything realistic is nearly impossible and you can fake 
them exactly the same way with raytracing. Again, a hardware volume 
evaluator might speed things up greatly.


> They usually do, because the programmers know what sort of minimum memory
> requirements on the card they're prepared to tolerate. When they don't, you
> really notice. However, using predominantly procedural shaders you throw
> the bottleneck on the card's processor, and card memory is cheaper.

You can't keep all the data on the card, a lot of it has to be sent 
every frame. Bus bandwidth is considerably more expensive than card 
memory and more limited than processor power. You could reduce memory, 
use the extra space for some additional raytracer processors, and still 
have a card capable of far more geometry and more realistic rendering at 
perfectly reasonable frame rates.

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

> But beware of developer's hubris, something we've seen a lot in this
groups...

Yeah, I've certainly seen some of that here and there. :)

I'm just speculating out loud what the implications might be if I
do get a scanlining patch working (however minimal at first).
The feature is fairly nontrivial... it's a significant
paradigm change on the entire program, and for a lot of people,
it changes the very nature of POV-Ray. I'm starting to debate
in my mind whether I should take ABX's suggestion and do
a totally different application, even if writing a parser
will be a headache. Maybe a simple app with a simple SDL,
just to demonstrate the idea in isolation at first.

I think hybrid rendering is the future, because you see the technique
being used more and more. Gritz developed Entropy at Exluna and
managed to sell a few copies before Pixar shut him down. The question
I'm perhaps asking is, has the time come for an open source/free
hybrid renderer? And if so, what's the most sensible route to it?
One thing I worry about is people saying "This is really nice,
but why on Earth didn't you make it a POV patch? Now I have
to maintain some scenes in one format and some in another."


> i.e. announcements/proposals from programmers about radical features
> supposed to change the future of Pov-Ray, but that eventually came to
nought
> for various reasons, the main one being that the developers weren't
familiar
> enough with POV-Ray itself and how it is actually used.

I can believe that. For what it's worth, I've given the issue a
lot of thought prior to this thread. I've done several large
projects (Corel Draw for Mac, a PostScript interpreter, a vector
file format, Leveller, and an internal tool for EA I can't
talk about), and I fully appreciate what the logistics are.
I wouldn't do this if I felt I wasn't doing it properly or
was just going to stop halfway through.



> My only advice would be for you to start using POV-Ray yourself to create
> complex scenes and animations (I'm not talking about demo scenes, but
images
> created for the IRTC or another real-life purpose) and then rethink your
> patch from this experience.

It's a good idea, and I'd love to, but I'm afraid I don't have the time.
I did do some map diagram work for a music festival once
with POV-Ray, so I'm not too unfamiliar with it I hope.

Ray

Post a reply to this message

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

> 

>> created for the IRTC or another real-life purpose) and then rethink
>> your patch from this experience.
> 
> It's a good idea, and I'd love to, but I'm afraid I don't have the
> time. 
> 
> 

That's actually taking the long way around.  Gilles suggestion will 
actually save you time if you are looking to patch POV-Ray.

Post a reply to this message

In article <web.3edf071ec1329458541c87100@news.povray.org>, 
tom### [at] compsocmanacuk says...
> Speed and complexity (hence cost). Current cards (at the high end for games)
> can cost a couple of hundred dollars. Any simplification that can be made
> can save cost, and having a card that doesn't need to switch over from
> using triangles to drawing boxes halfway through a scene is good for
> efficiency.
Cost will always be high in the first of some new technology. This is a 
given. As for it changing the way it does things when it goes from a mesh 
to a box, any implementation would optimize this, assuming of course that 
calculating a single point on the surface of a triangle that is defined 
by three points is 'really' that incredibly different and calculating a 
point on the surface of a sphere or box. They both require very similar 
calculations. I am not sure how you would get a major change in speed due 
to what minor transition actually happens.

> I don't think a raytracer on a card
> designed for realtime game use has to solve exactly the same problems as a
> top-level raytracer for non-realtime use. In the same way that the Quake
> engine and 3D Studio aren't kin.
> 
Obviously, however neither you nor I know exactly what set of features or 
capabilities would really need or make sense to support, or even 
necessarily how. All I have is POV-Ray as an example of a top-level 
raytracer and stripped down to the bare bones it might be able to produce 
decent real time by itself in a 640x480 mode (maybe even in higher 
resolutions). However you would have to severely strip it down to do so. 
As it is, most of the time spent is parsing the SDL, which in the 3D card 
would be replaced by feeding it much more specific data that wouldn't 
require parsing. Even the bounding boxes could be pre-defined and 
supplied as part of the object. If you eliminate the #1 biggest time 
waster and then optimize for those features most useful in a real time 
game... Its not like there are a lot of examples of stuff like this 
people have written. I think there where a few that used such predefined 
objects and pre-calculated information to do real time demos for the 
Apple IIgs in the 80s and it managed a frame rate good enough for a 
simple game on a 2.5mhz system. Are you honestly telling me that someone 
couldn't do thousand times better on even a 500mhz machine, let alone a 
1ghz. And that is just running it as software.

The key issues are development time, cost of the product and 
backward compatibility. The last item being the only one that no one that 
wouldn't bury any attempt made right now to do it.

> >Well, that kind of describes most of the new cards that come out. lol
> >Yes, it would need compatibility with the previous systems, but that
> >isn't exactly an impossibility.
> 
> It is more difficult when you have completely changed the philosophy behind
> the card, but want it to remain compatible with the previous philosophy.
> You don't agree?
> 
Not necessarily. OpenGL structure for storing objects differs from POV-
Rays SDL for example, but the underlying data is more or less identical. 
You need a converter only because no native support exists to load such 
an object. If you designed a card, then you wouldn't likely be 
incorporating the ability to support the same structures as previous 
cards already use. There is no practical reason to not do so.

> >There is nothing to prevent using a second chip dedicated to processing
> >such things and having it drop the result into a block of memory to be
> >used like a 'normal' bitmap. This assumes that the speed increase gained
> >by building the rendering engine into the card wouldn't offset the time
> >cost of the procedural texture. In any case, there are ways around this
> >issue, especially if such methods turn out to already be in use on the
> >newer DirectX cards.
> 
> Then aren't you going to lose the advantage of generating textures on the
> card? If I generate a bitmap by procedure or by artist and subsequent
> loading, I must still store it. Newer cards do procedural shading on a
> pixel as it's rendered (or so I thought), so no extra storage is required.
> 
This contradicts you previous suggestion that somehow using such 
procedural systems is tied to complexity and the a bitmap has added 
advantages. If that is true, then there would be no reason to not simply 
generate a bitmap from the procedural texture and use it. Now you say 
this isn't needed, since newer cards already do what I said..?

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

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3edf9d90$1@news.povray.org...
>
>The question I'm perhaps asking is, has the time come for an open
source/free
>hybrid renderer? And if so, what's the most sensible route to it?

You could also consider adding raytracing to open source scanline renderers
such as Blender and OpenFX, which are after all already more suited to
animation (and particularly character animation) than POV-Ray since both
come with a native GUI modeller.

> It's a good idea, and I'd love to, but I'm afraid I don't have the time.

Well, what's the hurry ? We're talking raytracing after all, time is not an
issue ;)
Take 3-4 months off, play with the features, try to make nice pictures, show
them here. I certainly trust your competence as far as software development
per se is concerned, but I think that the objectives for such an ambitious
project will be much better defined if you get a first-hand knowledge of
what it is to work and develop real scenes with POV-Ray. Only then you'll
fully understand what the software can/cannot do, not from a theoretical
point of view but from a practical one.
There are lots of YARs (Yet Another Renderer) and YAMs (Yet Another
Modeller) out there and I wish the developers had taken the time to
understand what people needed before wasting their own time (and the time of
their users)...

G.


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

Post a reply to this message

Gilles Tran wrote:
> There are lots of YARs (Yet Another Renderer) and YAMs (Yet Another
> Modeller) out there and I wish the developers had taken the time to
> understand what people needed before wasting their own time (and the time of
> their users)...

*cough* Poser 5 *cough*

*snicker*

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

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

> Because the SDL is not always the preferred language.
> A person might have legacy code in another language,
> or prefer to use C++ because it's object oriented,
> or compiled code runs faster when object generation
> involves some complex process, etc. All else being
> equal, I'd rather write in C/C++ just because... I'm
> tired of having to type "#declare" every time I
> want to assign a value to a variable in SDL.

Try MegaPOV...IIRC, it includes my #set patch. Not exactly the same as 
in languages like C++, but an improvement.
Anyway, there are reasons for the current scene language. With one 
common scene language, everybody understands each other. And with that 
language under the control of the writers of the program, it can be 
designed specially for the job of scene description. I've done scenes in 
C++, and while great for complex algorithms, it is unwieldy for just 
describing a scene. On top of this, it reduces dependencies on platforms 
and external software packages...not everybody has a C++ compiler, and a 
text source file can be freely exchanged without worries about 
processors, OS's, languages, or compiler versions.

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

Tim Cook wrote:
> Gilles Tran wrote:
> 
>> There are lots of YARs (Yet Another Renderer) and YAMs (Yet Another
>> Modeller) out there and I wish the developers had taken the time to
>> understand what people needed before wasting their own time (and the 
>> time of
>> their users)...
> 
> 
> *cough* Poser 5 *cough*
> 
> *snicker*
> 
You appear to misunderstand Poser's primary application, it is not 
primarily a renderer and not a modeller at all.

Post a reply to this message

Jim Charter wrote:
> You appear to misunderstand Poser's primary application, it is not 
> primarily a renderer and not a modeller at all.

It's more the 'wishing the developers had taken the time to understand
what people needed before wasting their own time (and the time of their
users)' that brings Poser 5 to mind...version 4 was better.

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

In article <3ee00100@news.povray.org>, Jim Charter <jrc### [at] aolcom> 
wrote:

> You appear to misunderstand Poser's primary application, it is not 
> primarily a renderer and not a modeller at all.

I think that was actually in reference to the "I wish the developers had 
taken the time to understand what people needed before wasting their own 
time (and the time of their users)..." portion of the message.

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

Christopher James Huff wrote:
> I think that was actually in reference to the "I wish the developers had 
> taken the time to understand what people needed before wasting their own 
> time (and the time of their users)..." portion of the message.

Wow, is there an echo in here or what?! ;)

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> wrote in message
news:3edbd8cf$1@news.povray.org...
>
> > 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.

In general, when team members post here, unless they specifically
state that they are posting officially, what they say is their own
opinion. The team is a diverse group of individuals and we do not
always agree on all subjects ;)

-- Chris Cason
   POV-Team co-ordinator
   [speaking officially]

Post a reply to this message

On Thu, 5 Jun 2003 18:01:39 +0200, "Gilles Tran" <tra### [at] inapginrafr>
wrote:

>the developers. It's not a users vs developers game. The two latest members
>of the POV-Team (Nathan Kopp and Ron Parker) started out as patchers, took
>it on their own to add features that became extremely popular, maintained
>and supported complex multipatches for a while (thus demonstrating their
>goodwill and ability to interact with users) and were quickly "promoted" as
>developers.

And the Team's younger brother, the TAG, consists of a) famous POV
artists such as yourself, b) very active members of this server, such
as Uncle Ken and myself (back then...), and c) experienced POV users
with lots of programming skills, such as Warp and Chris Huff (and of
course the lines between a), b) and c) are blurred :) ). The
beta-testers were more or less of the same major breeds (elvish, human
and zombies, respectively :)) ). The influence of the user base on the
Team is tremendous.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Fri, 06 Jun 2003 09:27:07 -0400, Tim Cook <z99### [at] bellsouthnet>
wrote:

>Wow, is there an echo in here or what?! ;)

c:\echo
ECHO is on

That kinda explains it.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Sat, 7 Jun 2003 23:44:21 +1000, "Chris Cason"
<new### [at] deletethispovrayorg> wrote:

>...we do not always agree on all subjects ;)

What with Thorsten on the Team... :))


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message