optics.pov from scenes/advanced...

The appended files had been rendered using povray V3.7.0 and Version 
3.7.1-alpha.8492620.unofficial.

Could someone please check this?

Thorsten aka ThH

Post a reply to this message

Attachments:
Download 'optics_3.7.0.png' (138 KB) Download 'optics_3.7.1.png' (137 KB)

Preview of image 'optics_3.7.0.png'

Preview of image 'optics_3.7.1.png'

Am 24.02.2016 um 14:24 schrieb ThH:

> Could someone please check this?
>
> Thorsten aka ThH

Ooops... System is AMD64 with Debian. Excuse.

Post a reply to this message

Am 24.02.2016 um 14:46 schrieb ThH:
> Am 24.02.2016 um 14:24 schrieb ThH:
> 
>> Could someone please check this?
>>
>> Thorsten aka ThH
> 
> Ooops... System is AMD64 with Debian. Excuse.

Can't reproduce the issue with the Windows version.
Are you sure you have a clean build?

Post a reply to this message

Am 24.02.2016 um 14:53 schrieb clipka:

> Can't reproduce the issue with the Windows version.
> Are you sure you have a clean build?

The source is from github and hasn't been modified.

Povray has been build using:

cd ~/Downloads/povray-master/unix/
./prebuild.sh
cd ..
./configure --prefix=/home/thh/POV_Master COMPILED_BY="ThH 
<no.spam@address>" LIBS="-lboost_system -lboost_thread"
make check install

No extra configure options.

 From my point of view I'd say it's clean.

I could provide the output of the build process...

Post a reply to this message

El 24/02/16 a las 14:24, ThH escribió:
> optics.pov from scenes/advanced...
>
> The appended files had been rendered using povray V3.7.0 and Version
> 3.7.1-alpha.8492620.unofficial.
>
> Could someone please check this?
>

   Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3 LTS.

--
jaime

Post a reply to this message

Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:

>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3
> LTS.
>
> --
> jaime

Thanks for checking and confirming Jaime :)

So it's not just me ;)

Post a reply to this message

Am 24.02.2016 um 16:02 schrieb ThH:
> Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:
> 
>>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3
>> LTS.
>>
>> -- 
>> jaime
> 
> Thanks for checking and confirming Jaime :)
> 
> So it's not just me ;)

Okay, here's the deal: I can't reproduce it, so my only chance to
identify the root cause is to have a close look at the code, but for
that to make any sense I need a clear picture of exactly where to look.
To this end, I need you (that's "you" as in "y'all") to:

- figure out the simplest possible scene that exhibits the problem;

- identify exactly which commit (in the master branch) broke the scene; and

- do plenty of systematic toying around with the scene to figure out the
exact circumstances under which the error shows. (For instance, why
isn't the green beam affected? Is it because it is not reflected? Then
why aren't the red and blue beams affected right after the first
reflection? Does max_trace_level have anything to do with it? Why does
only the bottom of the red sub-beams seem affected? Why the top and
center of the blue sub-beams? etc. -- Be inquisitive and creative!)

Post a reply to this message

Am 24.02.2016 um 16:51 schrieb clipka:

  -- Be inquisitive and creative!)

I'm in :)

Post a reply to this message

Le 24/02/2016 16:51, clipka a écrit :
> Am 24.02.2016 um 16:02 schrieb ThH:
>> Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:
>>
>>>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04
.3
>>> LTS.
>>>
>>> -- 
>>> jaime
>>
>> Thanks for checking and confirming Jaime :)
>>
>> So it's not just me ;)
> 
> Okay, here's the deal: I can't reproduce it, so my only chance to
> identify the root cause is to have a close look at the code, but for
> that to make any sense I need a clear picture of exactly where to look.

> To this end, I need you (that's "you" as in "y'all") to:
> 
> - figure out the simplest possible scene that exhibits the problem;
> 
> - identify exactly which commit (in the master branch) broke the scene;
 and
> 
> - do plenty of systematic toying around with the scene to figure out th
e
> exact circumstances under which the error shows. (For instance, why
> isn't the green beam affected? Is it because it is not reflected? Then
> why aren't the red and blue beams affected right after the first
> reflection? Does max_trace_level have anything to do with it? Why does
> only the bottom of the red sub-beams seem affected? Why the top and
> center of the blue sub-beams? etc. -- Be inquisitive and creative!)
> 

The problem might not be only in the code, I tested several heads and
compilers

/=================+=====+==
=====+=======+============
====\
| head \ compiler | gnu | clang | intel | gnu with debug |
+-----------------+-----+-------+-------+----------------+
| 3.7.0 stable    |  ok |  ok   |  ok   |  ok            |
+-----------------+-----+-------+-------+----------------+
| 3.7.1 master    | BUG |  ok   |  ok   |  BUG           |
+-----------------+-----+-------+-------+----------------+
| my master (hg)  | BUG |  ok   |  ok   |  BUG           |
+-----------------+-----+-------+-------+----------------+
| hgpovray        | ok  |  ok   |  ok   |  ok            |
\-----------------+-----+-------+-------+----------------/

notice, the intensity of green on stable branch seems higher (might be
known... gamma ?)

the difference between hgpovray and my master is:
* hgpovray is late on the refactoring of the code
* I have all my additions in hgpovray

the difference between my master and official master:
* I'm about a year late on synchronisation with refactoring

last pull from master to my master was April-June 2015, so the "bug" was
already there then.

The start/fork of hgpovray is 8 june 2014, so code before that date was
still fine.

The OP's picture was in white bug, mine is yellow.
(Ubuntu 64 bits 15.10)

Just one year of patches to check... it might be tied to the size of a
structure, and a particularity of Gnu compiler (gcc/g++ 5.2.1 20151010)
sensible to that... or a change of initialisation...

Post a reply to this message

Attachments:
Download 'gmpovray.png' (239 KB)

Preview of image 'gmpovray.png'

Am 24.02.2016 um 17:04 schrieb ThH:
> Am 24.02.2016 um 16:51 schrieb clipka:
>
>   -- Be inquisitive and creative!)
>
> I'm in :)

Find attached optics_mod.pov.
Hope it's a good starter on the the way for a minimal scene to produce 
the error.

In addition I've attached 2 pics rendered on my machine. Again 3.7.0 vs 
3.7.1.

Now for some more investigation... ;)

Post a reply to this message

Attachments:
Download 'optics_mod.pov.txt' (2 KB) Download 'optics_mod_3.7.0.png' (84 KB) Download 'optics_mod_3.7.1.png' (91 KB)

Preview of image 'optics_mod_3.7.0.png'

Preview of image 'optics_mod_3.7.1.png'

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