 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"m@b" <sai### [at] googlemail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
