On Wed, 15 Dec 2004 00:17:38 -0800, gonzo <rgo### [at] lansetcom> wrote:
> What's a BRDF?

Actually... there is not many unrollings of this acronym.

http://www.acronymfinder.com/af-query.asp?Acronym=BRDF

:-)

ABX

Post a reply to this message

news:cpnq4s$sj8$1@chho.imagico.de...

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

Other software call "fresnel" a shader that allow texture attribute to vary
according to the viewing angle of a 3D surface. Of course this is can be
done with POV-Ray for reflection and, for other properties, with the aoi
patch in Megapov (and it can be partially simulated in regular POV with
slope). I guess a future POV 4.0 could unify this with a single
property/keyword.

G.

-- 

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

Post a reply to this message

Gilles Tran wrote:
> 
> Other software call "fresnel" a shader that allow texture attribute to vary
> according to the viewing angle of a 3D surface.

In fact all shaders POV-Ray offers (although the term 'shader' is 
possibly misleading in case of a raytracer) except diffuse vary the 
color depending on the viewing angle.  It is the very definition of a 
diffuse surface that the appearance does not depend on the viewing 
angle.  The fresnel formulas specify a certain type of angle dependance 
which well describes the reflectance of an ideal specular surface and 
for this purpose it is used in POV-Ray.  To use it elsewhere, for 
example to vary the surface's own color pattern is possible (via aoi 
pattern) but would only serve artistic purposes without physical 
background so there isn't a predefined feature (like a fresnel waveform 
for use with aoi) in POV-Ray.

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

I think that the others here have just about covered the important points,
but I'm going to add my two cents a quarter and a nickel anyway.  It's
obvious to me that you didn't do your homework before posting this farce.

One of the first things you learn in English 101 - Or any english class
where writing is a major focus - is that you should always define your
abbreviations before you use them if they are not very commonly known.

For those of us here who don't know, but would like to, a BDRF is a
Bi-Directional Re-distribution function, and a quick search of the top hits
on Google will render more information.

That said:

I've been working with POV-Ray for about seven years now, but it's only
within the last four or so that I've begun to produce anything really
worthwhile, and, while I've never done it myself, I've seen others make
some remarkably realistic images with POV (HE Day's "Drunk Patrol" simply
blows my mind.)

In the future, it would be wise for you to research any topic you're going
to write about THOUROUGHLY, BEFORE you go making a horse's ass of yourself.

Regards,

ADB

Post a reply to this message

Anthony D. Baye wrote:
> 
> For those of us here who don't know, but would like to, a BDRF is a
> Bi-Directional Re-distribution function, 

Actually it is BRDF and it means Bi-Directional Reflectance Distribution 
Function.

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

Christoph Hormann <chr### [at] gmxde> wrote:
> Anthony D. Baye wrote:
> >
> > For those of us here who don't know, but would like to, a BDRF is a
> > Bi-Directional Re-distribution function,
>
> Actually it is BRDF and it means Bi-Directional Reflectance Distribution
> Function.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 23 Sep. 2004 _____.//^>_*_<^/.______

Yeah, that sounds right.  I kept backing out of the posting area by
accident, I guess in my frustration I got it Garbled.  Sorry.

ADB

Post a reply to this message

"Jim Charter" <jrc### [at] msncom> wrote in message 
news:41bfafa3$1@news.povray.org...
> Thorsten Froehlich wrote:
>
>>
>> I will give you the benefit of the doubt and assume you are just clueless
>> and not a troll.
>>
>
> Blink
>


Ever see Star Trek episode where the Klingons insult the Enterprise in front 
of Scotty?

Post a reply to this message

In article <41c1100c$1@news.povray.org> , "Greg M. Johnson" 
<gregj;-)565### [at] aolcom> wrote:

> Ever see Star Trek episode where the Klingons insult the Enterprise in front
> of Scotty?

Ah, The "The Trouble With Tribbles" episode...

    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

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


With all of these ideas I can hardly wait to see you patch to compare it to
the official POVRay. I am just assuming that you would back up this post
with real code applied to a patch for all of us to see you ideas in action.

Post a reply to this message

>
> With all of these ideas I can hardly wait to see you patch to compare it
to
> the official POVRay. I am just assuming that you would back up this post
> with real code applied to a patch for all of us to see you ideas in
action.
>
>

Ah, that's just a wee bit unfair. Sort of like asking a director to perform
as well as an award winning actor. The director can sort of say what the
actor should be doing, but only the actor can pull it off. (sorry for a bad
analogy).

Now if you have a problem with the theories and ideas presented by the
poster, say so (as others already have). But saying the theories and ideas
are bad because the poster can't implement them is rather wrong.

Post a reply to this message