"Severi Salminen" <not### [at] hereinvalid> wrote:
> > > Are you sure?  A watersurface seems a lot more reflective from underneath
> > > the water than from above the water. Could be an optical illusion though.
> > >
> > > <snip>
> >
> > http://en.wikipedia.org/wiki/Total_internal_reflection
>
> We were not talking about total internal reflections, but normal specular
> reflections. I have the impression that they happen about equally to both
> directions.

I know that the discussion was about 'normal' reflection. I was only referring
to the post by Zeger Knaepen since total internal reflection is what's making
up the phenomenon he's describing in his post.

Regards Roman

Post a reply to this message

>   Try with the example at wikipedia:
> http://en.wikipedia.org/wiki/Image:Total_internal_reflection.jpg

I really have now only spheres and planes. Boxes next.

>   If you are bruteforce-rendering anyways, using these limited lighting
> models kind of becomes moot. They were created precisely for
> non-bruteforce rendering because bruteforce rendering was unfeasible.
> Now that you are bruteforce-rendering, there's no need to use them. You
> can use realistic BRDFs.

I don't know. I think these are different things. Brute force helps to create
every lighting effect which depends on light bouncing multiple times. BRDF, on
the other hand, just represents the way light reflects. So they address
different problems. But it is true that both should be handled and taken into
account in a good renderer.

>   In principle a BRDF is quite simple: It's a function which takes an
> incoming direction vector and an outcoming direction vector as (const)
> parameters, and returns a factor for each color component between 0.0
> and 1.0. That's it. Its usage is equally simple: When you have
> calculated a ray which intersects a surface and want to reflect that ray
> to some direction, you shoot that reflected ray and then multiply the
> color returned by that ray with the factor returned by the BRDF of that
> surface. This will be the color returned by the original incoming ray.

I think that is not the best way to implement it. Better way is to use a ray
distribution function that generates rays distributed according to BSDF. Now I
use cosine weighted function to create random rays at diffuse surface. This
minimizes useless rays and gives faster results - but is unbiased. And I create
pure specular rays at specular surface - no need to create other rays and give
them weight 0. The result is identical but faster. There are good functions for
different glossy surfaces also.

So basically I'm using certain ideal BSDF's but "ideal" is not necessarily
"physically possible"...

Post a reply to this message

Severi Salminen wrote:
> I don't know. I think these are different things.

  Of course you *can* perform brute-force rendering without using BRDFs.
The point is that it doesn't make too much sense because BRDFs are the
most accurate texture definition functions, while everything used in
non-brute-force rendering is only an inaccurate approximation.
Brute-force rendering allows using BRDFs, so why not use them?

>>   In principle a BRDF is quite simple: It's a function which takes an
>> incoming direction vector and an outcoming direction vector as (const)
>> parameters, and returns a factor for each color component between 0.0
>> and 1.0. That's it. Its usage is equally simple: When you have
>> calculated a ray which intersects a surface and want to reflect that ray
>> to some direction, you shoot that reflected ray and then multiply the
>> color returned by that ray with the factor returned by the BRDF of that
>> surface. This will be the color returned by the original incoming ray.
> 
> I think that is not the best way to implement it.

  I didn't say anything about which direction the reflected ray should
go. The BRDF doesn't care.

  You can, of course, send more rays towards directions for which the
BRDF gives larger factors.

Post a reply to this message

nemesis nous apporta ses lumieres en ce 2008/02/25 11:32:
> you're using photon mapping for the caustics, right?  Ever since these 
> guys have been posting these bruteforce renders, I've been noticing an 
> interesting pattern about photon mapping:  the caustics don't match the 
> shape of the source of light, you look at your render and to that of 
> Severi and you notice your caustics are focused in one point while his 
> are large and in the shape of the light sphere.  And that is to be 
> expected, since photon mapping reacts to the (point)light source, not to 
> a physical object emitting light, like in the bruteforce methods.
> 
> But radiosity works ok for that purpose.  Like here, just first 
> radiosity pass as I don't have the time right now for a complete 
> render... there are a few radiosity artifacts left, you could raise the 
> count a bit...
> 
> 
With photons, you can have broad caustics. You need to add "area_light" in the 
photons block of the area_light.
Here's an area_light that will emit photons from a "spherical" area:

light_source{Location, rgb 1 area_light 3*x,3*y 17,17 autostop 0 circular orient 
photons{area_light}// the key of having soft caustics
}

-- 
Alain
-------------------------------------------------
EVERYTHING HAS A GENDER

You may not know this but many nonliving things have a gender...

A Subway is Male, because it uses the same old lines to pick people up.

Post a reply to this message

Severi Salminen wrote:
> Glass has about 4% reflection coefficient when angle of incidence is 0.
> I guess this 4% holds true both when entering glass and exiting it?

It's more complicated than that in reality. Light doesn't reflect from 
the surface of the glass. It reflects inside the glass. It only seems 
like it reflects from the surface because different paths that reflect 
at different depths in the glass cancel out. A piece of glass the proper 
thickness has no "surface reflection" at all, and a half wavelength 
thicker and it has 16% reflection. So, technically speaking, there's no 
"reflection off the back" at all - it's just that the math works out to 
make it look like there is. (And I have no idea where I left the book I 
have that explains the math well enough to indicate whether the math 
works out to make it look like a 4% reflection off the back, too. ;-)

(Similarly, a mirror reflects all over its surface, but only the paths 
where incidence = reflection don't tend to cancel out. Diffraction 
gratings and holograms take advantage of this, for example.)

I mean, if you're talking about "physically-accurate" tracing. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> Severi Salminen wrote:
>> Glass has about 4% reflection coefficient when angle of incidence is 0.
>> I guess this 4% holds true both when entering glass and exiting it?
> 
> It's more complicated than that in reality. Light doesn't reflect from
> the surface of the glass. It reflects inside the glass. It only seems
> like it reflects from the surface because different paths that reflect
> at different depths in the glass cancel out. 

Thanks for the clarification. The important part is the actual net
effect that affects the image. If the 4% (or whatever n1 and n2 gives)
holds true in most cases and is accurate within some margin - that is
suitable for now.

> I mean, if you're talking about "physically-accurate" tracing. :-)

Definitely :=)

But at this point I'm mostly interested in reproducing the effects that
make bigger difference in final image. For example:

having no shadows is worse than having inaccurate sharp shadows
inaccurate sharp shadows < inaccurate area_light approximation

Lack of accurate GI < lack of dispersion

lack of dispersion < slightly inaccurate refraction model (light bends a
bit too far etc.)

etc.

So things must be fixed in priority order. Here is the same scene with
5% reflection in the spheres - including the light that tries to exit
the sphere :) 46000 passes. Quite smooth rendering.

I'm now experimenting with Halton sequence that replaces totally random
rays. It is deterministic but should give more uniform distribution. So
less samples are needed for certain noise level. Not working properly yet...

Post a reply to this message

Attachments:
Download 'kuva10.jpg' (38 KB)

Preview of image 'kuva10.jpg'

Warp wrote:

>   Of course you *can* perform brute-force rendering without using BRDFs.
> The point is that it doesn't make too much sense because BRDFs are the
> most accurate texture definition functions, while everything used in
> non-brute-force rendering is only an inaccurate approximation.
> Brute-force rendering allows using BRDFs, so why not use them?

Depending on definition, even POV-Ray is using BRDFs. Maybe I just don't
know what is your definition of "BRDF" when considering ray tracers.
(see below)

>   You can, of course, send more rays towards directions for which the
> BRDF gives larger factors.

And that is the best way to do it. Like I said, sending rays to all
direction when the material is 100% mirror, is not so clever.

The problem here is I have no idea, how the user would assign an
_arbitary_ BRDF to a object. What does it look like and how would the
program generate a distribution function out of it. Should it be just a
bunch of weight/angle pairs and the renderer interpolates and renders
accordingly? Or something else?

And of course, I use BRDFs even now if end result is considered. They
just look a bit different and are "special cases", like 100% diffuse
material, 100% specular surface etc, transmissive surface following
Snell's law etc. Luxrenderer also "uses BRDFs" the way I do. So maybe
I'm using BRDFs after all :)

http://www.luxrender.net/index.php?option=com_content&view=article&id=49&Itemid=59

Post a reply to this message

Severi Salminen wrote:
> Thanks for the clarification. The important part is the actual net
> effect that affects the image. If the 4% (or whatever n1 and n2 gives)
> holds true in most cases and is accurate within some margin - that is
> suitable for now.

I think it's more like 4% is going to be the average surface 
reflectivity, and you really have to manufacture the glass smooth and 
with a constant thickness within a fraction of a wavelength to see any 
difference.

The "not always 4%" effect can be seen in things like oil floating on 
water, where the layer of oil is less than a few wavelengths thick, so 
you see the different colors reflecting with different percentages.

For a "normal" block of glass, yah, it's going to be about 4%, because 
you're going to average a whole bunch of thicknesses of glass and a 
number of different angles (as your pupil has a size much larger than a 
wavelength of light too).

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Here is a new render. Now with boxes and properly working total internal
reflection (you can see the windows through green glass, for example).
Everything looks pretty good to me: shadows, highlights, caustics etc.
The "windows" are actually only light emitting boxes. I also stopped
using the infamous C rand() and implemented Mersenne Twister RNG. It is
a lot faster (some 20-30% faster rendering) - and there is even faster
variation available.

Next:

1. Wait till "the Bible" arrives in mail. "Physically based rendering",
by Matt Pharr and Greg Humphreys.
2. Implement basic transformations.
3. Improve box intersections stuff.
4. Some kind of bounding box hierarchy acceleration system is needed.
5.- 1000004. Million other things.

Post a reply to this message

Attachments:
Download 'kuva11.jpg' (111 KB)

Preview of image 'kuva11.jpg'

Oh, cool.

Are you going to make the program available (e.g., Sourceforge) at some 
point?

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

For example, using PHP to access a MySQL database is a common subject 
for print and on-line articles. Perhaps combining those two technologies 
on an Esperanto-speaking giant robot that shoots laser beams out of its 
eyes?
     -- From the _Linux Journal_ article submission guidelines

Post a reply to this message