"scott" <sco### [at] laptopcom> wrote in message news:471ef1fb@news.povray.org...
> >> 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
>

As a composition, I'd agree. And the material is nice. It was the
"heterogeneous scattering" that got me though.

Post a reply to this message

471e6858@news.povray.org...
>  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.

That's true, but after having tested the Maxwell demo, I came to believe 
that this technology was what raytracing was 15 years ago: slow, immature, 
but vastly superior (quality-wise) to the competition. It's also extremely 
simple to use. Now I'm not saying that all development effort should be put 
on unbiaised rendering, just that it's an example of the things that should 
be looked at very closely. For instance, one thing I found particularly 
impressive (and remarkably efficient) in Maxwell is that material 
definitions are based on physical parameters rather than on the traditional 
channel paradigm (can't explain more, but the manual is on line IIRC).

In short, there's really a lot of cool stuff out there (and I'm using a 
bunch of them in FinalRender), and that is worthy of discussion. One 
exciting, attractive aspect (for artists and developers alike) of POV-Ray 10 
years ago was that it was innovative. Isosurfaces, photon mapping, radiosity 
were new, fantastic features. A new version of POV-Ray should be innovative 
when it comes to rendering technology.

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

There are lots of people working (for free) on other renderers using these 
algorithms, so the workforce is here. Now, how to make them work for POV-Ray 
is a matter of good diplomacy...

G.



G.

Post a reply to this message

Gilles Tran wrote:
> For instance, one thing I found particularly 
> impressive (and remarkably efficient) in Maxwell is that material 
> definitions are based on physical parameters rather than on the traditional 
> channel paradigm (can't explain more, but the manual is on line IIRC).
> 

Yes, that's definitely one thing that I would like to see in a free 
renderer. Finally go away from the RGB space... And being able to output 
that would be nice as well.

-- 
Vincent

Post a reply to this message

scott wrote:
> This one looks much better IMO:
> http://www.pbrt.org/gallery/01F12.jpg

I want to know how you copy a shape like that, myself. :)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote:
> There are lots of people working (for free) on other renderers using these
> algorithms, so the workforce is here. Now, how to make them work for POV-Ray
> is a matter of good diplomacy...

PBRT is very nice, source-wise (and the book is immensely useful). It does
support conventional raytracing if I remember rightly, it doesn't have to
run unbiased. I don't know if that applies to this fork.

I'm waiting until the 3.7 source is made available before deciding whether
or not to continue with POV. The main things that keep me using it now
(apart from invested time) are that the SDL allows me to make a reasonable
scene without having to involve Blender, and that I still think media is
pretty unique.

Tom

Post a reply to this message

"Gilles Tran" <gil### [at] agroparistechfr> wrote:

> For instance, Maxwell has a feature
> where one can change the lighting setup *** after *** rendering so that one
> can test various lighting situations in real time.
> That's really something worth investigating for POV-Ray 4. IMHO this is
> much, much more important than SDL.

> G.

You are raising quite a good point. I do not know how it is done either, but
the way I’d do it is to save all of the info in separate places, much
like layers in 2d editing. So, store ray-object intersection in the bottom
layer, then pigment on another, normals on yet another, light on a fourth
etc. Currently POV outputs the “flattened” picture, but if it
returned the various elements instead, or simply gave access to them, one
could try some weird effects very easily (for example swapping the normals
layer with ambient layer). But most useful would be to alter the values on
one layer by simple multiplication, e.g picture is rendered and ambient
layer contains values fit for an ambient of 0.6, multiply layer’s
values by 1/0.6 to get the ambient 1 layer. The result would be practically
instantaneous, with no need to re-render the whole pic. Or one could alter
the light position and other settings and  only update the light-related
layers, without need for recalculating everything else. It could be truly
useful in cutting down the time spent waiting for test renders to finish.

*Wakes up* :-/

Still, a beautiful dream.

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

I personally want quality. And easy-to-distribute radiosity. If I want 
speed I can use my renderfarm. Radiosity is unusable on it, you know 
what happens if you render an image in tiles with (current) POV-Ray 
radiosity: brightness differences between tiles.

Post a reply to this message

"Grassblade" <nomail@nomail> wrote:
> "Gilles Tran" <gil### [at] agroparistechfr> wrote:
>
> > For instance, Maxwell has a feature
> > where one can change the lighting setup *** after *** rendering so that one
> > can test various lighting situations in real time.

ah!  so that is what that Flash intro is all about...

I wonder if that has anything to do with it being unbiased or, more likely,
with High Dynamic Range or caching mechanisms...

> > That's really something worth investigating for POV-Ray 4. IMHO this is
> > much, much more important than SDL.

povray's SDL is the main feature that povray has to offer me.  There are far
better/faster renderers out there, some with lots more features and
workforce.  None has the simplicity and expressiveness of povray's SDL
format.

I really, really wanted to go the Renderman way, but RIB is unbearably
annoying and C/C++ for modelling is overkill...

> You are raising quite a good point. I do not know how it is done either, but
> the way I’d do it is to save all of the info in separate places, much
> like layers in 2d editing. So, store ray-object intersection in the bottom
> layer, then pigment on another, normals on yet another, light on a fourth
> etc. Currently POV outputs the “flattened” picture, but if it
> returned the various elements instead, or simply gave access to them, one
> could try some weird effects very easily (for example swapping the normals
> layer with ambient layer).

interesting.

> *Wakes up* :-/
>
> Still, a beautiful dream.

in order to turn into reality, we need developers, a roadmap and plenty of
algorithms... a benevolent dictator for life wouldn't do bad, either... :)

and a good-looking SDL as well! :D

Post a reply to this message

BTW, this looks completely smooth:
http://www.luxrender2.org/images/gallery/prius.jpg

:)

Post a reply to this message

nemesis wrote:
> BTW, this looks completely smooth:
> http://www.luxrender2.org/images/gallery/prius.jpg

The yellow car as seen thru the windshield of the dark car is far from 
completely smooth. :-) Altho that might just be the jpeg compression or 
something, but it looks more like error diffusion or just a bad algorithm.

(And the seats, but that could be the fabric pattern.)

I dunno. That one just looks really fake to me. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message