 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pov-Ray is lagging farther and farther behind commercial rendering software
in terms of photo-realism. There are many reasons why this is the case,
but some reasons are more evident and more easily solved than others.
1. The phong model is outdated now. The next release of pov-ray should
use physically-based BRDFs, and only keep the phong model around for
compatability. Phong makes everything look like plastic, including what we
have been calling "glass". The difference between pov-ray glass and
physically-based glass in other packages is STRIKING. Real glass has a
fresnel effect, where shallow-angled light reflected from the surface tends
more towards a perfect mirror. This also happens in real life. My
suggestion is allow BRDFS for those who need them, and base the
documentation around the Phong model as usual.
2. Pov-ray does not have hair, fuzz, fur, or suede textures. Brushed metal
would be nice also. And car paint too... I won't ask for
subsurfacescattered flesh just yet, it tends to be very time-consuming to
implement. There are many textures out there that can only be implemented
using path-tracing techniques, such as very shiney, partially-reflective
gold. A few others are glossy reflections (blurred reflections) and
frosted glass.
3. Povray uses distributed ray-tracing to simulate global illumination.
Reflected parts of the scene do not have the radiosity calculation
performed on them. I have found this to be highly frustrating. (Simply
create a radiosity room and stick a large reflecting ball in the middle to
see what I mean.) The speed-ups to this method leave even the most
advanced users scratching their heads. Ive been using pov-ray since it was
named DKB-Trace, and honestly, I'm still not sure that "minimum_reuse"
means under the radiosity settings. If you think about what distributed
ray-tracing does, you will notice it works by tracing rays into DARK PARTS
of the scene, hoping for a swath of light. It doesnt take a professor to
realize that this is a wasted calculation. Tracing a ray into a dark part
of the scene will mathematically never make a difference in the shaded
pixel. There are methods which make an unhappy marriage between photon
shooting and "gathering" from those shoots in a way based off of importance
sampling. By making the algorithm more complex, it tends to avoid WASTED
CALCULATIONS. Also, these bi-directional algorithms (as they are called)
make the settings for the end-user very simple. So we need not worry that
more complex algorithms will "confuse the end-user even more".
4. There are other physically-based methods out there that turn ray-tracing
on its head. I pretty much expect future versions of Pov-ray to move away
from the phong model (part 1) and implement a few BRDFs for popular
surfaces, but other methods would be nice to see also, which I have less
faith in. There are ways to calculate light in rendering in which you do
not even use RGB color space. These algorithms use spectral integration,
and create a large picture out of pixels that are colored with the
SPECTRUM, rather than RGB triples. This kind of rendering allows you to
specify the wattage of incandescent lightbulbs, or even simulate flash
bulbs from particular cameras. REALISTIC SUNLIGHT, of course, is the
biggest pay-off to this method. Other freeware packages on the web that
attempt to do this are usually written by a single busy person, and they
are hopelessly buggy or just plain do not work. This is the reason I have
come to this board to make this suggestion. Pov-ray is the most robust and
stable free rendering software in the world.
5. Even without spectral integration, you can render in RGB space and still
do EXPOSURE simulations. (Usually its the case that exposure simulation is
not used unless a certain amount of "energy" is calculated to be passing
through the cameras' aperture, but it can be done ad hoc in RGB space also,
by fanagling.) This basically works by storing floating point triples into
each pixel, none of which are CLIPPED or "tuned down" to fit into 0.0 -->
1.0. The idea is that even in the wide amplitude of real light, you
always want your display adapter to use its contrast ratio to its maximum.
A pass is performed over this final image, the workings of which are
controlled by the user. The plugin that someone made to simulate this is
not robust enough. The user must be allowed to map directly to floating
point triples, and then "slide" this window around on an image whose
contrast ratio is much larger than 0.0 to 1.0. Automatically
"stretching" the mapping to fit the entire contrast of the triples is not
always what you want.
--
Paris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Dec 2004 16:13:34 EST, "Paris" <par### [at] lycos com> wrote:
> Pov-Ray is lagging farther and farther behind commercial rendering software
> in terms of photo-realism.
I'm sure others will quickly respond to the other aspects but I'm curious how
did you measured "farther and farther". Was there less cinema movies this year
than last year made with POV-Ray? Was there less posters sold in zazzle made
with POV-Ray than last year? What _exactly_ was background for your statement.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SNIP
Interesting in-depth analysis. Not that many of the things were covered in
various threads, but this sums up a few things rather nicely. Nontheless, if
you hadn't noticed: many of these things are gradually making their way into
POV-Ray via MegaPOV, POV-Man (I think that's the one with
Renderman-Shader-Compability, right?) and other patches. Once they've been
thoroughly tested, they find their way into the official version. That was
the case with some of the media methods, isosurfaces etc.
Another thing you have to note is that though some things aren't possible
with POV-Ray within a reasonable timeframe, others can be made possible with
the right amount of patience and POV-SDL. Have a look at Jaimes Vives
Piquere's Macros for nice light-setups.
Overall, I'd just place my 2 cents and say that POV-Ray never worked under
any outside pressure, it just did what the POV-Team and the Community liked.
If there's someone capable of implementing prompt subsurface-scattering,
someone will eventually code it. Still, there's only so much you can do if
you want to stay true to the raytracing-technique and not make use of
several faking techniques to simulate one effect or another (e.g. I'd count
sprite-lensflares to such faking effects).
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paris wrote:
> Pov-Ray is lagging farther and farther behind commercial rendering software
> in terms of photo-realism.
If you get paid for saying things like this that might be an excuse -
apart from that you are making a complete fool of yourself with what you
wrote. Everything you write demostrates you have now idea of the inner
workings of POV-Ray and try to write something sounding superficially
intelligent from some basic things you might have read in a bad book or
a 1st semester college course.
If you just want to rant please move to .off-topic. This group is for
serious discussion and not for baseless claims.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paris <par### [at] lycoscom> wrote:
> Pov-Ray is lagging farther and farther behind commercial rendering software
> in terms of photo-realism.
You get what you pay for, pal.
> 1. The phong model is outdated now.
You can do quite pretty stuff with povray's fresnel highlights and
variable reflection. It may require some fine-tuning by hand, but
I wouldn't call it so "outdated".
> 2. Pov-ray does not have hair, fuzz, fur, or suede textures. Brushed metal
> would be nice also. And car paint too...
Please post the algorithms on how they are done with raytracing and
I'm sure they will find their way into povray.
> There are many textures out there that can only be implemented
> using path-tracing techniques, such as very shiney, partially-reflective
> gold. A few others are glossy reflections (blurred reflections) and
> frosted glass.
Although not trivial, you can do blurred reflections and refractions
(using stochastic raytracing) with the current povray. It's not even
hopelessly slow.
> Reflected parts of the scene do not have the radiosity calculation
> performed on them.
Not true. Are you using POV-Ray 3.1 or something?
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I won't waste my time dissecting everything written in this posting but
in case there are people here who consider taking this posting as a
valuable statement i will as an example analyze the first point:
>
> 1. The phong model is outdated now.
It is not clear what is actually meant with "phong model" here but it
has to be assumed it is the method of calculating specular highlights
introduced by Phong (this is the only feature related to the name Phong
that exists in POV-Ray). Now the above statement is certainly not true
since this technique is frequently used by artists (and not only in
POV-Ray of course).
> The next release of pov-ray should
> use physically-based BRDFs, and only keep the phong model around for
> compatability.
This implies POV-Ray's use of the "phong model" (see above) is more than
one feature of many that can be used or not used which is not the case.
What "physically-based BRDFs" are is not explained and neither why the
"phong model" and other techniques in POV-Ray are not physically-based.
> Phong makes everything look like plastic, including what we
> have been calling "glass".
This is obviously wrong but even if it wasn't this would not be a very
valuable statement (like 'using red light makes everything red').
> The difference between pov-ray glass and
> physically-based glass in other packages is STRIKING.
This is pointless without examples (and of course wrong - i have seen
dozens of very realistic glass renders made with POV-Ray).
> Real glass has a
> fresnel effect, where shallow-angled light reflected from the surface tends
> more towards a perfect mirror.
Ah - a new name: Fresnel. Last time i checked this was a reserved
keyword in POV-Ray so there has to be some feature related to Mr. Fresnel...
> This also happens in real life. My
> suggestion is allow BRDFS for those who need them, and base the
> documentation around the Phong model as usual.
The use of the word 'BRDF' is strange here - the "phong model" (if meant
as explained above) is a BRDF as well. Apart from that the idea to
introduce a new feature ("allow BRDFS" - whatever this should mean) but
not document it is just ridicuous.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.41bf577e1db2d3fb765651f90@news.povray.org> , "Paris"
<par### [at] lycoscom> wrote:
> Pov-Ray is lagging farther and farther behind commercial rendering software
> in terms of photo-realism. There are many reasons why this is the case,
> but some reasons are more evident and more easily solved than others.
I will give you the benefit of the doubt and assume you are just clueless
and not a troll.
> 1. The phong model is outdated now. The next release of pov-ray should
> use physically-based BRDFs, and only keep the phong model around for
> compatability. Phong makes everything look like plastic, including what we
> have been calling "glass". The difference between pov-ray glass and
> physically-based glass in other packages is STRIKING. Real glass has a
> fresnel effect, where shallow-angled light reflected from the surface tends
> more towards a perfect mirror.
I would suggest to RTFM before making false statements about available
features in POV-Ray...
<http://www.povray.org/documentation/view/3.6.1/348/>
> 2. Pov-ray does not have hair, fuzz, fur, or suede textures. Brushed metal
> would be nice also. And car paint too... I won't ask for
> subsurfacescattered flesh just yet, it tends to be very time-consuming to
> implement. There are many textures out there that can only be implemented
> using path-tracing techniques, such as very shiney, partially-reflective
> gold. A few others are glossy reflections (blurred reflections) and
> frosted glass.
Again, maybe you should RTFM. And brushed metal, well, can it get more
brushed than
<http://news.povray.org/povray.binaries.images/thread/%3Cweb.419777b7897a5e5
4b0aac12c0@news.povray.org%3E/>?
Apart from that, you do realise that hair and fur are not textures, right?
And car paint, how did you get the idea POV-Ray cannot render something as
trivial as car paint, which is hardly anything else but paint?
> 3. Povray uses distributed ray-tracing to simulate global illumination.
Distributed ray-tracing is a supersampling technique (antialiasing), so it
has nothing to do with global illumination.
> Reflected parts of the scene do not have the radiosity calculation
> performed on them. I have found this to be highly frustrating. (Simply
> create a radiosity room and stick a large reflecting ball in the middle to
> see what I mean.) The speed-ups to this method leave even the most
> advanced users scratching their heads. Ive been using pov-ray since it was
> named DKB-Trace, and honestly, I'm still not sure that "minimum_reuse"
> means under the radiosity settings.
Clearly you have not, otherwise you would know that POV-Ray's radiosity was
added in POV-Ray 3.0 many years after DKB-Trace. And if you cannot use it,
well, it certainly ain't trivial but that _you_ cannot use it hardly says
anything about POV-Ray's quality but only about _your_ abilities. And given
your other statements so far, I have serious doubts in those...
> If you think about what distributed
> ray-tracing does, you will notice it works by tracing rays into DARK PARTS
> of the scene, hoping for a swath of light. It doesnt take a professor to
> realize that this is a wasted calculation. Tracing a ray into a dark part
> of the scene will mathematically never make a difference in the shaded
> pixel.
No clue probably defines your statement best, POV-Ray "radiosity" is a Monte
Carlo ray-tracing technique, so how you got the idea that it has anything to
do with sampling dark areas of a scene is beyond me. The algorithm
implemented is based on "A Ray Tracing Solution for Diffuse Interreflection"
by Ward, Rubinstein, and Clear in the Siggraph 1988 Proceedings.
> 4. There are other physically-based methods out there that turn ray-tracing
> on its head.
Ah, you mean the "real-world"? Sure, that will always be better than
ray-tracing.
> I pretty much expect future versions of Pov-ray to move away
> from the phong model (part 1) and implement a few BRDFs for popular
> surfaces, but other methods would be nice to see also, which I have less
> faith in. There are ways to calculate light in rendering in which you do
> not even use RGB color space. These algorithms use spectral integration,
> and create a large picture out of pixels that are colored with the
> SPECTRUM, rather than RGB triples.
You do realise the cost of using a non-RGB implementation? There is a
reason why there are special programs that allow exact simulation of the
wave effects of light. Unless you need it, POV-Ray can simulate the effect
just like all "professional" rendering software does. I guess in all your
cluelessness you are talking about dispersion, so maybe RTFM
<http://www.povray.org/documentation/view/3.6.1/415/>.
> 5. Even without spectral integration, you can render in RGB space and still
> do EXPOSURE simulations. (Usually its the case that exposure simulation is
> not used unless a certain amount of "energy" is calculated to be passing
> through the cameras' aperture, but it can be done ad hoc in RGB space also,
> by fanagling.) This basically works by storing floating point triples into
> each pixel, none of which are CLIPPED or "tuned down" to fit into 0.0 -->
> 1.0.
I believe you want HDR image output. There is a not a standard format for
that, but your talk about floating-point RGB values clearly shows you know
exactly nothing about what you are talking about. And no, I will not bother
to explain.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:41bf6e0c$1@news.povray.org...
> In article <web.41bf577e1db2d3fb765651f90@news.povray.org> , "Paris"
> <par### [at] lycoscom> wrote:
>
snip
> Again, maybe you should RTFM. And brushed metal, well, can it get more
> brushed than
>
<http://news.povray.org/povray.binaries.images/thread/%3Cweb.419777b7897a5e5
> 4b0aac12c0@news.povray.org%3E/>?
>
yeah, that's a freakin awesome texture, by the way.
> Apart from that, you do realise that hair and fur are not textures, right?
> And car paint, how did you get the idea POV-Ray cannot render something as
> trivial as car paint, which is hardly anything else but paint?
>
I can only assume he means paint that appears different based on the angle
with which it is viewed. Someone did a *very* nice animation exhibiting this
in p.b.animations a while back. I'm not sure what version of POV or patches
it used though. It was exactly car paint though. I can't find it now though
:/
-ross
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> I will give you the benefit of the doubt and assume you are just clueless
> and not a troll.
>
Blink
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paris wrote:
> Pov-Ray is lagging farther and farther behind commercial rendering software
> in terms of photo-realism. There are many reasons why this is the case,
> but some reasons are more evident and more easily solved than others.
>
> 1. The phong model is outdated now. The next release of pov-ray should
> use physically-based BRDFs
Ok, I'll leave it to the technical whiz types to disassemble the rest of
this, 'cause you already lost me...
What's a BRDF?
Bouncing Recalcitrant Damn Fool?
Blonde Receptionists Dating Foundation?
Business Requirements Driving Failure?
Blatantly Ridiculous Dumb Fluff?
Bush Regime's Dastardly Fixation?
Bored Reactionary Dropping FUD?
Blue Rhinoceros Drinking Floorwax?
Bucolic aRDvaark Fainting?
Belatedly Realized Dangerous Flatulence?
RG - dammit Jim, I'm an artist not a rocket scientist
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
