On 10/15/21 5:14 AM, jr wrote:
> hi,
> 
...
> 
>> ---
>>
>> The flowers.pov file already has the tabulated.inc guard set to 1
>> contrary to the scene's comments.
> 
> Thomas held up his hand, but I did not "see" it either.  will change the
> default, and thinking of adding an '#if' guard in 'flowers_read.pov' too.
> 

Adding it too flowers_read.pov would be helpful. Aiding my confusion as 
to how the animation was supposed to work was the table being in the 
background showing about half red(1) entries and yellow entries - which 
I rather dumbly took as some indication of what I should see for 
distribution for flower colors.

(1) The initial set of flowers end up orange. Maybe?

#declare AmericanRose = srgb <1,0.01176,0.24314>;
...
pigment {AmericanRose*0.5}


> 
>> ---
>>
>> The flowers_read.pov animation doesn't look to me to be picking up all
>> the yellow flowers? Maybe one or two per asteroid? I didn't investigate
>> though, perhaps it's working as expected?
> 
> the animation runs from planting the last few reds to the first few dozen
> yellows only.
> 

Thanks Thomas, I now understand.

> 
>> ---
>>
>> With the flowers.ini AA, at least on linux with v3.8 and povr, the
>> method 3 AA doesn't look very good. Perhaps something like:
>>
>> sampling_method = 2
>> antialias_threshold = 0.005
>> antialias_depth = 3
>> jitter = on
> 
> as Thomas wrote, setting the 'file_gamma' in the ini was a bad idea, will remove
> it.  does removing it address the issue without changing 'sampling_method' etc?
> 

I dug a little. The ugly background table AA comes from using 
'antialias_gamma = 1' though the file_gamma at 1.0 makes the saved 
images linear/dark too. Both settings should go away.

Of interest, perhaps, regarding aa method 3 here. I measured these times 
and results on my Ubuntu 20.04 system.

  8.16cpu 0:03.16elapsed (antialias_gamma = 1; shipped result ugly)
26.76cpu 0:07.89elapsed (No antialias_gamma = 1; result good)
19.31cpu 0:06.10elapsed (No antialias_gamma = 1; result good; povr(*))

(*) Here the development compile being used is not that optimized and 
it's still faster. This is demonstrating the povr branch's fix to 
prevent the color channel sqrt() of negative values and subsequent 
undefined behavior. With povr the method 3 AA isn't sometimes running 
exhaustively to the recursion limit no matter other settings.

First, I screwed up on my recommendation in not have the 
antialias_threshold at 0.0. The fastest good result I see for the 
suggested render sizes, if that's your aim when shipping the package, is 
to use:

sampling_method = 2
antialias_threshold = 0.0
antialias_depth = 2
jitter = off
// 10.85user 0.09system 0:03.86elapsed

With the background table we have a very regular grid and this a case. 
Ultimately, we have to shoot enough rays to 'see' the detail we want 
cleanly visible.

The method 3 AA often works, but it presently has a known weakness in 
not being able to force an initial minimum set of samples (and this 
should probably be done to some isotropic density of samples).

The faster method 2 approach above might miss detail too at other render 
resolutions / aspect ratios.

...
> 
>> ---
>>
>> With the toa example, where the "toa_state.txt" or "toa_run.log" already
>> exist we get an error message via toal__chkFilesExist(), but the error
>> message only says "existing file(s)" were found.
> 
> or, conversely, "missing file(s)".  my thinking was/is that for animation run, I
> only need to know whether both or neither (state + log) exist, depending on
> frame_number, so the macro only provides a result for that.  how should I write
> the corresponding messages to read better?
> 

I'm a fan of seeing the actual file names if relatively easy, but at a 
minimum maybe something like "existing output files()" were found. 
(Missing input...?). Maybe the issue not that important with other 
include sorted.

My initial animation render didn't work because I was missing an 
include. That first attempt did create those two output files, but I 
didn't notice. And because I'd played around with the earlier demos I 
first thought perhaps I'd created some file which was colliding with the 
toa demo. I was slow to realize I had created files on the first failed 
attempt which were now an issue. If everything is cleaner from the 
start, there will be less potential for confusion.

Bill P.

Post a reply to this message