 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not going to do the obvious - it seems it's been done to death already -
so instead I wanted to suggest something which could be improved in POVRay,
I expect very simply. Maybe there is a plugin/macro or something to do
this already (I'm a bit new...) but I would like to see something like
this:
diffuse { bozo ... }
specular { image_map ... }
i.e. different mapping on different texture channels. Using multiple
channels of proper texturing, rather than layers, this would make it
possible to achieve some incredible images.
Just 2p to add...
L
-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Loki wrote:
> Maybe there is a plugin/macro or something to do
> this already (I'm a bit new...) but I would like to see something like
> this:
>
> diffuse { bozo ... }
> specular { image_map ... }
>
This is not a feature suggestion but a suggestion for a change in
language design (and not a very consistent one). What you could do with
such a feature you can already do with texture maps.
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:
> Loki wrote:
> > Maybe there is a plugin/macro or something to do
> > this already (I'm a bit new...) but I would like to see something like
> > this:
> >
> > diffuse { bozo ... }
> > specular { image_map ... }
> >
>
> This is not a feature suggestion but a suggestion for a change in
> language design (and not a very consistent one). What you could do with
> such a feature you can already do with texture maps.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 23 Sep. 2004 _____.//^>_*_<^/.______
Sorry I wasn't very clear. What I mean is it would be good to be able to
map a different image map to the colour, diffuse, specular, reflection and
transparency channels of a texture separately. I understand what you mean
about texture maps but that isn't quite what I was getting at.
L
-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Loki wrote:
>
> Sorry I wasn't very clear. What I mean is it would be good to be able to
> map a different image map to the colour, diffuse, specular, reflection and
> transparency channels of a texture separately. I understand what you mean
> about texture maps but that isn't quite what I was getting at.
You did not understand me - you can do all this with texture maps (but
of course not using 'image_map' since this is a pigment and not a pattern).
It is not a good idea to start demanding a new feature just because it
is not obvious to you how to accomplish a certain effect with existing
means.
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
|
|
| |
| |
|
|
|
|
| |
