On 05/02/2023 8:33 PM, Bald Eagle wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
> 
>> Thanks for that. I am getting a patchy illumination, when I animate it
>> there is inconsistency between frames. Any thoughts?
> 
> I would say #include the rad_def.inc file and then put this in your scenefile
> "header":
> 
> #include "rad_def.inc"


I did try that file, even on the best settings I still get flicker.

m@

Post a reply to this message

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)

This helped, the blotchiness is acceptable for a still image but still 
jumpy in animation.

Raising the 'scope - yes, good point.

On 06/02/2023 2:14 AM, Alain Martel wrote:
> Le 2023-02-05 à 05:42, m@b a écrit :
> 
> 
> You need to increase the sample value.
> Using the two values version may help.
> Have the pretrace go deeper.
> As for the count, use the two values version for nearest_count.
> 
> Try this version :
> 
> global_settings {
>   assumed_gamma 1
>   #if (Radiosity)
>    radiosity {
>     pretrace_start 0.04
>     pretrace_end 0.0025 // or even 0.00125
> Content-Type: multipart/mixed; 
> boundary="------------0rgDYJuCNp1Z4Md0WnOykdJ3"
> Date: Sun, 5 Feb 2023 18:42:09 +0800
> MIME-Version: 1.0
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) 
> Gecko/20100101
> Thunderbird/102.6.1
> Subject: Re: Oscilloscope
> Content-Language: en-US
> Newsgroups: povray.binaries.images
> References: <63de46eb@news.povray.org>
> <web.63de754733e903b1f9dae3025979125@news.povray.org>
> From: "m@b" <sai### [at] googlemailcom>
> In-Reply-To: <web.63de754733e903b1f9dae3025979125@news.povray.org>
> NNTP-Posting-Host: 122.2.111.112
> Message-ID: <63df880b@news.povray.org>
> X-Trace: news.povray.org 1675593739 122.2.111.112 (5 Feb 2023 05:42:19 
> -0500)
> Lines: 15631
> X-No-Archive: Yes
> X-Copyright: This copyrighted article comes from a private news server 
> and may NOT be distributed on USENET or other news servers.
> X-POV-Header: --- --- --- --- --- --- --- --- --- --- --- ---
> Path: news.povray.org!not-for-mail
> Xref: news.povray.org povray.binaries.images:146685
> 
> This is a multi-part message in MIME format.
> --------------0rgDYJuCNp1Z4Md0WnOykdJ3
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> On 04/02/2023 11:09 PM, Bald Eagle wrote:
>>
>> Nice!
>>
>> Try it with radiosity and using the background image as an hdr light 
>> source:
>>
>> global_settings {
>>   assumed_gamma 1
>>   #if (Radiosity)
>>    radiosity {
>>     pretrace_start 0.04
>>     pretrace_end 0.01
>>     count 200
>>     recursion_limit 3
>>     nearest_count 10
>>     error_bound 0.5
>>    }
>>   #end
>> }
>>
>>
>>
>> #declare Environment =
>> sphere {
>>   0, 1
>>   hollow on
>>   material {
>>    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.
> 
> m@
> --------------0rgDYJuCNp1Z4Md0WnOykdJ3
> Content-Type: image/png; name="CRO 01.png"
> Content-Disposition: attachment; filename="CRO 01.png"
> Content-Transfer-Encoding: base64
> 
> iVBORw0KGgoAAAANSUhEUgAAA1YAAAHgCAIAAAApMmt9AAAABGdBTUEAALGPC/xhBQAAAANz
> QklUCAgI2+FP4AAAAAd0SU1FB+cCBQonGTmyvbsAAAAedEVYdFNvZnR3YXJlAFBPVi1SYXkg
> djMuOC4wLWJldGEuMeAriKEAAABXdEVYdENvbW1lbnQAUmVuZGVyIERhdGU6IDIwMjMtMDIt
> MDUgMTA6Mzk6MjVaClBsYXRmb3JtOiBpNjg2LXBjLXdpbi1zc2UyCkNvbXBpbGVyOiBtc3Zj
> IDE0ClqZthsAACAASURBVHic7L1Lr23bcR72VdWYa+/zuk9e8vJNiTIpxZTlJHYsCVaCJAJs
> A0ksIG5YQFppBPlX6aWdAIHhjhUYMBTFii1ZpiVcipJFUnxe3se555y915pzVJUbVTXGWOdK
> gNVgoIYWL/fZe6015xyPenz1HPSP/tf/DnCYAyAgfzoAYiICxYuJmYiJiZjjVyI4HESA5wvu
> 7oC7uQNwc4fD6wsA8oe7mYMov+oez447IH6NSz3/8HGlu7sTMC6sS8jdchL1XeS9AMy7Ony+
> Fc8B4HC38UAiGk/EuDoHMK9EjtHN6mtEpm6qbkZELMxEQCwYAUQUw6th5l3hbsub46vxBtXN
> EctOuQHLvBzMFNcxMxGZqbsTCzPPG6N2FBT3HXePzY67mbubE+etxvrHFMzM3c0sro5Pzd3M
> 3HILYotzCc1NzcxVrWs3Nbe4B5JqQICbKUjb1l5/61Nvf/7zW9u20ybbdjnv9y/uP/jRu8/e
> f79rByHoETVaV8sRuMHV4W4+hgEAxLWslEQVWyMUaxN7kEtKRiDUrJnYQYMsAfTDTI3g3JhF
>   // more pretrace sampling almost always reduce noise and artefacts.
>     count 350 999 // Should reduce those dark splotches.
>   // Second value set a sampling direction pool.
>   // Second value MUST be greater than the first
>     recursion_limit 2 // 1 may even be enough.
>     nearest_count 20 5 // enable adaptive sampling and pretrace
>   // second value must be the smaller one.
>   // Larger first value often help to reduce the dark splotches,
>   // and also make then less sharp.
>     error_bound 0.35
>    }
>   #end
> }
> 
> Try raising the oscilloscope a little bit above the table. After all, 
> most have rubber pads under them acting as short legs.

Post a reply to this message

On 04/02/2023 7:51 PM, m@b wrote:
> My latest effort.
> 
> Background from here: <https://polyhaven.com/a/vintage_measuring_lab>
> 
> m@

Thanks for the input everybody. It seems likely that there will always 
be some flicker when using radiosity in an animation. (As explained by 
Kenneth above)

The answer in this case is to save a radiosity data file and then load 
it in each frame, this has time advantages as well. Obviously this 
method will not work when I start moving the camera around.

I was not happy with the background contrast, so I added the a png 
sphere just inside the hdr sphere with no_shadow and no_radiosity so I 
cam mess with the background emission and gamma without affecting radiosity.

Post a reply to this message

Attachments:
Download 'cro ws 02.mp4.dat' (153 KB)

"m@b" <sai### [at] googlemailcom> wrote:
> >
> 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.
>

You got a more obvious improvement re: High_Reproducibility than I did in my own
tests. Thanks for the comparison. I need to revisit that feature, to find out
if/ how much other rad settings affect it.

Post a reply to this message

Le 2023-02-06 à 02:41, m@b a écrit :
> This helped, the blotchiness is acceptable for a still image but still 
> jumpy in animation.
> 
> Raising the 'scope - yes, good point.
>

Try those one by one :
Slightly increasing error_bound (this will make the rendering go a 
little bit faster)
(your actual value is 0.35)
error_bound 0.37
error_bound 0.4
error_bound 0.44

Increase count
count 450 12347
count 700 25000
nearest_count 20 7

Set minimum_reuse slightly smaller than pretrace_end such as :
(default is minimum_reuse 0.015 for a default pretrace_end of 0.04)
pretrace_end 0.0025
minimum_reuse 0.002

pretrace_end 0.00125
minimum_reuse 0.001

Set low_error_factor to a smaller value (default is 0.5)
low_error_factor 0.3
low_error_factor 0.1

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> On the screen changes being an issue. If we change the screen's finish
> to { emission 0 ambient 1 }, would we get the bright screen without any
> light contribution to radiosity? I don't know...?
>
Well, unfortunately (or fortunately, depending on how you look at it!), ambient
is now completely turned off when radiosity is used, so I can't test the idea in
v3.8. Only emission and diffuse are active.

I also thought about the 'no_radiosity' switch for certain objects. If the
oscilloscope screen is actually a separate object, maybe that would help?
Honestly, I'm not completely sure I understand that feature, from the docs'
description. But in my own test scene, I have a sky_sphere with a pigment; if I
add 'no_radiosity' to it, that does indeed turn off any radiosity-light
contribution from it.

Post a reply to this message

On 2/6/23 02:37, m@b wrote:
> 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.

Thanks much for all the performance and visual difference animations!!!

I once stumbled across the +HR code. IIRC the ordering mechanism isn't 
as optimized as it could be - with much more complicated code. That 
said, any +HR mechanism will always be slower.

Bill P.

Post a reply to this message

On 2/6/23 09:26, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> On the screen changes being an issue. If we change the screen's finish
>> to { emission 0 ambient 1 }, would we get the bright screen without any
>> light contribution to radiosity? I don't know...?
>>
> Well, unfortunately (or fortunately, depending on how you look at it!), ambient
> is now completely turned off when radiosity is used, so I can't test the idea in
> v3.8. Only emission and diffuse are active.
> 
> I also thought about the 'no_radiosity' switch for certain objects. If the
> oscilloscope screen is actually a separate object, maybe that would help?
> Honestly, I'm not completely sure I understand that feature, from the docs'
> description. But in my own test scene, I have a sky_sphere with a pigment; if I
> add 'no_radiosity' to it, that does indeed turn off any radiosity-light
> contribution from it.
> 
> 
Thanks for the confirmation on ambient and emission together with 
radiosity.

I too forgot about the no_radiosity keyword! I believe this the better 
approach to make the screen invisible to radiosity rays, but as you said 
it would need to be built in such a way all the glowing bits are 
represented as stand alone objects such that the keyword could be used.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> I too forgot about the no_radiosity keyword! I believe this the better
> approach to make the screen invisible to radiosity rays, but as you said
> it would need to be built in such a way all the glowing bits are
> represented as stand alone objects such that the keyword could be used.

I professional photography, they will use an-off camera reflector for
fill-lighting.

Can the reverse be done?  What if you shielded the screen with a black square or
mesh, and used no_object so that it wasn't visible?  Or something semi-opaque
that would still allow lighting, like a diffuser on a light-bulb?

This is a beautiful scope model, and the animated lissajous curves are nice  :)

- BE

Post a reply to this message