POV-Ray : Newsgroups : povray.binaries.images : Oscilloscope Server Time
28 Mar 2024 17:31:53 EDT (-0400)
  Oscilloscope (Message 1 to 10 of 29)  
Goto Latest 10 Messages Next 10 Messages >>>
From: m@b
Subject: Oscilloscope
Date: 4 Feb 2023 06:52:11
Message: <63de46eb@news.povray.org>
My latest effort.

Background from here: <https://polyhaven.com/a/vintage_measuring_lab>

m@


Post a reply to this message


Attachments:
Download 'cro 01a.png' (1180 KB)

Preview of image 'cro 01a.png'
cro 01a.png


 

From: Bald Eagle
Subject: Re: Oscilloscope
Date: 4 Feb 2023 10:15:00
Message: <web.63de754733e903b1f9dae3025979125@news.povray.org>
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  ;)


Post a reply to this message

From: Tor Olav Kristensen
Subject: Re: Oscilloscope
Date: 4 Feb 2023 17:40:00
Message: <web.63dedc6e33e903bd0d6e0d389db30a9@news.povray.org>
"m@b" <sai### [at] googlemailcom> wrote:
> My latest effort.
>...

Nice modelling. I guess it was a lot of work.

I really like these old analogue oscilloscopes.
I even have an Advance Instruments OS1000A laying round somewhere IIRC.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

From: m@b
Subject: Re: Oscilloscope
Date: 5 Feb 2023 05:42:19
Message: <63df880b@news.povray.org>
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@


Post a reply to this message


Attachments:
Download 'cro 01.png' (492 KB) Download 'povout.mp4.dat' (329 KB)

Preview of image 'cro 01.png'
cro 01.png

From: Bald Eagle
Subject: Re: Oscilloscope
Date: 5 Feb 2023 07:35:00
Message: <web.63dfa23733e903b1f9dae3025979125@news.povray.org>
"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"
global_settings {
     radiosity {
          Rad_Settings(Radiosity_Default, off, off)
     }
}

leave the last two switches to off, as they are for normals and media.

I think you can use one of the text definitions in the beginning of the file, or
use a number from 1-10;

- BE


Post a reply to this message

From: Alain Martel
Subject: Re: Oscilloscope
Date: 5 Feb 2023 13:14:40
Message: <63dff210$1@news.povray.org>
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
  // 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

From: William F Pokorny
Subject: Re: Oscilloscope
Date: 5 Feb 2023 16:41:59
Message: <63e022a7$1@news.povray.org>
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.

- 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.

- 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.

- 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.


Post a reply to this message

From: Bald Eagle
Subject: Re: Oscilloscope
Date: 5 Feb 2023 19:05:00
Message: <web.63e0439833e903b1f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> 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. :-)

Well I didn't code it either - IIRC, it was a code block that someone suggested
when I was trying to use an hdr environment to get a better looking render.

The scene looked flat, and I figured that maybe he was just using a "background"
and not exploiting the full benefit of the (what seemed to me to be) and hdr
image.

So I just dipped into the archive, found the scene, and copy-pasted.

"Because I'm lazy, and don't know anything about all those specialized options
and flags....?"  :)

Good points below, I figured there was also some sort of randomization invoved
with radiosity, but didn't know what, or if it was user controllable.   I just
felt that we'd deal with that issue if and when it came up.

> 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.
>
> - 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.
>
> - 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.
>
> - 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.


Post a reply to this message

From: Kenneth
Subject: Re: Oscilloscope
Date: 6 Feb 2023 01:40:00
Message: <web.63e09f2c33e903b9b4924336e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> - 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.

That would be Stochastic_Seed= -some number-, or +SSn. I was wondering about
those dark grid lines too; maybe a result of the animation's render size as
well? I would imagine that a larger render would keep the lines intact.

> - 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. A more reliable alternative
> is to use single threads for each frame (+wt1)...
>

I tried this single-thread experiment in the past and still saw flickering
radiosity color patches during animation-- but that was probably because I
mistakenly used a moving camera.

But it does indeed completely eliminate the flicker! (Neither high-quality rad
settings nor the 'high reproducibility' switch can do that so well, according to
my own tests.) The only restriction is that the scene has to be completely
static (like m@b's  here)-- no moving objects or camera. Even the moving
waveform on the  oscilloscope could cause some tiny amount of flickering on
other objects, although it would probably be unnoticeable.

Some interesting facts when using this single-thread idea:
My machine has 8 cores/16 threads. Using just 1 thread, my own animation test
was only about 3 times slower-- not 16 times or even 8 times, which is what I
was expecting. That's good news!

But  the statictics in the 'messages' pane are,
"Render Time:
          Radiosity Time: ... using 2 threads
          Trace Time: ... using 1 thread"

Two threads for the radiosity?

This flickering effect of rad during animation would seem to come from one of
two sources: Either the SMP nature of multi-threading, or the random nature of
the light patches themselves from frame to frame (i.e., chosen from different
locations in the scene for each new frame.) Currently, there is no 'switch' to
lock-in those locations-- which would be kind of similar 'in concept' to the
newer antialiasing/jitter mechanism of AA Sampling_Method 3 and Stochastic_Seed,
which eliminates otherwise-random AA jitter during animation:

"(By default,) the corresponding pseudo-random number generators are seeded with
a value derived from the current date and time. If the Stochastic_Seed=n or +SSn
option is specified, the seed will instead be derived from the specified value,
allowing to produce exactly the same output each time by specifying that same
value."

A similar concept for radiosity would be really helpful.

My guess is that running an *animation* with radiosity was never taken into
account when rad was first added to POV-ray...possibly because it took so long
to render even a single image then!


Post a reply to this message

From: William F Pokorny
Subject: Re: Oscilloscope
Date: 6 Feb 2023 02:08:15
Message: <63e0a75f$1@news.povray.org>
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

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.