On 06/02/2023 5:41 AM, William F Pokorny wrote:
> On 2/5/23 05:42, m@b wrote:
>>>    texture { uv_mapping
>>>     pigment {
>>>      image_map {
>>>       hdr "FILENAME.hdr"
>>>       gamma 1.5
>>>       map_type 0
>>>       interpolate 2
>>>       once
>>>      }
>>>     }
>>>    finish {emission 1}
>>>    }
>>>   interior { ior 1.0 }
>>>   }
>>>   no_shadow
>>> }
>>>
>>> object { Environment scale 1000} // might have to adjust  😉
>>>
>>
>> Thanks for that. I am getting a patchy illumination, when I animate it 
>> there is inconsistency between frames. Any thoughts?
>>
>> The only change I made was to reduce the Environment gamma to 1, the 
>> scene was over-illuminated at 1.5.
> 
> Bill W. - Is there a reason for using uv_mapping with map_type 0 over 
> map_type 1 only in the image_map block? I think what you have OK, but 
> it's not how I would have coded the mapping. :-)
> 
> Random thoughts / questions.
> ---------------------------
> 
> - With .exr and .hdr images the file gamma should always be left at 1.0. 
> These files have values in both the [0,1) range and [1,1+]. This means 
> any gamma other than 1.0 creates adjustments which move in opposite 
> directions depending upon whether particular color channel values at a 
> given pixel <1 or >=1. It 'should be' any .hdr, .exr file one finds out 
> and about was written at a gamma of 1.0. IIRC, POV-Ray itself cannot 
> write .hdr / .exr files at other than 1.0.
> 
Yes - Already discovered :-)

> - With .exr and .hdr images, interpolation is I believe iffy. The image 
> interpolation code was written for [0,1] ranges. I usually use no 
> interpolation with high dynamic range images and move to higher 
> resolution environment maps if need be. However, I've not 'really' 
> looked at how the different interpolation options work with typical .exr 
> and .hdr images.

Interpolation turned off – no change in timing, no improvement observed. 
I turned it back on again!

> 
> - With respect to blotchiness frame to frame, remember, v3.7 introduced 
> the radiosity high reproducibility option. Use High_Reproducibility / 
> +HR on the command line or in the ini file. An more reliable alternative 
> is to use single threads for each frame (+wt1). This, though, might lead 
> one to manually break up the rendering of frames into buckets to make 
> use of all your cores / threads.
> 
High_Reproducibility increased the frame time from 0:53 to 3:30.
The exhibit below has High_Reproducibility on for the first half then 
off. Some improvement.

> - Puzzling to me - some of the dark grid lines on the screen flicker in 
> and out of existence during the render...? Unsure why this would happen 
> unless perhaps using method 3 anti aliasing? If using method 3 remember 
> you need to specify the seed used (can't recall the ini/command line 
> option +ss maybe?) to keep results consistent render to render.
> 
> Bill P.

Changed to anti aliasing method 1 – no visible difference. This problem 
goes away when I do a final render at higher resolution.

m@

Post a reply to this message

Attachments:
Download 'high_reproducibility=on then off.mp4.dat' (176 KB)