Darren New <dne### [at] sanrrcom> wrote:
> The yellow car as seen thru the windshield of the dark car is far from 
> completely smooth. :-) Altho that might just be the jpeg compression or 
> something

  Jpeg compression doesn't add that kind of high-frequency noise.

-- 
                                                          - Warp

Post a reply to this message

>> The yellow car as seen thru the windshield of the dark car is far from
>> completely smooth. :-) Altho that might just be the jpeg compression or
>> something
>
>  Jpeg compression doesn't add that kind of high-frequency noise.

Looks like noise due to high ISO setting (and/or low sensor size) on the 
camera.  Makes it look more like a real photo IMO.

Post a reply to this message

scott <sco### [at] laptopcom> wrote:
> Looks like noise due to high ISO setting (and/or low sensor size) on the 
> camera.  Makes it look more like a real photo IMO.

  Noise is usually something you want to avoid in photos.

-- 
                                                          - Warp

Post a reply to this message

47208206$1@news.povray.org...
>>> The yellow car as seen thru the windshield of the dark car is far from
>>> completely smooth. :-) Altho that might just be the jpeg compression or
>>> something
>>
>>  Jpeg compression doesn't add that kind of high-frequency noise.
>
> Looks like noise due to high ISO setting (and/or low sensor size) on the 
> camera.  Makes it look more like a real photo IMO.

It seems to work like the other unbiased renderers I've tested: the image 
starts black, then grainy, then less grainy, and is progressively refined... 
until the user decides it's good enough and stops the render.

G.

Post a reply to this message

>> Looks like noise due to high ISO setting (and/or low sensor size) on the
>> camera.  Makes it look more like a real photo IMO.
>
>  Noise is usually something you want to avoid in photos.

True, but unless you have an expensive dSLR noise is obviously present in 
all but the brightest photos.  Just saying that IMO that noise in the render 
makes it look *more* like a regular photo, not less.

Post a reply to this message

"Gilles Tran" wrote:
> It seems to work like the other unbiased renderers I've tested: the image 
> starts black, then grainy, then less grainy, and is progressively 
> refined... until the user decides it's good enough and stops the render.

I'd guess that whenever rays hits a both reflective and refractive surface, 
each ray is not split in two, but some of the rays go through while others 
are reflected (say, 50/50). So a surface seen through a glass pane will be 
noise for twice as long as a surface seen directly. A surface seen through 
*two* glass panes will take four times as long to get smooth etc.

Actually I'd have presumed that they would focus attention of rays to those 
areas that are still noisy to prevent that some surfaces are noisy much 
longer than others, but it still might perhaps explain why the details seen 
though the windshield etc. are so much more noisy...

Rune

Post a reply to this message

4720abd9$1@news.povray.org...
> Actually I'd have presumed that they would focus attention of rays to 
> those areas that are still noisy to prevent that some surfaces are noisy 
> much longer than others, but it still might perhaps explain why the 
> details seen though the windshield etc. are so much more noisy...

For the technically-inclined, here's a discussion of the technique and of 
the noise issue.
http://renderspud.blogspot.com/2006/10/biased-vs-unbiased-rendering.html

G.

Post a reply to this message

Rune <aut### [at] runevisioncom> wrote:
> I'd guess that whenever rays hits a both reflective and refractive surface, 
> each ray is not split in two, but some of the rays go through while others 
> are reflected (say, 50/50).

  I have been thinking about this, but there's one problem I can't think
a solution for:

  For approximately half of the rays which hit the surface only reflection
is calculated (and for the rest of the rays only refraction). So basically
for those rays the surface is only reflective, but not refractive. Or in
other words, for those rays it's an *opaque* surface.

  The problem is: For these rays, which see the object as opaque, what
surface color should they use? They cannot simply return the color of
the reflected ray because it may not be 100% reflection. If the surface
is, for example, 20% reflective, than only 20% of the reflected ray color
will be mixed with 80% of something else.
  In regular raytracing this 80% would be the color of the refracted ray
(which is mixed with the actual color of the surface). However, since we
are not calculating refraction for this ray, we don't have the color of
the refraction.
  The only thing we have left is the surface's own color. However, if we
simply mix 20% of the reflected ray color with 80% of the surface's color,
we are basically making the surface less transparent in the overall process.
Also, what *is* this color if the surface has been defined to be completely
transparent? In that case the surface basically has no color, so there's
nothing we can mix our reflected ray color with.
  Just returning the reflected ray color is no good. That would mean that
in the end result the surface would look much more reflective and opaque
than it was set for.

  "Return only the reflected ray color, but when you are calculating the
average of all the rays sent for that pixel, only use 20% of the color of
all rays which reflected, and 80% of the color of those rays which refracted"
doesn't work either. This would work for max_trace_level 2, but no further.
If at trace level 3 the ray reflects again, we have the same problem again:
We have to mix its color at 20% with what? Or what if the ray hits another
object with a different reflection %? Moreover, what if the ray now refracts
instead?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Rune <aut### [at] runevisioncom> wrote:
>> I'd guess that whenever rays hits a both reflective and refractive surface, 
>> each ray is not split in two, but some of the rays go through while others 
>> are reflected (say, 50/50).
> 
>   I have been thinking about this, but there's one problem I can't think
> a solution for:
> 
>   For approximately half of the rays which hit the surface only reflection
> is calculated (and for the rest of the rays only refraction). So basically
> for those rays the surface is only reflective, but not refractive. Or in
> other words, for those rays it's an *opaque* surface.
> 
>   The problem is: For these rays, which see the object as opaque, what
> surface color should they use? They cannot simply return the color of
> the reflected ray because it may not be 100% reflection. If the surface
> is, for example, 20% reflective, than only 20% of the reflected ray color
> will be mixed with 80% of something else.

As far as I understand, there is no mixing going on in these methods, 
not at the ray level. You don't shoot one ray per pixel, you shoot many 
of them, and make them bounce around surfaces or refract with 
probabilities according to the transparency.

In your example, you would fire 100 rays, and have:
~80 that are refracted, and colored by the "transmitted" color of the 
surface
~20 that are reflected, and colored by the "reflective" color of the surface

In the end you average all the intensities, and you get, statistically, 
the same result you'd get with a classical raytracer: 80% of refracted 
ray color * "transmitted" color, 20% of reflected ray color * 
"reflective" color.

This sounds horridly ineffective, but since you spawn only one ray at 
each surface intersection, instead of two, you are able to go much 
further, without stopping at a fixed bailout, because you are not 
stopped by the exponential growth in the number of rays. This is roughly 
what makes the renderer unbiased.

I'm quite sure there are better explanations than this floating around, 
though :-)

-- 
Vincent

Post a reply to this message

Warp wrote:
>   Noise is usually something you want to avoid in photos.

	Usually, but not always.

-- 
When everything's coming your way, you're in the wrong lane


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message