 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/6/23 01:33, Kenneth wrote:
> Two threads for the radiosity?
Not sure. Faint ding, ding in my empty skull - along the lines of my
having looked a little at this question in the past, but just getting
nothing clear.
In addition to any camera (or other) movement / change affecting a
frame's radiosity results - area_light jitter, photon jitter, crand (and
perhaps other options) introduce render to render changes too.
While reading your post I wondered if re-using radiosity samples would
result in more frame to frame stability. A while ago now we looked some
at radiosity sampling in animations IIRC.
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...?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/02/2023 8:33 PM, Bald Eagle wrote:
> "m@b" <sai### [at] googlemail com> 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
|
|
| |
| |
|
|
|
|
| |
