Hi:

   I found an strange problem when using he radiosity save/load
mechanism. My typical setup uses the same settings for both passes,
except that I set both "pretrace_start" and "pretrace_end" to 1, and
"always_sample" to off, on the loading pass. This saves a lot of
rendering time, which is my main purpose for using the save/load feature.

   This trick worked great for me until now... it always produced some
radiosity artifacts, but on the RC2 these artifacts change from run to
run, without changes to the code... this is a bit annoying, because
sometimes they are soft and subtle, but other times they are hard shaped
and very evident.

   Until I prepare a minimal scene showing the problem, does anyone
(clipka, I suppose... ;) know if any of the recent radiosity changes may
have induced this behavior? ...just by reading the release notes I don't
see anything too evident (to me).

   Regards,


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

> Until I prepare a minimal scene showing the problem, does anyone
> (clipka, I suppose... ;) know if any of the recent radiosity changes
> may have induced this behavior? ...just by reading the release notes
> I don't see anything too evident (to me).

   Ok, finally I found it... but took me a while to figure it out:
forcing "always_sample on" on the loading pass fixed the random
artifacts, or at least now they are not noticeable.

   It was a bit unexpected, as it always worked fine to set it "on"
during the save pass, and "off" during the loading pass... it even seems
to make sense: on the second pass you would just want to load the data
gathered on the first pass, without any extra calculation.

   The only explanation that seems to make sense is that "always_sample
off" was not working before, but now, with the recent change to "off" by
default, I need to turn it on for the second pass to avoid artifacts...
but I'm surely wrong, as usual.

   Regards,

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > Until I prepare a minimal scene showing the problem, does anyone
> > (clipka, I suppose... ;) know if any of the recent radiosity changes
> > may have induced this behavior? ...just by reading the release notes
> > I don't see anything too evident (to me).

>    Ok, finally I found it... but took me a while to figure it out:
> forcing "always_sample on" on the loading pass fixed the random
> artifacts, or at least now they are not noticeable.

>    It was a bit unexpected, as it always worked fine to set it "on"
> during the save pass, and "off" during the loading pass... it even seems
> to make sense: on the second pass you would just want to load the data
> gathered on the first pass, without any extra calculation.

>    The only explanation that seems to make sense is that "always_sample
> off" was not working before, but now, with the recent change to "off" by
> default, I need to turn it on for the second pass to avoid artifacts...
> but I'm surely wrong, as usual.

  Perhaps if radiosity data is loaded, the setting could be turned on
automatically, if that's what normally should be done anyways. (If someone
wanted it to be turned off regardless, he could always do it explicitly.)

-- 
                                                          - Warp

Post a reply to this message

On 01/13/2011 05:49 AM, Jaime Vives Piqueres wrote:
>   It was a bit unexpected, as it always worked fine to set it "on"
> during the save pass, and "off" during the loading pass... it even seems
> to make sense: on the second pass you would just want to load the data
> gathered on the first pass, without any extra calculation.

Hmmm ... IIRC aren't there a couple of parameters that /have/ to be the
same during the save AND load passes in order to get the best results
... count and error_bound seem to be ringing a bell.

Having to specify always_sample on during load DOES seem to be contrary
to why you would say off (default) ... time savings

The doc passage:
http://wiki.povray.org/content/Documentation:Reference_Section_3.2#always_sample

seems to being saying that there MAY be cases that you would have to
"override the behavior"

Jim

Post a reply to this message

> Perhaps if radiosity data is loaded, the setting could be turned on
> automatically, if that's what normally should be done anyways. (If
> someone wanted it to be turned off regardless, he could always do it
> explicitly.)
>

   Having looked now to the wiki docs pointed by Jim, I see now that I
always misunderstood what always_sample was doing... :( It has nothing
to do with the load/save mechanism: it's all about the pretrace step.

   So, it makes sense to keep it turned on when you are NOT using
pretrace on the loading pass, as it is my case. What I don't understand
is why it wasn't giving me random artifacts before the change of the
default value...


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

> Hmmm ... IIRC aren't there a couple of parameters that /have/ to be
> the same during the save AND load passes in order to get the best
> results ... count and error_bound seem to be ringing a bell.

   Yes, and I'm using the same for both passes, except for pretrace start
and end, which I set to 1 on the second pass to save time. Also, until
now I was turning always_sample off in order to save more time, without
realizing that it was not necessary because there is no pretrace step on
the second pass.

>
> Having to specify always_sample on during load DOES seem to be
> contrary to why you would say off (default) ... time savings
>
> The doc passage:
> http://wiki.povray.org/content/Documentation:Reference_Section_3.2#always_sample
>
>  seems to being saying that there MAY be cases that you would have
> to "override the behavior"
>

   As I said to Warp, I see now that I was misunderstanding what it does...

   Anyhow, I still don't get it: you would think that taking more samples
will be slow, but always better to reduce artifacts and get more
quality, isn't?

   Also, I don't understand why I get really weird, random artifacts if I
turn it off during the load pass (they were not there during the first
pass, for sure). I'm not using pretrace on the second pass (by setting
it to 1), so you would think that it should not matter if always_sample
is on or off...

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

>> Hmmm ... IIRC aren't there a couple of parameters that /have/ to be
>> the same during the save AND load passes in order to get the best
>> results ... count and error_bound seem to be ringing a bell.
>
> Yes, and I'm using the same for both passes, except for pretrace start
> and end, which I set to 1 on the second pass to save time. Also, until
> now I was turning always_sample off in order to save more time, without
> realizing that it was not necessary because there is no pretrace step on
> the second pass.
>
>>
>> Having to specify always_sample on during load DOES seem to be
>> contrary to why you would say off (default) ... time savings
>>
>> The doc passage:
>> http://wiki.povray.org/content/Documentation:Reference_Section_3.2#always_sample
>>
>>
>> seems to being saying that there MAY be cases that you would have
>> to "override the behavior"
>>
>
> As I said to Warp, I see now that I was misunderstanding what it does...
>
> Anyhow, I still don't get it: you would think that taking more samples
> will be slow, but always better to reduce artifacts and get more
> quality, isn't?
>
> Also, I don't understand why I get really weird, random artifacts if I
> turn it off during the load pass (they were not there during the first
> pass, for sure). I'm not using pretrace on the second pass (by setting
> it to 1), so you would think that it should not matter if always_sample
> is on or off...
>

If you want to totaly suppress the pretrace step, don't change 
pretrace_start. Just set pretrace_end to a value larger than 0.08, like 
pretrace_end 1.




Alain

Post a reply to this message

Am 13.01.2011 14:23, schrieb Jaime Vives Piqueres:

> Anyhow, I still don't get it: you would think that taking more samples
> will be slow, but always better to reduce artifacts and get more
> quality, isn't?

The problem with "always_sample on" is that those additional samples 
will be taken into account only for /some/ pixels (namely those pixels 
that are computed after the respective sample is taken); so you get 
areas that are more accurate than others, with hard boundaries between 
them (render blocks for instance). That typically looks worse than 
sticking with the less accurate result. (Unless the increase in accuracy 
is extremely minor, but in that rare case there's obviously no point in 
taking those additional samples anyway.)

Post a reply to this message

Am 13.01.2011 13:57, schrieb Jaime Vives Piqueres:

> Having looked now to the wiki docs pointed by Jim, I see now that I
> always misunderstood what always_sample was doing... :( It has nothing
> to do with the load/save mechanism: it's all about the pretrace step.
>
> So, it makes sense to keep it turned on when you are NOT using
> pretrace on the loading pass, as it is my case.

No. I can imagine exactly /one/ reason to use "always_sample on": To 
trim down on pretrace for a speedy low-quality render.

Other than that, it is absolutely, positively better to use more 
pretrace, and set always_sample off (or at least that's the way it 
should be, in the absence of any bugs).

> What I don't understand
> is why it wasn't giving me random artifacts before the change of the
> default value...

This whole thing is a puzzler to me, too; unfortunately I haven't found 
the time to dig into it yet. My only idea is that something might get 
garbled during saving/loading of the pretrace data.

Post a reply to this message

>> What I don't understand
>> is why it wasn't giving me random artifacts before the change of the
>> default value...
>
> This whole thing is a puzzler to me, too; unfortunately I haven't found
> the time to dig into it yet. My only idea is that something might get
> garbled during saving/loading of the pretrace data.

   I guess there is more than one issue here... I've just tested with a 
simple scene, *without* saving or loading radiosity, just a simple 
radiosity scene, and I get different results at each run:

// -------------------------------------------
#version 3.7;

#include "rad_def.inc"
global_settings{
  radiosity{
  }
}

#default{texture{finish{ambient 0 diffuse 1}}}

#include "colors.inc"

box{-.5,.5
   scale <10,3,10>
   pigment{White}
   translate 1.5*y
}

light_source{
  <0,2.99,0>
  White*3
  fade_distance 1
  fade_power 2
}

camera{
  location <1,1.6,-4>
  look_at <0,1.5,0>
}
// -------------------------------------------


   If I run two consecutive renders of this scene and difference the 
results, with 3.6 I get a totally black image (as it was expected). With 
3.7 I get visible differences... Using the save/load mechanism only 
seems to make it worse and more noticeable.

   I'm starting to think this is a problem with my build... something 
must have been gone wrong when compiling the RC2 sources, because I 
don't see anywhere mentioned that radiosity samples are now random for 
each run. Can anyone do a quick test?

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message