After reading a message by Warp about how save_file and load_file could work
on the same scene together, I remembered that he mentioned this before. Back
then I had the intention to test it, but surely RL came in the way... now, I
don't have much free time these days anyhow, but I've not resisted to try
it, because I had a "bengenesque" idea that might work: use the animation
feature to successively decrease the error_bound while saving the data and
reloading it on the next frame:

#declare this_fr=concat("saved-",str(frame_number,2,0),".rad");
#declare last_fr=concat("saved-",str(frame_number-1,2,0),".rad");
radiosity {
   count 160
   error_bound 0.04+0.02*frame_number
   nearest_count 10
   recursion_limit rad_bounces
   brightness rad_brightness
   #if (file_exists(last_fr)=1)
    load_file last_fr
    always_sample off
   #end
   save_file this_fr
   randomize on
}

Running 16 frames I get a very good result in just 1 hour: see
secret-progressive16.jpg. I also included for reference the first pic of the
sequence (secret-progressive01.jpg), and also a pic showing how the end
settings will look without loading the previous frames radiosity
(secret-progressive16b.jpg).


I think it deserves some more research, but looks promising to overcome
many radiosity problems.

--
Jaime

Post a reply to this message

Attachments:
Download 'secret-progressive16.jpg' (35 KB) Download 'secret-progressive01.jpg' (39 KB) Download 'secret-progressive16b.jpg' (47 KB)

Preview of image 'secret-progressive16.jpg'

Preview of image 'secret-progressive01.jpg'

Preview of image 'secret-progressive16b.jpg'

Sorry for responding my own post, but I forgot to mention that I was also
inspired by Clipka "secret" scene, and used these radiosity tests to see if
that kind of scene could be rendered more realistically with this technique.

Regards,

--
Jaime

Post a reply to this message

Jaime Vives Piqueres wrote:
> I think it deserves some more research, but looks promising to overcome
> many radiosity problems.

  I think it also deserves to be considered being implemented as an
internal feature of POV-Ray. In other words, something which could be
turned on to make POV-Ray do this automatically, and without the need
for the save files.

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> After reading a message by Warp about how save_file and load_file could work
> on the same scene together, I remembered that he mentioned this before. Back
> then I had the intention to test it, but surely RL came in the way... now, I
> don't have much free time these days anyhow, but I've not resisted to try
> it, because I had a "bengenesque" idea that might work: use the animation
> feature to successively decrease the error_bound while saving the data and
> reloading it on the next frame:
>
> Running 16 frames I get a very good result in just 1 hour: see
> secret-progressive16.jpg. I also included for reference the first pic of the
> sequence (secret-progressive01.jpg), and also a pic showing how the end
> settings will look without loading the previous frames radiosity
> (secret-progressive16b.jpg).
>
>
> I think it deserves some more research, but looks promising to overcome
> many radiosity problems.

Things to note:

- By setting nearest_count to 10, no additional samples will be taken after the
10th pass whatsoever. In fact, many samples will have been taken much earlier.

- By taking high error_bound samples first, which are low quality, you will
reduce the number of low error_bound samples taken.

- The artifacts you see in the 16b image are not due to the quality of the
radiosity samples used for that shot, but due to the moment they were taken:
What we see are the results of final-trace sampling, with the new samples
affecting their surroundings only in successive rows.


I expect that exactly the same quality - if not even better - can be achieved
within just two frames by using constant settings as currently used in the...
hm, let me guesstimate... something like the 6th frame.

You may also want to try using 1/max(image_width,image_height) as pretrace_end,
and N/max(image_width,image_height) with N being some power of 2 as
pretrace_start, and render just a single frame. Try a nearest_count of 3 or the
like.


Finally, expect 3.7 radiosity to become better anyway.

Oh, and finally finally - keep having ideas like these, 'cause even if they
don't work as you may think they may still be inspiring. And inspiration is the
thing most needed with POV's radiosity.

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Sorry for responding my own post, but I forgot to mention that I was also
> inspired by Clipka "secret" scene, and used these radiosity tests to see if
> that kind of scene could be rendered more realistically with this technique.

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).

Post a reply to this message

clipka escribió:
> - By setting nearest_count to 10, no additional samples will be taken
> after the 10th pass whatsoever. In fact, many samples will have been
> taken much earlier.

   I should have warned that "I really don't know what I'm doing" is my
second name... but thanks for the pointer.

> - By taking high error_bound samples first, which are low quality, you
> will reduce the number of low error_bound samples taken.

   Well, here I must admit that I thought I knew what I was doing... ;) What
I wanted was to take first the high error_bound samples, to avoid the 
problem of radiosity coming trough the joints... but perhaps it works 
equally the other way: I must try it.

> - The artifacts you see in the 16b image are not due to the quality of
> the radiosity samples used for that shot, but due to the moment they were
> taken: What we see are the results of final-trace sampling, with the new
> samples affecting their surroundings only in successive rows.

   I think I didn't fully understand this explanation... sorry (not your
fault). But the 16b was done apart in one pass, without loading any radiosity...

> I expect that exactly the same quality - if not even better - can be
> achieved within just two frames by using constant settings as currently
> used in the... hm, let me guesstimate... something like the 6th frame.
> 
> You may also want to try using 1/max(image_width,image_height) as
> pretrace_end, and N/max(image_width,image_height) with N being some power
> of 2 as pretrace_start, and render just a single frame. Try a
> nearest_count of 3 or the like.

   Again, I must try these tips...

> Finally, expect 3.7 radiosity to become better anyway.

   I hope so!

> Oh, and finally finally - keep having ideas like these, 'cause even if
> they don't work as you may think they may still be inspiring. And
> inspiration is the thing most needed with POV's radiosity.

   Thanks: I have lots of weird ideas... and not only abut radiosity, but 
many show to be nonsense after the first tests.

  For example, I also tried something similar to what Holger Karsten tried
with MCPov: rendering many frames with random sample sequences (MegaPOV) and
then averaging them with ImageMagick. It sort of works, but needs too many
frames to get ride of the noise.

   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.

--
Jaime

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I think it also deserves to be considered being implemented as an
> internal feature of POV-Ray. In other words, something which could be
> turned on to make POV-Ray do this automatically, and without the need
> for the save files.

The idea of doing a final pretrace step that does exactly the same as the main
render definitely deserves attention.

However, this would theoretically have to include all the bells & whistles, like
anti-aliasing or focal blur, diffraction etc., as these *may* have an impact.


I was also pondering the idea of avoiding radiosity sampling during the final
render in some other way, but haven't come up with a conclusive idea yet. The
problem is always the same: Once you "slipped off" an existing sample into
no-man's land, you'd need to use *some* other color - but whichever you choose
will possibly be different from that last nearby existing one, and give a
(comparatively) sharp edge - an artifact.

Theoretically it would be possible to just keep using the nearest sample, but
this has drawbacks as well:

- Speed: The sample lookup algorithm is designed around the expected maximum
radius of influence of a particular sample. Searching for samples further away
than their expected radius of influence would be a hassle.

- Artifacts: When moving further away from a sample, there would be a moment
when the closest sample would switch to another one, potentially causing yet
another jump in color.

- Geometry: Some samples just don't fit, e.g. because they're on the other side
of a comparatively thin object.


POV already provides (theoretically) good tools for addressing this issue: The
reuse_count (together with always_sample off), forcing more samples to be
collected during pretrace than will be needed during final render, reducing the
risk of any spot being missed completely, and the low_error_factor, allowing
samples to be re-used at greater distance during final render.

There were a lot of design flaws in 3.6 acting against these mechanisms. Let's
see how things work when these flaws have been eliminated.

Post a reply to this message

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.

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>    Well, here I must admit that I thought I knew what I was doing... ;) What
> I wanted was to take first the high error_bound samples, to avoid the
> problem of radiosity coming trough the joints... but perhaps it works
> equally the other way: I must try it.

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.

If you're talking about light leaking through at the hinge side of the door,
that may even be physically correct.


> > - The artifacts you see in the 16b image are not due to the quality of
> > the radiosity samples used for that shot, but due to the moment they were
> > taken: What we see are the results of final-trace sampling, with the new
> > samples affecting their surroundings only in successive rows.
>
>    I think I didn't fully understand this explanation... sorry (not your
> fault). But the 16b was done apart in one pass, without loading any radiosity...

I'll try again, just the basics:

One of the main source of artifacts are radiosity samples which are taken during
the final render. The artifacts seen in the 16b sample look exactly like that
type.

(I'll not go into detail *why* they look that way ;) it's simply a side effect
of final-render-sampling that cannot be avoided)

This happens when the pretrace steps didn't generate enough samples.

If the same samples would be available at the start of the final render already,
you would not get any such artifacts.

They are available *after* that final render, and this is the moment when
radiosity data saving is done. So if you render the whole smash all over again,
this time loading the samples from the previous run, you don't get a different
set of samples - but you get a much better render.


>    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 :)

Post a reply to this message

The amazing JVP back at work, ladies and gentlemen!  Someone please shoot that
damned RL! :D

Post a reply to this message

clipka escribió:
> 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

clipka escribió:
> 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'

Very noisy, yes, but undoubtfully much more acurate.

So, we have 2 options so far:  noise and insane rendertimes or splotches and
high rendertimes.  Pick your poison.  :)

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> It's a megapov patch based on path-tracing and reportedly very accurate.  Very
> slow too, but more accurate no doubt than current radiosity.

Hehe - *current* radiosity is flawed, no doubt :)

Anyway: I guess I'll have a close look at that one, because it seems to be very
well suited to assess how a scene *should* look with radiosity.

I also think that some of the ideas may work well in radiosity, too.

Post a reply to this message

"triple_r" <nomail@nomail> wrote:
> 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.

To get my eyes off radiosity for a moment:

The over-sampling of some areas vs. remaining noise in others might be not too
difficult to control. The key would be to stop using a uniform number of trace
iterations, and instead stop tracing a pixel as soon as you are confident that
it is good enough. Or, to stay in the MCPov paradigm, instead of shooting a
fixed number of rays per pixels in each pass, modulate the number depending on
how confident you are about them.

As a confidence indicator, you can keep track of a statistical parameter like
the standard deviation for each pixel. If it has been low so far, chances are
it will continue to remain low, so a lower sample count should suffice for
them.

A less memory-consuming approach to drive this would be the standard deviation
of a "pixel neighborhood": If the pixels in some area currently deviate a lot,
chances are this is due to noise, so you may want to spend more computing power
on this area.


This might also make an interesting concept for the collection of radiosity
samples: Ditch the fixed count, and instead modulate the number of rays based
on the standard deviation encountered in nearby samples. A first coarse pass
could do an extremely high number of sample rays, which might allow it to pick
up small light sources.

Keeping track of the standard deviation for different directions could refine
this approach.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Very noisy, yes, but undoubtfully much more acurate.
>
> So, we have 2 options so far:  noise and insane rendertimes or splotches and
> high rendertimes.  Pick your poison.  :)

No splotches and moderate render times, that's what I'm aiming at :)

Post a reply to this message