Am 24.02.2016 um 18:32 schrieb ThH:

> Now for some more investigation... ;)

optics_mod_2.pov + pics

So far: Comment out 1 photon related command of your choice and the pics 
are optically identical.

Will continue...

Post a reply to this message

Attachments:
Download 'optics_mod_2.pov.txt' (2 KB) Download 'optics_mod_2_3.7.0.png' (82 KB) Download 'optics_mod_2_3.7.1.png' (87 KB)

Preview of image 'optics_mod_2_3.7.0.png'

Preview of image 'optics_mod_2_3.7.1.png'

Am 24.02.2016 um 18:10 schrieb Le_Forgeron:

> Just one year of patches to check...

Binary search FTW.

For starters, please focus on the commits that changed
`source/core/lighting/photons.cpp`, `source/core/material/media.cpp`,
and/or `source/core/render/trace.cpp`:

3c719d20822eae09e586fa5fb6685f7228872040 (3 Jan 2016)
a4c66a28ffdffe1296e44d1ad587ba93886ec925 (2 Jan 2016)
87de094585c4c8904b1c77124a4218567097dad4 (1 Jan 2016)
6d20f85957cca8e6acc22ad87485665524f363a9 (1 Jan 2016)
49835074f55e1027d97e7260b16bac43a6bc7059 (15 Nov 2015)
93b9ae98eaa28fdc1ada1ce9ccc59150fc037141 (12 Sep 2015)
3e93e2e2a1a4ccec034d7666d41f78ffb1ebf00f (11 Sep 2015)
04ed70261ff8cc1e2a02ec226a4fe0f1ef6177bf (5 Aug 2015)
117f215c5efb9e0d69703a520eff04713de72778 (5 Aug 2015) [p]
1b5aab60b0f15de4e8170bbec3820c5236c353d8 (27 Jun 2015)
6ed60adea3195995492635aa27c7c2db018717cc (5 Mar 2015) [m,t]

[p] I currently have no list of relevant commits to `photons.cpp` prior
to this one, as the file resided in a different location.

[m,t] I currently have no list of relevant commits to `media.cpp` and
`trace.cpp` prior to this one, as the files resided in a different location.

You may first want to check the following commit though; it is known to
build ok on Unix, and dates back just a few days earlier:

0c7f9773c6bbdd3bddcce2475d6e374ab2292ae6 (3 Mar 2015)

Note that some of the other commits may fail to compile on Unix. I trust
you to be able to deal with this one way or the other.

Post a reply to this message

Le 25/02/2016 03:49, clipka a écrit :
> Am 24.02.2016 um 18:10 schrieb Le_Forgeron:
> 
>> > Just one year of patches to check...
> Binary search FTW.

If only all commits were able to be compiled...

The problem is any commit
from 2014-06-14 14:26:48 +0200
to 2014-07-02 04:05:34 +0200

Far before any of your candidates.

Post a reply to this message

Attachments:
Download 'result.txt' (6 KB)

Am 25.02.2016 um 19:08 schrieb Le_Forgeron:
> Le 25/02/2016 03:49, clipka a écrit :
>> Am 24.02.2016 um 18:10 schrieb Le_Forgeron:
>>
>>>> Just one year of patches to check...
>> Binary search FTW.
> 
> If only all commits were able to be compiled...
> 
> The problem is any commit
> from 2014-06-14 14:26:48 +0200
> to 2014-07-02 04:05:34 +0200
> 
> Far before any of your candidates.

(Are you sure your list is complete? I do see more commits in between
those you cite, even on the same branch.)

The following look noteworthy to investigate:

changeset:   94:8e40f1a50cfd
parent:      92:e995e1ab7beb
parent:      93:a07181fe86db
user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
date:        Thu Jun 19 10:24:56 2014 +0200
summary:     Merge branch 'master' into refactor

and then:

changeset:   96:f2d948f2a077
bookmark:    hotfix/photons_eca922a2
tag:         default/hotfix/photons_eca922a2
user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
date:        Wed Jun 25 16:42:36 2014 +0200
summary:     fix photons bug introduced with commit
'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'

In between these, we have a change in how photon colour/brightness data
is stored.

Do you think you can try to get these to compile by applying the Jun/Jul
2014 series of "GitHub issue #29" fixes to them?

Post a reply to this message

Am 26.02.2016 um 05:44 schrieb clipka:

> The following look noteworthy to investigate:
> 
> changeset:   94:8e40f1a50cfd
> parent:      92:e995e1ab7beb
> parent:      93:a07181fe86db
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Thu Jun 19 10:24:56 2014 +0200
> summary:     Merge branch 'master' into refactor
> 
> and then:
> 
> changeset:   96:f2d948f2a077
> bookmark:    hotfix/photons_eca922a2
> tag:         default/hotfix/photons_eca922a2
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Wed Jun 25 16:42:36 2014 +0200
> summary:     fix photons bug introduced with commit
> 'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'
> 
> In between these, we have a change in how photon colour/brightness data
> is stored.

I think I'm up to something here.

The changes between these two commits are all about the encoded storage
of photons in an RGBE format, which is an adaptation of the floating
point idea to the domain of colours, using three independent mantissas
for the colour channels but a single shared exponent. This idea is also
at the core of the Radiance HDR image file format.

Photon storage and the Radiance HDR image file format use virtually the
same variation of the format, using 8-bit unsigned integers for both the
mantissas and the exponent, with the one exception that for photons an
exponent bias of 250 was chosen, while Radiance HDR uses a bias of 128.

Originally, the data type for photons storage was a simple C-style
4-element unsigned char array, with associated C-style global functions
for encoding and decoding. The Radiance HDR file format handling used
its own independent functions doing virtually the same thing.

Now in the aforementioned changes, this was refactored into a common
C++-style template class type for both photons and Radiance HDR code.

Having looked again at that changed code, I noticed some peculiarities
about the code that I didn't quite understand (yes, I know I wrote the
code myself ;)), and which I currently consider inferior, but I also
wasn't quite sure what that "photons bug introduced with commit
'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'" was that had to be fixed
back then, and whether those peculiarities were there for a reason, so I
decided to revert those changes to revive that bug again.

I immediately recognized the resulting "optics.pov" render as the thing
that prompted me to implement the fix, so I'm sure again what it was all
about: In the process of refactoring I had made a slight "improvement"
that turned out to add a little bit of white light to otherwise pure
colours.

Now this doesn't look anything like what ThH has reported, nor what
you're seeing in your tests; but there is someting intriguing about it
that hadn't caught my attention back then:

It doesn't affect /all/ the rays.

As a matter of fact, it affects /exactly/ the very same subset of rays
as the issue now under investigation.


I think this is very strong evidence that the current issue is also
rooted in the RGBE handling code.

Post a reply to this message

Attachments:
Download 'optics.png' (284 KB)

Preview of image 'optics.png'

Am 24.02.2016 um 14:24 schrieb ThH:
> optics.pov from scenes/advanced...
> 
> The appended files had been rendered using povray V3.7.0 and Version
> 3.7.1-alpha.8492620.unofficial.

Can someone please test this version:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110

I have no idea whether it will fix anything, but there is a glimmer of
hope that it just might.

Post a reply to this message

Am 27.02.2016 um 07:59 schrieb clipka:

> Can someone please test this version:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>
> I have no idea whether it will fix anything, but there is a glimmer of
> hope that it just might.

I wish you luck :)

The URL listed above leads to a Windows-Only-Thing, right?

Or did I miss any thing for NIXs ?

Thorsten aka ThH

Post a reply to this message

Am 27.02.2016 um 08:17 schrieb ThH:
> Am 27.02.2016 um 07:59 schrieb clipka:
>
>> Can someone please test this version:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>>
>>
>> I have no idea whether it will fix anything, but there is a glimmer of
>> hope that it just might.
>
> I wish you luck :)
>
> The URL listed above leads to a Windows-Only-Thing, right?
>
> Or did I miss any thing for NIXs ?
>
> Thorsten aka ThH

Shame on me...

NIXs meant Linux.

No to self:
No postings before first mug of tea!

Post a reply to this message

Am 27.02.2016 um 08:23 schrieb ThH:
> No to self:
> No postings before first mug of tea!

Darn me...

Meant:

Note to self

Post a reply to this message

Am 27.02.2016 um 08:17 schrieb ThH:
> Am 27.02.2016 um 07:59 schrieb clipka:
> 
>> Can someone please test this version:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>>
>>
>> I have no idea whether it will fix anything, but there is a glimmer of
>> hope that it just might.
> 
> I wish you luck :)
> 
> The URL listed above leads to a Windows-Only-Thing, right?

Nope; while the page the URL takes you to /does/ link to three pre-built
Windows binaries, it also leads to two source file packages, which
contain the entire source code for /all/ versions, including the Unix stuff.

Post a reply to this message

Am 27.02.2016 um 09:15 schrieb clipka:

> Nope; while the page the URL takes you to /does/ link to three pre-built
> Windows binaries, it also leads to two source file packages, which
> contain the entire source code for /all/ versions, including the Unix stuff.

I stand corrected.

Downloading (while having my 3rd mug of tea)

Will report back :)

Post a reply to this message

Am 27.02.2016 um 09:31 schrieb ThH:

> Downloading (while having my 3rd mug of tea)
>
> Will report back :)

Hmmm...

Output attached.

Post a reply to this message

Attachments:
Download 'optics.png' (222 KB)

Preview of image 'optics.png'

Am 27.02.2016 um 10:19 schrieb ThH:
> Am 27.02.2016 um 09:31 schrieb ThH:
> 
>> Downloading (while having my 3rd mug of tea)
>>
>> Will report back :)
> 
> Hmmm...
> 
> Output attached.

Doesn't seem to make much of a difference, does it?

Looks like I need more help from you folks to figure out where exactly
the problem is rooted.

Post a reply to this message

Am 27.02.2016 um 10:57 schrieb clipka:

> Doesn't seem to make much of a difference, does it?

I second that ;)

> Looks like I need more help from you folks to figure out where exactly
> the problem is rooted.

Was the optics_mod.pov or optics_mod_2.pov provided above of any help?

Sure.. The original scene is destroyed.

My hope is/was the simplified version might give you an idea, you find a 
solution, which - by lucky chance - solves all photon/media related 
problems.

--
Thorsten aka ThH
No... I've never did any coding using C, C++, ...

Post a reply to this message

Am 27.02.2016 um 11:16 schrieb ThH:

> Was the optics_mod.pov or optics_mod_2.pov provided above of any help?
> 
> Sure.. The original scene is destroyed.
> 
> My hope is/was the simplified version might give you an idea, you find a
> solution, which - by lucky chance - solves all photon/media related
> problems.

Unfortunately not. I need you to toy around more to give me that one
breakthrough idea.

It's really frustrating that there is not the slightest glitch to be
seen with the Windows version.

Post a reply to this message

Am 27.02.2016 um 12:00 schrieb clipka:

> Unfortunately not. I need you to toy around more to give me that one
> breakthrough idea.

Understood.

> It's really frustrating that there is not the slightest glitch to be
> seen with the Windows version.

Lucky windows-user so to say ;)

Post a reply to this message

Am 27.02.2016 um 12:05 schrieb ThH:

> Am 27.02.2016 um 12:00 schrieb clipka:
>
>> Unfortunately not. I need you to toy around more to give me that one
>> breakthrough idea.
>
> Understood.
>
>> It's really frustrating that there is not the slightest glitch to be
>> seen with the Windows version.
>
> Lucky windows-user so to say ;)

3 different pics by changing 1 line of the original optics.pov...

Does this raise any interest or additional frustrations?

Yes... The pics are brighter. I used assumed_gamma .5.

Post a reply to this message

Attachments:
Download 'optics_sandbox_r_01.png' (200 KB) Download 'optics_sandbox_r_10.png' (187 KB) Download 'optics_sandbox_r_20.png' (157 KB)

Preview of image 'optics_sandbox_r_01.png'

Preview of image 'optics_sandbox_r_10.png'

Preview of image 'optics_sandbox_r_20.png'

Am 27.02.2016 um 13:54 schrieb ThH:
> Am 27.02.2016 um 12:05 schrieb ThH:
> 
>> Am 27.02.2016 um 12:00 schrieb clipka:
...
>>> It's really frustrating that there is not the slightest glitch to be
>>> seen with the Windows version.
>>
>> Lucky windows-user so to say ;)

No, actually not. I know that there /is/ a bug lurking below the
surface, and unless I know exactly what causes it, I cannot rule out
that it may also strike at Windows users under /some/ circumstances.

> 3 different pics by changing 1 line of the original optics.pov...
> 
> Does this raise any interest or additional frustrations?

I dunno... care to tell me /what/ you changed? ;)

> Yes... The pics are brighter. I used assumed_gamma .5.

Why on earth would you do that?
(Then again, I did ask you to experiment, so...)

Post a reply to this message

Am 27.02.2016 um 13:54 schrieb ThH:

> 3 different pics by changing 1 line of the original optics.pov...

What really intrigues me, and what I would like to ask you to try and
investigate, is why only /some/ of the light rays are affected; why
don't /all/ the blue and /all/ the red rays end up blazingly white?

There must be /some/ reason for this, and I reckon that it might lead to
a useful clue.

Post a reply to this message

Am 27.02.2016 um 16:21 schrieb clipka:

> I dunno... care to tell me /what/ you changed? ;)

This is what gave the 3 different results:

#declare MirrorTex1 =
texture {
     pigment {color White}
     //finish {ambient 0 diffuse 0 reflection  1/1}
     //finish {ambient 0 diffuse 0 reflection 1/10}
     finish {ambient 0 diffuse 0 reflection 1/20}
}

Original reflection - Image ...01...
10% - Image ...10...
5 % - Image ...20...

Keeping my fingers crossed!

>> Yes... The pics are brighter. I used assumed_gamma .5.
>
> Why on earth would you do that?
> (Then again, I did ask you to experiment, so...)

Maybe my CRT-Monitor is too dark. That why I did it ;)

Post a reply to this message

On 02/27/2016 10:37 AM, clipka wrote:
> Am 27.02.2016 um 13:54 schrieb ThH:
>
>> 3 different pics by changing 1 line of the original optics.pov...
>
> What really intrigues me, and what I would like to ask you to try and
> investigate, is why only /some/ of the light rays are affected; why
> don't /all/ the blue and /all/ the red rays end up blazingly white?
>
> There must be /some/ reason for this, and I reckon that it might lead to
> a useful clue.
>
Christoph,

I think it has something to do with the light type.

// <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
// light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
//     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
//     photons {refraction on reflection on}
// }
// <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
    light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
        photons {refraction on reflection on}
    }

Perhaps someone else can verify ?

I extended the blocking wall for the point light, but not strictly needed.

Bill P.

Post a reply to this message

Am 27.02.2016 um 17:17 schrieb William F Pokorny:

> Christoph,
>
> I think it has something to do with the light type.
>
> // <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
> // light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
> //     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
> //     photons {refraction on reflection on}
> // }
> // <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
>     light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>         photons {refraction on reflection on}
>     }
>
> Perhaps someone else can verify ?

Tried it...

Yes. The resulting image differs, bit still not right.

I've attached my rendering.

Post a reply to this message

Attachments:
Download 'optics_sandbox.png' (50 KB)

Preview of image 'optics_sandbox.png'

Am 27.02.2016 um 16:37 schrieb clipka:
> Am 27.02.2016 um 13:54 schrieb ThH:
>
>> 3 different pics by changing 1 line of the original optics.pov...
>
> What really intrigues me, and what I would like to ask you to try and
> investigate, is why only /some/ of the light rays are affected; why
> don't /all/ the blue and /all/ the red rays end up blazingly white?
>
> There must be /some/ reason for this, and I reckon that it might lead to
> a useful clue.

A new series...

How about these images?

Post a reply to this message

Attachments:
Download 'optics_sandbox_f_00.png' (26 KB) Download 'optics_sandbox_f_01.png' (26 KB) Download 'optics_sandbox_f_02.png' (35 KB) Download 'optics_sandbox_f_02_03.png' (42 KB) Download 'optics_sandbox_f_03.png' (34 KB) Download 'optics_sandbox_f_04.png' (27 KB) Download 'optics_sandbox_f_05.png' (26 KB) Download 'optics_sandbox_f_06.png' (26 KB)

Preview of image 'optics_sandbox_f_00.png'

Preview of image 'optics_sandbox_f_01.png'

Preview of image 'optics_sandbox_f_02.png'

Preview of image 'optics_sandbox_f_02_03.png'

Preview of image 'optics_sandbox_f_03.png'

Preview of image 'optics_sandbox_f_04.png'

Preview of image 'optics_sandbox_f_05.png'

Preview of image 'optics_sandbox_f_06.png'

Am 27.02.2016 um 18:08 schrieb ThH:
> Am 27.02.2016 um 17:17 schrieb William F Pokorny:
> 
>> Christoph,
>>
>> I think it has something to do with the light type.
>>
>> // <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
>> // light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>> //     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
>> //     photons {refraction on reflection on}
>> // }
>> // <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
>>     light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>>         photons {refraction on reflection on}
>>     }
>>
>> Perhaps someone else can verify ?
> 
> Tried it...
> 
> Yes. The resulting image differs, bit still not right.
> 
> I've attached my rendering.

Looks ok to me (except that the "original" light should cover the entire
height of the image's left side, but I'm pretty sure that's an entirely
different problem). Where the light streams past the block at the upper
edge of the image it's totally normal that we get bright white light.

I think it might well be worth toying around with the spotlight some more.

Post a reply to this message

Am 27.02.2016 um 18:27 schrieb clipka:

> I think it might well be worth toying around with the spotlight some more.

Did so. Images attached.

Anything looking promising?

Post a reply to this message

Attachments:
Download 'optics_sandbox_fo_1.png' (43 KB) Download 'optics_sandbox_fo_2.png' (51 KB) Download 'optics_sandbox_fo_3.png' (27 KB)

Preview of image 'optics_sandbox_fo_1.png'

Preview of image 'optics_sandbox_fo_2.png'

Preview of image 'optics_sandbox_fo_3.png'

Am 27.02.2016 um 19:07 schrieb ThH:
> Am 27.02.2016 um 18:27 schrieb clipka:
> 
>> I think it might well be worth toying around with the spotlight some
>> more.
> 
> Did so. Images attached.
> 
> Anything looking promising?

VERY promising. Whatever you did there, it has some definitive effect on
the symptoms.

Details please.

Post a reply to this message

Am 27.02.2016 um 19:10 schrieb clipka:

> VERY promising. Whatever you did there, it has some definitive effect on
> the symptoms.
>
> Details please.

Falloff:

     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 1
     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 2
     spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 3

(Holds breath)

Post a reply to this message

Am 27.02.2016 um 19:22 schrieb ThH:
> Am 27.02.2016 um 19:10 schrieb clipka:
> 
>> VERY promising. Whatever you did there, it has some definitive effect on
>> the symptoms.
>>
>> Details please.
> 
> Falloff:
> 
>     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 1
>     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 2
>     spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 3
> 
> (Holds breath)

While this does show a clear correlation between the falloff parameter
and the area where the error occurs, the geometry of that area is still
a puzzle to me: For instance, why is the area farther out on the red leg
than on the blue leg? And why is the area much farther out than the falloff?

Can you do me a favor and toy around with the colours, the geometry of
how the optical elements are arranged, and how this relates to the falloff?

(BTW, when you post results, please include the details right away. Me
having to ask for them unnecessarily bogs down the whole process.)

Post a reply to this message

Ha!

Does this look familiar to anyone?

It turns out that the root problem _is_ also present in the Windows
version -- but it's masked by a peculiarity of the run-time library's
handling of special floating-point values.

What happens is that _somewhere_ in the photon computations one of the
mathematical operations results in "not a sensible value", which carries
over into the computed colour values. How such values behave in the
conversion to the RGBE format depends on the run-time library
implementation: On Windows it results in zero values, thus "healing" the
problem. On Linux however, it results in rather high values instead.

Post a reply to this message

Attachments:
Download 'optics.png' (145 KB)

Preview of image 'optics.png'

Am 28.02.2016 um 06:02 schrieb clipka:

> While this does show a clear correlation between the falloff parameter
> and the area where the error occurs, the geometry of that area is still
> a puzzle to me: For instance, why is the area farther out on the red leg
> than on the blue leg? And why is the area much farther out than the falloff?
>
> Can you do me a favor and toy around with the colours, the geometry of
> how the optical elements are arranged, and how this relates to the falloff?

Me likes toying around with this great piece of software. I will :)
>
> (BTW, when you post results, please include the details right away. Me
> having to ask for them unnecessarily bogs down the whole process.)

Ok. Understood.

Post a reply to this message

Am 28.02.2016 um 07:59 schrieb clipka:
> Ha!
>
> Does this look familiar to anyone?

In deed. It does ;)

> It turns out that the root problem _is_ also present in the Windows
> version -- but it's masked by a peculiarity of the run-time library's
> handling of special floating-point values.
>
> What happens is that _somewhere_ in the photon computations one of the
> mathematical operations results in "not a sensible value", which carries
> over into the computed colour values. How such values behave in the
> conversion to the RGBE format depends on the run-time library
> implementation: On Windows it results in zero values, thus "healing" the
> problem. On Linux however, it results in rather high values instead.

Frustration turned into and idea. Fine :)

Will there be a new master in the near future? Please don't get me 
wrong... Only asking because I would like to "play around" with the 
latest master.

Post a reply to this message

Am 28.02.2016 um 08:07 schrieb ThH:

> Will there be a new master in the near future? Please don't get me
> wrong... Only asking because I would like to "play around" with the
> latest master.

Depends on your definition of "near future" ;)

I guess I'll be able to figure out and fix the root cause today or
tomorrow. Until then, I see no point in releasing some interim workaround.

Post a reply to this message

Am 28.02.2016 um 08:55 schrieb clipka
:
> Am 28.02.2016 um 08:07 schrieb ThH:
>
>> Will there be a new master in the near future? Please don't get me
>> wrong... Only asking because I would like to "play around" with the
>> latest master.
>
> Depends on your definition of "near future" ;)
>
> I guess I'll be able to figure out and fix the root cause today or
> tomorrow. Until then, I see no point in releasing some interim workaround.

Thanks for this info :)

I'm toddling off... Got some toying around to do ;)

Post a reply to this message

Am 28.02.2016 um 09:14 schrieb ThH:

> I'm toddling off... Got some toying around to do ;)

Talking of high values...

What will happen using lower values?

To approaches concerning the media-box:

box {<-7,-0.1,-3>, < 6, 1, 4> hollow
     texture {pigment {color rgbf 1}}
     interior {
         media {
             //scattering {1, color White extinction 0} // 01 (Original 
optics.pov)
             //scattering {1, color White-<0,0,1> extinction 0} // 02
             scattering {1, color White extinction 0+12} // 3 (Docs: 
..artistic freedom...) // 03
             //emission color White*0.2
             method 3
             intervals 1 samples 4
         }
     }
     photons {target}
}

Of any use ?

Post a reply to this message

Attachments:
Download 'optics_sandbox_hv_01.png' (43 KB) Download 'optics_sandbox_hv_02.png' (38 KB) Download 'optics_sandbox_hv_03.png' (34 KB)

Preview of image 'optics_sandbox_hv_01.png'

Preview of image 'optics_sandbox_hv_02.png'

Preview of image 'optics_sandbox_hv_03.png'

Am 28.02.2016 um 09:37 schrieb ThH:

> To approaches concerning the media-box:

Two... Heaven!

Moving the mirrors +<1,0,0>...

// 00 - Original optics.pov
object {Mirror(<-3, 0, 0>, 3*45, 2, 1, BlueMirrorTex)}
object {Mirror(<-3, 0, 3>,-45, 2, 1, MirrorTex1)}

// 01 - Variation 1
object {Mirror(<-3, 0, 0>+<1,0,0>, 3*45, 2, 1, BlueMirrorTex)}
object {Mirror(<-3, 0, 3>+<1,0,0>,-45, 2, 1, MirrorTex1)}

// 00 - Original optics.pov
//object {Mirror(<-1, 0, 0>, 180+22.5, 2, 1, RedMirrorTex)}
//object {Mirror(<-3, 0,-2>, 22.5, 2, 1, MirrorTex1)}

// 02 - Variation 2
object {Mirror(<-1, 0, 0>+<1,0,0>, 180+22.5, 2, 1, RedMirrorTex)}
object {Mirror(<-3, 0,-2>+<1,0,0>, 22.5, 2, 1, MirrorTex1)}

// 03 - Variation 3
// 01 + 02

Post a reply to this message

Attachments:
Download 'optics_sandbox_g_00.png' (43 KB) Download 'optics_sandbox_g_01.png' (39 KB) Download 'optics_sandbox_g_02.png' (37 KB) Download 'optics_sandbox_g_03.png' (40 KB)

Preview of image 'optics_sandbox_g_00.png'

Preview of image 'optics_sandbox_g_01.png'

Preview of image 'optics_sandbox_g_02.png'

Preview of image 'optics_sandbox_g_03.png'

Am 28.02.2016 um 10:45 schrieb ThH:
> Am 28.02.2016 um 09:37 schrieb ThH:
> 
>> To approaches concerning the media-box:
> 
> Two... Heaven!

No need for any more toying.

You might want to test the newest version though :D

Post a reply to this message

Am 28.02.2016 um 11:04 schrieb clipka:

> No need for any more toying.
>
> You might want to test the newest version though :D

Great. Will.

Couldn't resist...

Changing the falloff:

Relevant code from the second light source

     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 00 
(Original optics.pov)
     //spotlight radius 0.3 falloff 0.35*20 point_at < 0, 0.5, 0> // 01
     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 02
     //spotlight radius 0.3 falloff 0.35*5 point_at < 0, 0.5, 0> // 03
     //spotlight radius 0.3 falloff 0.35*.25 point_at < 0, 0.5, 0> // 04
     //spotlight radius 0.3 falloff 0.35/.25 point_at < 0, 0.5, 0> // 05
     //spotlight radius 0.3 falloff 0.35/5 point_at < 0, 0.5, 0> // 06
     //spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 07
     spotlight radius 0.3 falloff 0.35/20 point_at < 0, 0.5, 0> // 08

Now let's build the new version :))

Post a reply to this message

Attachments:
Download 'optics_sandbox_fo2_00.png' (43 KB) Download 'optics_sandbox_fo2_01.png' (51 KB) Download 'optics_sandbox_fo2_02.png' (51 KB) Download 'optics_sandbox_fo2_03.png' (53 KB) Download 'optics_sandbox_fo2_04.png' (32 KB) Download 'optics_sandbox_fo2_05.png' (47 KB) Download 'optics_sandbox_fo2_06.png' (31 KB) Download 'optics_sandbox_fo2_07.png' (27 KB) Download 'optics_sandbox_fo2_08.png' (26 KB)

Preview of image 'optics_sandbox_fo2_00.png'

Preview of image 'optics_sandbox_fo2_01.png'

Preview of image 'optics_sandbox_fo2_02.png'

Preview of image 'optics_sandbox_fo2_03.png'

Preview of image 'optics_sandbox_fo2_04.png'

Preview of image 'optics_sandbox_fo2_05.png'

Preview of image 'optics_sandbox_fo2_06.png'

Preview of image 'optics_sandbox_fo2_07.png'

Preview of image 'optics_sandbox_fo2_08.png'

Le 28/02/2016 11:12, ThH a écrit :
> Am 28.02.2016 um 11:04 schrieb clipka:
> 
>> No need for any more toying.
>>
>> You might want to test the newest version though :D

> Now let's build the new version :))


POV-Ray 3.7.1-alpha.8499454.unofficial
Gitid: 5b5e312523b226e5be1409f270325b66b5c92bf9

no more problem in optics.pov and gnu compiler

Now I have to report it to my branch too.

Post a reply to this message

Am 28.02.2016 um 11:12 schrieb ThH:
> Am 28.02.2016 um 11:04 schrieb clipka:
>
>> No need for any more toying.
>>
>> You might want to test the newest version though :D

Case closed. You made it :)))

Thank you and all those involved in the process...

High 5, 10, 15, 20, ... !

Post a reply to this message

Attachments:
Download 'optics.png' (233 KB)

Preview of image 'optics.png'

On 02/28/2016 05:04 AM, clipka wrote:
>
> You might want to test the newest version though :D
>

Cool! You got the bug - thanks.

I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray 
3.7.1-alpha.8499454. I like the new, less intense, result over the old, 
but is this 3.7.0 to 3.7.1 change expected ?

Bill P.

Post a reply to this message

Am 28.02.2016 um 12:24 schrieb William F Pokorny:

> I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray
> 3.7.1-alpha.8499454. I like the new, less intense, result over the old,
> but is this 3.7.0 to 3.7.1 change expected ?
>
> Bill P.

You're right 8)

Just did a 1200x900 render using the versions mentioned above...

Haven't noticed the "new look" while toying hunting for the error.

Expected change... Interesting Question :)

Post a reply to this message

Am 28.02.2016 um 13:40 schrieb ThH:

> Expected change... Interesting Question :)

abyss.pov 3.7.0 vs 3.7.1... Same result: 2 "different" Images.

Expected change ?

Post a reply to this message

Am 28.02.2016 um 12:24 schrieb William F Pokorny:
> On 02/28/2016 05:04 AM, clipka wrote:
>>
>> You might want to test the newest version though :D
>>
> 
> Cool! You got the bug - thanks.
> 
> I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray
> 3.7.1-alpha.8499454. I like the new, less intense, result over the old,
> but is this 3.7.0 to 3.7.1 change expected ?

There are various factors that could contribute.

For one thing, the old encoding/decoding scheme for the photon colour
data was flawed, leading to a systematic error in the photon brightness,
which has been fixed in 3.7.1. However, that doesn't seem to fit the
bill, as this error should have manifested as a slight bias towards
black, so that in 3.7.1 we should see an _increase_ rather than a
decrease in brightness.

Another thing is that the error in the photons code I've just fixed has
been around for quite a while, and _did_ already exist in 3.7.0; it just
didn't surface until the change in the encoding/decoding scheme
translated it into artifacts Unix systems. It _may_ be that the old
encoding/decoding scheme did already translate the error into artifacts,
and that they just were a lot less bright.

My current favourite theory, however, is that the change in brightness
is related to a change in the media computation. There, too, a
long-standing flaw led to another systematic error, which has also been
fixed in 3.7.1.

Note that this can explain the differences in abyss.pov, too.

Post a reply to this message

Am 28.02.2016 um 15:29 schrieb clipka:

> My current favourite theory, however, is that the change in brightness
> is related to a change in the media computation. There, too, a
> long-standing flaw led to another systematic error, which has also been
> fixed in 3.7.1.

Currently trying some more scenes.

I had the impression the effect might be linked to media.

> Note that this can explain the differences in abyss.pov, too.

I see.

Slightly off-topic...

Does anyone know of a software (Linux) to compare 2 images?

Post a reply to this message

ThH <no.spam@address> wrote:


> Slightly off-topic...
>
> Does anyone know of a software (Linux) to compare 2 images?

OpenCV library
Paint.NET
Photoshop
ImageMagick
convert img1 img2 -fx "(((255*u)&(255*(1-v)))|((255*(1-u))&(255*v)))/255"
img_out


Hope that gets you some sort of useful start...

Post a reply to this message

Am 28.02.2016 um 15:53 schrieb Bald Eagle:

>> Does anyone know of a software (Linux) to compare 2 images?
>
> OpenCV library
> Paint.NET
> Photoshop
> ImageMagick
> convert img1 img2 -fx "(((255*u)&(255*(1-v)))|((255*(1-u))&(255*v)))/255"
> img_out
>
>
> Hope that gets you some sort of useful start...

I'm sure it will. Thank you Bald Eagle :)

Will try convert in a few minutes ;)

Post a reply to this message

Am 28.02.2016 um 15:43 schrieb ThH:

> Does anyone know of a software (Linux) to compare 2 images?

If you are willing to invest a few bucks, I can highly recommend Scooter
Software's BeyondCompare 4.

Post a reply to this message

Am 28.02.2016 um 16:09 schrieb clipka:

> If you are willing to invest a few bucks, I can highly recommend Scooter
> Software's BeyondCompare 4.

Thank you clipka.

Think ixquick will find it for me ;)

"few bucks"... Depends on how much is few. Will find out :)

Post a reply to this message

Am 28.02.2016 um 16:09 schrieb ThH:

> Will try convert in a few minutes ;)

convert is the way for me. Thanks you for the example above Bald Eagle :))

Free and for the terminal ;)

As said before: Always learning something new :)

Post a reply to this message

Am 28.02.2016 um 16:21 schrieb ThH:

> Think ixquick will find it for me ;)
>
> "few bucks"... Depends on how much is few. Will find out :)

Ok. This is the _big_ solution ;)

Will be remember it, if I need a _big_ solution.

Thanks again clipka :)

Post a reply to this message