Gilles Tran <gil### [at] agroparistechfr> wrote:
> The 
> ability to write i++ instead of i=i+1 is not going to make better pictures. 
> Improving the rendering engine will.

  I don't remember seeing even one single post suggesting some concrete
rendering algorithm idea which could be implemented in povray.

  It's easy to say "povray should have more rendering algorithms", much
harder to actually present hard data and concrete proposals about what
and how exactly.

-- 
                                                          - Warp

Post a reply to this message

Ross <rli### [at] speakeasynet> wrote:
> for example, this one could
> rock my socks off:

> "render translucent objects with heterogeneous scattering properties"
> http://www.pbrt.org/gallery/dragon_subsurf.png

  The algorithm used to create that picture might be cool and all, but
somehow that precise example picture doesn't excite me a lot. It somehow
fails to look photorealistic.

-- 
                                                          - Warp

Post a reply to this message

471e47bd@news.povray.org...
> Gilles Tran <gil### [at] agroparistechfr> wrote:
>> The
>> ability to write i++ instead of i=i+1 is not going to make better 
>> pictures.
>> Improving the rendering engine will.
>
>  I don't remember seeing even one single post suggesting some concrete
> rendering algorithm idea which could be implemented in povray.

My point exactly :) With all the developers currently discussing the future 
of POV-Ray, the major selling point of a renderer (i.e. rendering quality) 
is mysteriously absent. And when one person dares showing up with some 
interesting ideas and a working piece of software, the poor guy gets told 
off because he *** gasp *** made the mistake of pressing twice on the send 
key.

Really, rendering algorithms are all over the place these days and 
implemented in many renderers, free or commercial.
http://www.amazon.com/exec/obidos/tg/detail/-/012553180X/qid=1080621276/sr=8-1

Implementing them is certainly challenging, but finding interesting 
algorithms and looking at their various practical implementations is not.

G.

Post a reply to this message

Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> >  I don't remember seeing even one single post suggesting some concrete
> > rendering algorithm idea which could be implemented in povray.

> My point exactly :)

  I don't think you meant that point with the same meaning as I did...

> With all the developers currently discussing the future 
> of POV-Ray, the major selling point of a renderer (i.e. rendering quality) 
> is mysteriously absent. And when one person dares showing up with some 
> interesting ideas and a working piece of software, the poor guy gets told 
> off because he *** gasp *** made the mistake of pressing twice on the send 
> key.

  I think POV-Ray needs new algorithms which will make it produce prettier
pictures *faster*, not slower. You said it yourself that the algorithms used
in that program may produce cool results, but you could take a trip around
the world in a boat before the image is ready.

  I'm not saying POV-Ray couldn't benefit from this. I'm saying that POV-Ray
would benefit *more* from algorithms which make it faster, and thus they
should have a higher priority.

> Implementing them is certainly challenging, but finding interesting 
> algorithms and looking at their various practical implementations is not.

  As I said, it's easy to suggest all kinds of features, but there doesn't
seem to be many volunteers for actually doing the hard work of studying the
algorithms and presenting some concrete proposals on how to embed them in
POV-Ray.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:471e4849@news.povray.org...
> Ross <rli### [at] speakeasynet> wrote:
> > for example, this one could
> > rock my socks off:
>
> > "render translucent objects with heterogeneous scattering properties"
> > http://www.pbrt.org/gallery/dragon_subsurf.png
>
>   The algorithm used to create that picture might be cool and all, but
> somehow that precise example picture doesn't excite me a lot. It somehow
> fails to look photorealistic.
>
> -- 
>                                                           - Warp

If you're simply saying that it is obviously computer generated, who cares?

So ignore the picture and think of the possibilities. I do think the image
is exciting precisely because the way it's rendered, it looks like some sort
of crystal that has been crushed, cracked or has impurities in it. I don't
know of an easy way to do that to an arbitrary object in povray. Do you? If
so, i'd like to see an example.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:471e6858@news.povray.org...
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> > >  I don't remember seeing even one single post suggesting some concrete
> > > rendering algorithm idea which could be implemented in povray.
>
> > My point exactly :)
>
>   I don't think you meant that point with the same meaning as I did...
>
> > With all the developers currently discussing the future
> > of POV-Ray, the major selling point of a renderer (i.e. rendering
quality)
> > is mysteriously absent. And when one person dares showing up with some
> > interesting ideas and a working piece of software, the poor guy gets
told
> > off because he *** gasp *** made the mistake of pressing twice on the
send
> > key.
>
>   I think POV-Ray needs new algorithms which will make it produce prettier
> pictures *faster*, not slower. You said it yourself that the algorithms
used
> in that program may produce cool results, but you could take a trip around
> the world in a boat before the image is ready.
>
>   I'm not saying POV-Ray couldn't benefit from this. I'm saying that
POV-Ray
> would benefit *more* from algorithms which make it faster, and thus they
> should have a higher priority.

Would it? Has research been done? Or is this just, as Colbert says,
truthiness?

Even while computers continue to get faster and cheaper?

As a hypothetical example, what if media was ommited from 3.5 becaues it was
too slow? Think of all the nice pictures we would have missed. Here we would
be still using 3.1's implementation. Or we would be elsewhere using
something else.

Yet people dealt with the slowness because it helped improve scenes.

>
> > Implementing them is certainly challenging, but finding interesting
> > algorithms and looking at their various practical implementations is
not.
>
>   As I said, it's easy to suggest all kinds of features, but there doesn't
> seem to be many volunteers for actually doing the hard work of studying
the
> algorithms and presenting some concrete proposals on how to embed them in
> POV-Ray.
>
> -- 
>                                                           - Warp

Post a reply to this message

On Tue, 23 Oct 2007 17:56:50 -0400, Ross wrote:

> Would it? Has research been done? Or is this just, as Colbert says,
> truthiness?
> 
> Even while computers continue to get faster and cheaper?
> 
> As a hypothetical example, what if media was ommited from 3.5 becaues it
> was too slow? Think of all the nice pictures we would have missed. Here
> we would be still using 3.1's implementation. Or we would be elsewhere
> using something else.
> 
> Yet people dealt with the slowness because it helped improve scenes.

Yes, as a user myself, speed isn't the only factor, quality is a huge 
factor as well, and there is a logical tradeoff between the two.

That doesn't mean faster algorithms that create the same quality are bad, 
of course - and doesn't mean the slowest algorithm to produce a given 
quality should be preferred (of course it shouldn't), but speed isn't my 
only criteria for selection of a tool.

Jim

Post a reply to this message

Ross <rli### [at] speakeasynet> wrote:
> As a hypothetical example, what if media was ommited from 3.5 becaues it was
> too slow? Think of all the nice pictures we would have missed. Here we would
> be still using 3.1's implementation. Or we would be elsewhere using
> something else.

  OTOH other renderers succeed in creating the same and even better media
effects much faster than POV-Ray...

-- 
                                                          - Warp

Post a reply to this message

In article <471e6c37@news.povray.org>, rli### [at] speakeasynet says...
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:471e4849@news.povray.org...
> > Ross <rli### [at] speakeasynet> wrote:
> > > for example, this one could
> > > rock my socks off:
> >
> > > "render translucent objects with heterogeneous scattering properties"
> > > http://www.pbrt.org/gallery/dragon_subsurf.png
> >
> >   The algorithm used to create that picture might be cool and all, but
> > somehow that precise example picture doesn't excite me a lot. It someho
w
> > fails to look photorealistic.
> >
> > -- 
> >                                                           - Warp
> 
> If you're simply saying that it is obviously computer generated, who care
s?
> 
> So ignore the picture and think of the possibilities. I do think the imag
e
> is exciting precisely because the way it's rendered, it looks like some s
ort
> of crystal that has been crushed, cracked or has impurities in it. I don'
t
> know of an easy way to do that to an arbitrary object in povray. Do you? 
If
> so, i'd like to see an example.
> 
Besides. I am not sure its the dragon that is the problem with that 
image, but the background. Move it a bit farther from the viewer and 
stick it on a more believable background...


-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

>> for example, this one could
>> rock my socks off:
> 
>> "render translucent objects with heterogeneous scattering properties"
>> http://www.pbrt.org/gallery/dragon_subsurf.png
> 
>  The algorithm used to create that picture might be cool and all, but
> somehow that precise example picture doesn't excite me a lot. It somehow
> fails to look photorealistic.

This one looks much better IMO:

http://www.pbrt.org/gallery/01F12.jpg

Post a reply to this message