> Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
>> First, I don't understand completely what you are trying to do. If you 
>> implement an unbiased method, of course the pictures will be radically 
>> different.
> 
>   Unless I have understood something completely incorrectly, I think that
> "unbiased rendering" simply means that light is not assumed to be coming
> from a specific direction, but the entire space is sampled for possible
> incoming light.
> 

But that means that the images should be different, no? And I mean, more 
than just noisy...

>   Well, the phong lighting model is a perfectly valid BRDF, so I see
> absolutely no reason why unbiased rendering would exclude the possibility
> of using it. I don't believe that unbiased rendering would somehow limit
> what kind of BRDFs you can use.
> 

I'm not sure about the phong model being a valid BRDF. But I don't 
remember the details so let's say it is...

>   If the phong lighting model is used as the BRDF for all surfaces the
> end result should be pretty much the same using unbiased rendering than
> using the traditional raytracing method (except for the possible graininess).
> 

Except that traditional raytracing neglects plenty of light transfers, 
which is what is making it biased in the first place. It's not even a 
question of what BRDFs are used...

>> There is no way around that. If the pictures, with the exact 
>> same parameters, were only more grainy, but eventually converged to the 
>> exact same image on average, then the method would be biased...
> 
>   I'm more interested in the single-path-tracing than in the unbiasing.
> 
>   (Besides, I think the only difference pure unbiased rendering would do
> is to make the image have global illumination, ie. what povray calls
> "radiosity", especially if big area lights are used instead of point
> lights.)
> 

Well that's a big difference, and I don't know if it's really possible 
or even desirable to make a single path if you're not looking for an 
unbiased result.

>> The other problem is indeed that many material models within POV-Ray are 
>> physically inaccurate
> 
>   I bet all BRDFs are physically inaccurate to some extent, and only
> *approximate* the real thing. The phong lighting model is one approximation
> among others (it might not be the best one, but it's a simple and fast one,
> and often gives good results).
> 

I was thinking more of your reflection 1 transmit 1 example. Energy 
conservation is still one of the basic properties of BRDFs. There is no 
way you can represent that with a BRDF. Of course all BRDFs are only 
approximations, but that does not mean that they do not have 
constraints. I guess my use of "physically accurate" is the problem here...


>> I suspect the case of your black reflective object is a bit similar.
> 
>   No, that phenomenon happens in real life. Even surfaces which do not
> reflect diffusely light almost at all can have strong specular reflection
> properties. That's the reason why pitch-black plastic can have bright
> highlights. It has something to do with quantum mechanics or something
> similar, don't remember any details.
> 

In your previous post, you said:
>   The algorithm presented above calculates the non-weighted average of
> the diffuse and specular components. This means that, for example, a
> black object cannot have a completely white highlight (because the averaging
> will make it gray), even though in real life it's perfectly possible for
> this to happen.

A black object can have a bright highlight, of course. Or rather, a 
bright reflection. In that case, you would lower diffuse_amount, to be 
able to set a higher reflection_amount.

What you cannot do is a white object with a 100% reflection on top of 
that. Because if you define that 100% of the incoming light goes in the 
specular reflection, there is nothing left to be diffused. So making the 
object white effectively means you have a dimmer highlight.

The problems in the algorithm is the colors should all be normalized. 
That way the only possiblity to have a black object is lowering its 
diffuse_amount, not setting its color to black. In current POV, you can 
do one or the other...

-- 
Vincent

Post a reply to this message