 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3edb7069$1@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphics com> wrote:
> I have considered that. I was about to write
> or modify a RIB renderer, for example.
> But I wasn't aware of the camera statement
> flexibility per se; thanks. If the POV-Team
> didn't mind me copying their parser code,
> the argument for doing a new app would
> certainly be better advanced. POV also
> has all the other infrastructure, such
> as texture file loading, in one nice spot.
A simple look at the license would tell you that you can only use the
source for a custom version of POV-Ray, and it must only add to the
functionality of the program (you can't remove the raytracer). Aside
from this, the parser would not be that useful to you: it builds the
entire scene in memory for the raytracer to render, changing it to do
something else for your scanliner would require rewriting huge amounts
of it (like pretty much all the code handling objects).
> I believe POV's future lies in being a more powerful platform for
> creating 3D graphics in general, not just as a raytracer.
The future of the Persistance Of Vision Raytracer is to be a scanline
renderer?
> For all I know, this experiment
> may one day lead to POV-Ray becoming the dominant
> film production tool for CG effects, and enable
> a whole new population of movie producers.
Why? That's not the goal of POV, and there are already tools for those
jobs. POV is primarily a hobbyist tool, and is oriented more for complex
stills with extremely realistic effects.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What *are* your purposes? You still haven't explained this.
I have several. Myself, I just want to draw landscapes
how I want. My company would like to provide end users
with a standalone renderer (preferably one they already
know and use) that can do landscapes more efficiently
and with procedural shaders.
I like displacement mapping, and it appears to be a
lot easier and faster with scanline rendering. Or at
least, I know how to do it that way here and now,
which is more expedient than trying to figure out
how to get a raytracer to do it. Besides, POV doesn't
handle procedural shaders anyway... that's another
thing I'd add. That'll make it a totally custom patch,
but that's alright. And down the road, I'd like
to get into film production, but I don't feel
like shelling out for PrMan when I'm perfectly
willing to study and write code, and perhaps there are
others who feel the same. And making something like
that available to everyone has a nice feel to it.
Maybe it won't be based on POV in the end, but
right now, to have something I can experiment with,
using POV saves me a ton of time. If it also happens
to let people test what POV would be like with
such features, that's a useful bonus, even if in
the end the majority thinks it isn't worthwhile.
> What do shaders have to do with the number of shapes?
It's the way I write some of my shaders. I generate lots of geometry.
e.g., a fractal cubeflake has lots of cubes in it. It's a crude
approach, I guess, but it works, and it's way easy to do.
The same reason some people use shadeops in Renderman
instead of SL.
> > For shapes like hair strands and grass blades,
> > however, supporting a spline (rope?) primitive
> > should be done.
>
> And what does this have to do with scanlining?
They'd draw faster scanlined and take less memory.
> Simple: Make a few dozen variations of tree meshes and plant a few tens
> of thousands (or more if you like) on the landscape. Blobs and
> isosurfaces can make good rocks, or you could use meshes for those too.
> And when viewed from a sufficient distance, a noisy isosurface can make
> a good bush.
Cool. But I'd rather not take up the memory,
even if it's just pointers, and, well --
I just don't like using isosurfaces. I think they're
very neat, but they're not my cup of tea.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The future of the Persistance Of Vision Raytracer is to be a scanline
> renderer?
No, I wouldn't dream of replacing the raytracer
functionality. Having both raytracing and scanline
code is more desirable.
> Why? That's not the goal of POV, and there are already tools for those
> jobs. POV is primarily a hobbyist tool, and is oriented more for complex
> stills with extremely realistic effects.
What are POV's goals, actually? Does the
POV-Team have a specific mission statement
in mind, or do they incrementally review
and adjust the code on a as-things-crop-up basis?
Is POV a renderer (method unimportant) or
a raytracer? Is the goal to produce graphics
or specifically to raytrace?
It does have an animation feature. The thing
to ask is, does that feature exist solely
to do raytraced animations, was it an after-thought
to placate people who wanted to make short clips,
is it there just to augment film producers'
other footage generators, or is it a core
feature to let POV evolve towards doing
full production film work?
When one considers the scripting and anim features
combined, it's pretty powerful. For something
that isn't meant to do movies, it's also
pretty compelling in that sense. It seems almost
a shame not to leverage that.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3edcd7d5$1@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphicscom> wrote:
> One difficulty I have with doing that is that
> sometimes its easier to drive a shader using
> some stepped coordinate system of the primitive rather
> than the world locations a raytracer returns.
What stops you from doing the same thing with raytracing? What makes you
think you can only compute world coordinates?
> For example, when scanlining a heightfield,
> I do it cell by cell, so rocks can be distributed
> based on how likely a cell is to be occupied.
> With raytracing, I have to derive the cell
> coords, and then maintain some kind of map
> to keep track of which cell was painted with what.
No you don't...why would you do this? You're just scattering rocks
around. Just use trace() to place them on the surface at random
locations. If you want an uneven distribution, use some function to
control the probability of a rock landing.
> Displacement shading is also easier when scanlining.
> At least, I haven't figured an easy way to do it
> when raytracing.
Sounds like you're talking about something like this:
http://www.cs.utah.edu/~bes/papers/height/paper.html
There is a landscape example with the equivalent of 1,000,000,000,000
triangles. And instead of generating and discarding millions (or
billions) of unused microtriangles, it generates them as needed.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
