> If you're talking about that light leaking though walls and the like, that's
> actually the high error_bound samples, not the low ones.

   Yes, I'm talking about these... but my experience says they appear at low 
error_bound values... ?!?!?

>>    Now, if someone is interested, I had the strange idea that a
>> fade_distance  for reflections will help making blurred reflections with
>> averaged normals... but I'm unable to test on my head if it will work.
> 
> Now it's me who understands just half of what you're saying :)
> 

   Sorry, I was too short on the explanation... what I mean is that when you 
look at blurred reflections in RL, the reflection seems to disappear at some 
distance from the reflected object. I know the reflection is there, but very 
blurred... but in practice it looks like this is just the underlying 
material color.

   Now, if you had a fade_distance keyword on the reflection{} statement, 
which attenuates the reflection until it reaches 0 for objects beyond the 
specified distance, perhaps this would help getting less noisy materials 
with the existing blurring techniques (averaged layers with big normals, 
micronormals,...).

   But as I said, my ideas turn to be nonsense often... and also it seems 
too simple to not have been figured out before.


--
Jaime

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> In these discussions it would be nice to know how the "reference
> renderer" handles this. Reference being MC-Pov.

Why would MC-Pov be qualified as a "reference renderer" in this case?

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> > If you're talking about that light leaking though walls and the like, that's
> > actually the high error_bound samples, not the low ones.
>
>    Yes, I'm talking about these... but my experience says they appear at low
> error_bound values... ?!?!?

Huh - that sounds weird to me... I can't imagine why that would be.

Then again, thinking of it: Did you also set minimum_reuse low? Otherwise the
low error_bound might increase the probability of samples being placed very
close to edges, while the comparatively high minimum_reuse might allow for
"cross-talk" with the other side of the wall.

There might also be a connection to some other radiosity flaw I just found,
which explains how light will "leak" into dark corners (still doesn't explain
leaks at edges though). Unfortunately I still lack a good idea to fix it.


>    Now, if you had a fade_distance keyword on the reflection{} statement,
> which attenuates the reflection until it reaches 0 for objects beyond the
> specified distance, perhaps this would help getting less noisy materials
> with the existing blurring techniques (averaged layers with big normals,
> micronormals,...).
>
>    But as I said, my ideas turn to be nonsense often... and also it seems
> too simple to not have been figured out before.

Naaah - that doesn't sound like nonsense to me. It may be somewhat different
from reality, but it may *look* convincing after all.

Post a reply to this message

> One thing that makes your scene much easier to render is that you allow the
> light to enter via a straight way. In mine, the profile of the door and frame
> is more complex, and the door is almost closed, so much that light cannot enter
> straight (well, except through the keyhole).
> 

   Yes, you're right, but my scene also had the problem with the light 
leaking, which is what I wanted to "solve" with the technique I was testing...

--
Jaime

Post a reply to this message

clipka wrote:
> Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
>> In these discussions it would be nice to know how the "reference
>> renderer" handles this. Reference being MC-Pov.
> 
> Why would MC-Pov be qualified as a "reference renderer" in this case?

Cause it doesn't exhibit radiosity artifacts - only noise. I just meant
that I'd love to see POV-ray support unbiased rendering as opposed to
radiosity with all its shortcomings. The argument against path tracing
and similar methods is usually speed so I wonder how would a properly
implemented path Monte Carlo renderer do in this scene.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> > In these discussions it would be nice to know how the "reference
> > renderer" handles this. Reference being MC-Pov.
>
> Why would MC-Pov be qualified as a "reference renderer" in this case?

http://pagesperso-orange.fr/fidos/MCPov/MCPov.html

It's a megapov patch based on path-tracing and reportedly very accurate.  Very
slow too, but more accurate no doubt than current radiosity.

fidos developed it last year and I remember there were many interesting posts
with comparisons between path-tracing and radiosity, path-tracing giving very
accurate results, despite the noise still left and render times.  Here's the
relevant links, very interesting read anyway:

http://news.povray.org/povray.binaries.images/thread/%3Cweb.47a4a907a327f677ce311500%40news.povray.org%3E/?ttop=294498&
toff=500
http://news.povray.org/povray.binaries.images/thread/%3C47bde8f9%40news.povray.org%3E/?ttop=294498&toff=450
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4838403f151ae76dd309f1e00%40news.povray.org%3E/?ttop=294498
&toff=300
http://news.povray.org/povray.binaries.images/thread/%3Cweb.48429c2754fc510a2b3143ed0%40news.povray.org%3E/?ttop=294498
&toff=300
http://news.povray.org/povray.binaries.images/thread/%3Cweb.484d6237b20e507399bf01250%40news.povray.org%3E/?ttop=294498
&toff=300

Post a reply to this message

clipka wrote:
> Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
>> In these discussions it would be nice to know how the "reference
>> renderer" handles this. Reference being MC-Pov.
> 
> Why would MC-Pov be qualified as a "reference renderer" in this case?

Because it's closer to reality, at the cost of insane render times.

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> In these discussions it would be nice to know how the "reference
> renderer" handles this. Reference being MC-Pov. In 1 hour the result
> might be quite good with a path tracer. At least if MC-POV implemented
> all known techniques to speed up the convergence.
>
> Severi S.

I am going to try it.  I am new to MC-Pov, but it *seems* to be working
correctly (i.e. black image with random white speckles after 2 minutes).  It'll
take me a while to know for sure, though...

I modified the scene a bit, though.  The version I grabbed from the other thread
had the reflective finishes commented out and some other alternative values
commented out for the specular components.  I put the reflection back into the
finishes, changed the global ambient_light to 1, and changed all textures to a
plain white pigment with diffuse of 1.00.  The normal statements are unchanged.

I am now sort of intrigued by MC Pov, particularly by the fact that the
algorithm could take advantage of multiple cores or machines.  It also makes me
think that, in the future, it might not be a bad idea for Pov to support more
than one possible global illumination method or light model that would be
specified in the ini file or global_settings block.



-Reactor

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> In these discussions it would be nice to know how the "reference
> renderer" handles this. Reference being MC-Pov. In 1 hour the result
> might be quite good with a path tracer. At least if MC-POV implemented
> all known techniques to speed up the convergence.

Trying out a very similar scene in MC-POV, but at 1:30, I can tell you that the
1 hour result won't be worth posting.  Of course I can be very patient if I
need to, so no complaints here!  Speaking of MC-POV though, are there any plans
to include the montecarlo subsurface scattering?

 - Ricky

Post a reply to this message

"triple_r" <nomail@nomail> wrote:
> Trying out a very similar scene in MC-POV, but at 1:30, I can tell you that the
> 1 hour result won't be worth posting.  Of course I can be very patient if I
> need to, so no complaints here!  Speaking of MC-POV though, are there any plans
> to include the montecarlo subsurface scattering?

Well, here's the MC-POV version I did last night anyway.  It's about twenty
hours of serial time (divided by two cores) with a single point source behind
the wall, and a blue source inside the room.  The problem with MC-POV seems to
be that some effects end up over-sampled while others are very noisy.  I
haven't figured out how to control this well, yet.  Perhaps better portal setup
would fix the problem, but at the moment I think radiosity is the horse to bet
on for most scenes.  You do get nice sharp shadows with path-tracing, though.

 - Ricky

Post a reply to this message

Attachments:
Download 'test1.jpg' (66 KB)

Preview of image 'test1.jpg'