I've been using Sams "Odd Tiles Object' include (get it in 
p.b.scene-files) forever and just noticed a problem. The 1st image shows 
the problem ... 2nd image is how is supposed to look.

Builds from the latest uber beta, /and/ povray master branches on github 
have the problem, povray 3.7 stable (github) and perforce repository are 
ok fine.

Post a reply to this message

Attachments:
Download 'otoc1.png' (305 KB) Download 'otoc2.png' (315 KB)

Preview of image 'otoc1.png'

Preview of image 'otoc2.png'

Am 12.08.2014 17:06, schrieb James Holsenback:
> I've been using Sams "Odd Tiles Object' include (get it in
> p.b.scene-files) forever and just noticed a problem. The 1st image shows
> the problem ... 2nd image is how is supposed to look.

Is that the "OTOc.inc" 3rd version?

> Builds from the latest uber beta, /and/ povray master branches on github
> have the problem, povray 3.7 stable (github) and perforce repository are
> ok fine.

The Sam's test scene (OTOTest.pov) renders fine here with the latest 
POV-Ray and UberPOV stuff (Windows versions).

Post a reply to this message

Attachments:
Download 'ototest.png' (300 KB)

Preview of image 'ototest.png'

On 08/12/2014 12:40 PM, clipka wrote:
> Am 12.08.2014 17:06, schrieb James Holsenback:
>> I've been using Sams "Odd Tiles Object' include (get it in
>> p.b.scene-files) forever and just noticed a problem. The 1st image shows
>> the problem ... 2nd image is how is supposed to look.
>
> Is that the "OTOc.inc" 3rd version?

that's what the file header says ...

>
>> Builds from the latest uber beta, /and/ povray master branches on github
>> have the problem, povray 3.7 stable (github) and perforce repository are
>> ok fine.
>
> The Sam's test scene (OTOTest.pov) renders fine here with the latest
> POV-Ray and UberPOV stuff (Windows versions).

here's what I'm doing:

#declare Floor =
union {
	object {
		OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture scale 1 } )
		}
	box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish 
{diffuse 0.6 specular 0.15 roughness 1e-5} }
	rotate x*90
	rotate y*0
	}

kind of funny that it works with some versions (perforce/git 3.7 stable) 
but not other git repos ... 32 vs 64 bit? compiler?? configure changes???

Post a reply to this message

On 08/12/2014 01:01 PM, James Holsenback wrote:
> On 08/12/2014 12:40 PM, clipka wrote:
>> Am 12.08.2014 17:06, schrieb James Holsenback:
>>> I've been using Sams "Odd Tiles Object' include (get it in
>>> p.b.scene-files) forever and just noticed a problem. The 1st image shows
>>> the problem ... 2nd image is how is supposed to look.
>>
>> Is that the "OTOc.inc" 3rd version?
>
> that's what the file header says ...
>
>>
>>> Builds from the latest uber beta, /and/ povray master branches on github
>>> have the problem, povray 3.7 stable (github) and perforce repository are
>>> ok fine.
>>
>> The Sam's test scene (OTOTest.pov) renders fine here with the latest
>> POV-Ray and UberPOV stuff (Windows versions).
>
> here's what I'm doing:
>
> #declare Floor =
> union {
>      object {
>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
> scale 1 } )
>          }
>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>      rotate x*90
>      rotate y*0
>      }
>
> kind of funny that it works with some versions (perforce/git 3.7 stable)
> but not other git repos ... 32 vs 64 bit? compiler?? configure changes???
>

found OTOTest.pov file laying around in some obscure corner ... here's 
results

Post a reply to this message

Attachments:
Download 'ototest.png' (1072 KB)

Preview of image 'ototest.png'

Am 12.08.2014 19:01, schrieb James Holsenback:

> here's what I'm doing:
>
> #declare Floor =
> union {
>      object {
>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
> scale 1 } )
>          }
>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>      rotate x*90
>      rotate y*0
>      }
>
> kind of funny that it works with some versions (perforce/git 3.7 stable)
> but not other git repos ... 32 vs 64 bit? compiler?? configure changes???

With 3.7.1-alpha.7681813 compiled straight from the GitHub code, the 
above scene snippet (with standard OTO_Object) gives me this:

Post a reply to this message

Attachments:
Download 'ototest2.png' (13 KB)

Preview of image 'ototest2.png'

On 08/12/2014 01:24 PM, clipka wrote:
> Am 12.08.2014 19:01, schrieb James Holsenback:
>
>> here's what I'm doing:
>>
>> #declare Floor =
>> union {
>>      object {
>>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>> scale 1 } )
>>          }
>>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>>      rotate x*90
>>      rotate y*0
>>      }
>>
>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>> but not other git repos ... 32 vs 64 bit? compiler?? configure changes???
>
> With 3.7.1-alpha.7681813 compiled straight from the GitHub code, the
> above scene snippet (with standard OTO_Object) gives me this:
>

I stayed out of my local git repos as I've made some changes ... Instead 
downloaded the zip package made available from povray github with the 
master filter selected, it has this hash 
ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem. With 
3.7-stable filter set, this hash 
39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine

Post a reply to this message

Am 12.08.2014 19:08, schrieb James Holsenback:

> found OTOTest.pov file laying around in some obscure corner ... here's
> results

Well, what can I say, other than "I can't reproduce it"?

Unless you can trim down the thing to an extremely minimalistic scene 
(say, one or two primitives with one or two textures) that is rendered 
differently by the builds you're using, or can nail down exactly what 
GitHub commit broke it, I might be able to do some guessing; but until 
then, unfortunately it looks like I need you to do more experimenting.

Post a reply to this message

On 08/12/2014 01:34 PM, James Holsenback wrote:
> On 08/12/2014 01:24 PM, clipka wrote:
>> Am 12.08.2014 19:01, schrieb James Holsenback:
>>
>>> here's what I'm doing:
>>>
>>> #declare Floor =
>>> union {
>>>      object {
>>>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>>> scale 1 } )
>>>          }
>>>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>>>      rotate x*90
>>>      rotate y*0
>>>      }
>>>
>>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>>> but not other git repos ... 32 vs 64 bit? compiler?? configure
>>> changes???
>>
>> With 3.7.1-alpha.7681813 compiled straight from the GitHub code, the
>> above scene snippet (with standard OTO_Object) gives me this:
>>
>
> I stayed out of my local git repos as I've made some changes ... Instead
> downloaded the zip package made available from povray github with the
> master filter selected, it has this hash
> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem. With
> 3.7-stable filter set, this hash
> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine
>
>
POV-Ray 3.7.1-alpha.7681813.unofficial

Post a reply to this message

Am 12.08.2014 19:34, schrieb James Holsenback:

> I stayed out of my local git repos as I've made some changes ... Instead
> downloaded the zip package made available from povray github with the
> master filter selected, it has this hash
> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem.

That's 3.7.1-alpha.7681813, so same version as I used.

> With 3.7-stable filter set, this hash
> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine

That's the genuine 3.7.0 release proper, aka "3.7.0 stable".

Post a reply to this message

On 08/12/2014 01:41 PM, clipka wrote:
> Am 12.08.2014 19:08, schrieb James Holsenback:
>
>> found OTOTest.pov file laying around in some obscure corner ... here's
>> results
>
> Well, what can I say, other than "I can't reproduce it"?
>
> Unless you can trim down the thing to an extremely minimalistic scene
> (say, one or two primitives with one or two textures) that is rendered
> differently by the builds you're using, or can nail down exactly what
> GitHub commit broke it, I might be able to do some guessing; but until
> then, unfortunately it looks like I need you to do more experimenting.
>
well it's after 3.7-stable for sure ... OTOc.inc sources math.inc dunno 
if that could be a clue.

Post a reply to this message

Am 12.08.2014 19:53, schrieb James Holsenback:
> On 08/12/2014 01:41 PM, clipka wrote:
>> Am 12.08.2014 19:08, schrieb James Holsenback:
>>
>>> found OTOTest.pov file laying around in some obscure corner ... here's
>>> results
>>
>> Well, what can I say, other than "I can't reproduce it"?
>>
>> Unless you can trim down the thing to an extremely minimalistic scene
>> (say, one or two primitives with one or two textures) that is rendered
>> differently by the builds you're using, or can nail down exactly what
>> GitHub commit broke it, I might be able to do some guessing; but until
>> then, unfortunately it looks like I need you to do more experimenting.
>>
> well it's after 3.7-stable for sure ...

Thanks for the help, you just narrowed it down to a meagre 120-130 
commits :-)


> OTOc.inc sources math.inc dunno
> if that could be a clue.

I hadn't thought of include files, and it would seem a tempting 
explanation, as I'm not regularly updating my installed set of those; 
but a quick check reveals that I'm already using the newest; which is 
not too surprising, giving that only three changes have been made within 
the include directory since 3.7-stable so far, and none of them seems 
anywhere close to being a plausible candidate. (And no, math.inc hasn't 
been changed at all.)

Post a reply to this message

On 08/12/2014 02:42 PM, clipka wrote:
> Am 12.08.2014 19:53, schrieb James Holsenback:
>> On 08/12/2014 01:41 PM, clipka wrote:
>>> Am 12.08.2014 19:08, schrieb James Holsenback:
>>>
>>>> found OTOTest.pov file laying around in some obscure corner ... here's
>>>> results
>>>
>>> Well, what can I say, other than "I can't reproduce it"?
>>>
>>> Unless you can trim down the thing to an extremely minimalistic scene
>>> (say, one or two primitives with one or two textures) that is rendered
>>> differently by the builds you're using, or can nail down exactly what
>>> GitHub commit broke it, I might be able to do some guessing; but until
>>> then, unfortunately it looks like I need you to do more experimenting.
>>>
>> well it's after 3.7-stable for sure ...
>
> Thanks for the help, you just narrowed it down to a meagre 120-130
> commits :-)

narrowed a bit further ... this hash works fine: 
9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!

Post a reply to this message

On 08/12/2014 02:55 PM, James Holsenback wrote:
> On 08/12/2014 02:42 PM, clipka wrote:
>> Am 12.08.2014 19:53, schrieb James Holsenback:
>>> On 08/12/2014 01:41 PM, clipka wrote:
>>>> Am 12.08.2014 19:08, schrieb James Holsenback:
>>>>
>>>>> found OTOTest.pov file laying around in some obscure corner ... here's
>>>>> results
>>>>
>>>> Well, what can I say, other than "I can't reproduce it"?
>>>>
>>>> Unless you can trim down the thing to an extremely minimalistic scene
>>>> (say, one or two primitives with one or two textures) that is rendered
>>>> differently by the builds you're using, or can nail down exactly what
>>>> GitHub commit broke it, I might be able to do some guessing; but until
>>>> then, unfortunately it looks like I need you to do more experimenting.
>>>>
>>> well it's after 3.7-stable for sure ...
>>
>> Thanks for the help, you just narrowed it down to a meagre 120-130
>> commits :-)
>
> narrowed a bit further ... this hash works fine:
> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>
>
ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I 
think that's considerable less territory to cover.

Post a reply to this message

Le 12/08/2014 19:48, clipka a écrit :
> Am 12.08.2014 19:34, schrieb James Holsenback:
> 
>> I stayed out of my local git repos as I've made some changes ... Instead
>> downloaded the zip package made available from povray github with the
>> master filter selected, it has this hash
>> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem.
> 
> That's 3.7.1-alpha.7681813, so same version as I used.
> 
>> With 3.7-stable filter set, this hash
>> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine
> 
> That's the genuine 3.7.0 release proper, aka "3.7.0 stable".
> 
Yet another compiler issue ?

Is there a full-scene available for download and test ?

-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

On 08/13/2014 03:16 AM, Le_Forgeron wrote:
> Le 12/08/2014 19:48, clipka a écrit :
>> Am 12.08.2014 19:34, schrieb James Holsenback:
>>
>>> I stayed out of my local git repos as I've made some changes ... Instead
>>> downloaded the zip package made available from povray github with the
>>> master filter selected, it has this hash
>>> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem.
>>
>> That's 3.7.1-alpha.7681813, so same version as I used.
>>
>>> With 3.7-stable filter set, this hash
>>> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine
>>
>> That's the genuine 3.7.0 release proper, aka "3.7.0 stable".
>>
> Yet another compiler issue ?

I'm having my suspicions that is what's going on ...

>
> Is there a full-scene available for download and test ?
>

Yep ... the OTOTest.pov file that comes with the OTOc.inc package (over 
in p.b.scene-files

Post a reply to this message

On 08/12/2014 03:53 PM, James Holsenback wrote:
> On 08/12/2014 02:55 PM, James Holsenback wrote:
>> On 08/12/2014 02:42 PM, clipka wrote:
>>> Am 12.08.2014 19:53, schrieb James Holsenback:
>>>> On 08/12/2014 01:41 PM, clipka wrote:
>>>>> Am 12.08.2014 19:08, schrieb James Holsenback:
>>>>>
>>>>>> found OTOTest.pov file laying around in some obscure corner ...
>>>>>> here's
>>>>>> results
>>>>>
>>>>> Well, what can I say, other than "I can't reproduce it"?
>>>>>
>>>>> Unless you can trim down the thing to an extremely minimalistic scene
>>>>> (say, one or two primitives with one or two textures) that is rendered
>>>>> differently by the builds you're using, or can nail down exactly what
>>>>> GitHub commit broke it, I might be able to do some guessing; but until
>>>>> then, unfortunately it looks like I need you to do more experimenting.
>>>>>
>>>> well it's after 3.7-stable for sure ...
>>>
>>> Thanks for the help, you just narrowed it down to a meagre 120-130
>>> commits :-)
>>
>> narrowed a bit further ... this hash works fine:
>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>
>>
> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
> think that's considerable less territory to cover.

this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working 
commit (compiles and runs OTOTest.pov properly)

broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even 
compile ./base/safemath.h is belching errors all over the place

In file included from base/image/image.cpp:57:0:
./base/safemath.h: In function ‘T pov_base::SafeUnsignedProduct(T1, T2, 
T3, T4)’:
./base/safemath.h:51:2: error: ‘numeric_limits’ was not declared in this 
scope
./base/safemath.h:51:2: note: suggested alternative:
/usr/include/c++/4.6/limits:304:12: note:   ‘std::numeric_limits’
./base/safemath.h:51:2: error: expected primary-expression before ‘>’ token
./base/safemath.h:51:2: error: ‘::is_integer’ has not been declared
./base/safemath.h:52:2: error: expected primary-expression before ‘>’ token
./base/safemath.h:52:2: error: ‘::is_integer’ has not been declared
./base/safemath.h:53:2: error: expected primary-expression before ‘>’ token
./base/safemath.h:53:2: error: ‘::is_integer’ has not been declared
./base/safemath.h:54:2: error: expected primary-expression before ‘>’ token
./base/safemath.h:54:2: error: ‘::is_integer’ has not been declared
./base/safemath.h:55:2: error: expected primary-expression before ‘>’ token
./base/safemath.h:55:2: error: ‘::is_integer’ has not been declared
./base/safemath.h:61:26: error: expected primary-expression before ‘>’ token
./base/safemath.h:61:33: error: no matching function for call to ‘max()’
./base/safemath.h:61:33: note: candidates are:
/usr/include/c++/4.6/bits/stl_algobase.h:254:5: note: template<class 
_Tp, class _Compare> const _Tp& std::max(const _Tp&, const _Tp&, _Compare)
/usr/include/c++/4.6/bits/stl_algobase.h:210:5: note: template<class 
_Tp> const _Tp& std::max(const _Tp&, const _Tp&)
make[2]: *** [base/image/image.o] Error 1

Post a reply to this message

Am 13.08.2014 12:11, schrieb James Holsenback:

>>> narrowed a bit further ... this hash works fine:
>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>
>>>
>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>> think that's considerable less territory to cover.
>
> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
> commit (compiles and runs OTOTest.pov properly)
>
> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
> compile ./base/safemath.h is belching errors all over the place

Ah, yes, that one... that's part of GitHub issue #29. It'll need 
replacing of "numeric_limits" with "std::numeric_limits" (and then 
probably some more fixes).

Post a reply to this message

On 13/08/2014 10:26, James Holsenback wrote:
> On 08/13/2014 03:16 AM, Le_Forgeron wrote:
>> Le 12/08/2014 19:48, clipka a écrit :
>>> Am 12.08.2014 19:34, schrieb James Holsenback:
>>>
>>>> I stayed out of my local git repos as I've made some changes ...
>>>> Instead
>>>> downloaded the zip package made available from povray github with the
>>>> master filter selected, it has this hash
>>>> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem.
>>>
>>> That's 3.7.1-alpha.7681813, so same version as I used.
>>>
>>>> With 3.7-stable filter set, this hash
>>>> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine
>>>
>>> That's the genuine 3.7.0 release proper, aka "3.7.0 stable".
>>>
>> Yet another compiler issue ?
> 
> I'm having my suspicions that is what's going on ...
> 

Identify your compiler ?
mine is gcc 4.8.2 (ubuntu) and testing with
ad6d545729bbd92800fc2d65fe74dcac86408c27 (head of master), it works ok here.
(from OTOC... )

(I did not reinstall the include files, so changes in such files might
not be reflected)


>>
>> Is there a full-scene available for download and test ?
>>
> 
> Yep ... the OTOTest.pov file that comes with the OTOc.inc package (over
> in p.b.scene-files
> 
Thanks.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

On 08/13/2014 04:07 PM, Le_Forgeron wrote:
> On 13/08/2014 10:26, James Holsenback wrote:
>> On 08/13/2014 03:16 AM, Le_Forgeron wrote:
>>> Le 12/08/2014 19:48, clipka a écrit :
>>>> Am 12.08.2014 19:34, schrieb James Holsenback:
>>>>
>>>>> I stayed out of my local git repos as I've made some changes ...
>>>>> Instead
>>>>> downloaded the zip package made available from povray github with the
>>>>> master filter selected, it has this hash
>>>>> ad6d545729bbd92800fc2d65fe74dcac86408c27 and has the problem.
>>>>
>>>> That's 3.7.1-alpha.7681813, so same version as I used.
>>>>
>>>>> With 3.7-stable filter set, this hash
>>>>> 39ce8a24e50651904010dda15872d63be15d7c37 tis ok fine
>>>>
>>>> That's the genuine 3.7.0 release proper, aka "3.7.0 stable".
>>>>
>>> Yet another compiler issue ?
>>
>> I'm having my suspicions that is what's going on ...
>>
>
> Identify your compiler ?

gcc (SUSE Linux) 4.6.2

> mine is gcc 4.8.2 (ubuntu) and testing with
> ad6d545729bbd92800fc2d65fe74dcac86408c27 (head of master), it works ok here.
> (from OTOC... )
>
> (I did not reinstall the include files, so changes in such files might
> not be reflected)
>
>
>>>
>>> Is there a full-scene available for download and test ?
>>>
>>
>> Yep ... the OTOTest.pov file that comes with the OTOc.inc package (over
>> in p.b.scene-files
>>
> Thanks.
>

Post a reply to this message

On 08/13/2014 07:28 AM, clipka wrote:
> Am 13.08.2014 12:11, schrieb James Holsenback:
>
>>>> narrowed a bit further ... this hash works fine:
>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>
>>>>
>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>> think that's considerable less territory to cover.
>>
>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>> commit (compiles and runs OTOTest.pov properly)
>>
>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>> compile ./base/safemath.h is belching errors all over the place
>
> Ah, yes, that one... that's part of GitHub issue #29. It'll need
> replacing of "numeric_limits" with "std::numeric_limits" (and then
> probably some more fixes).
>
>
went to #af80da48a650b51039d23318a73b583493d81200 (last of #29 issue) 
and now it builds clean, but the wall from the OTO test scene is incomplete

Post a reply to this message

On 08/13/2014 07:28 AM, clipka wrote:
> Am 13.08.2014 12:11, schrieb James Holsenback:
>
>>>> narrowed a bit further ... this hash works fine:
>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>
>>>>
>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>> think that's considerable less territory to cover.
>>
>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>> commit (compiles and runs OTOTest.pov properly)
>>
>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>> compile ./base/safemath.h is belching errors all over the place
>
> Ah, yes, that one... that's part of GitHub issue #29. It'll need
> replacing of "numeric_limits" with "std::numeric_limits" (and then
> probably some more fixes).

have you been able to (or are you even going to) look into why the 
implementation (re-factoring???) of this construct isn't compatible with 
my compiler (that's what appears to be happening) since you can't 
confirm on your end.

it /really/ appears that this (OTOTest file) got broken @ 
cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits 
just cleaned up the implementation so i could at least compile.

Post a reply to this message

On 08/16/2014 06:49 AM, James Holsenback wrote:
> On 08/13/2014 07:28 AM, clipka wrote:
>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>
>>>>> narrowed a bit further ... this hash works fine:
>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>
>>>>>
>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>> think that's considerable less territory to cover.
>>>
>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>> commit (compiles and runs OTOTest.pov properly)
>>>
>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>> compile ./base/safemath.h is belching errors all over the place
>>
>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>> probably some more fixes).
>
> have you been able to (or are you even going to) look into why the
> implementation (re-factoring???) of this construct isn't compatible with
> my compiler (that's what appears to be happening) since you can't
> confirm on your end.
>
> it /really/ appears that this (OTOTest file) got broken @
> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
> just cleaned up the implementation so i could at least compile.
>

following up on the notion that it's compiler/configure related, I did a 
comparison of configure output the buildbot server and my system!

This 1st output is from the buildbot server ...

gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1:

Just a few entries of interest here /not/ all of them ... compare them 
with below output!

Language constructs and functions
---------------------------------
checking size of int... 4
checking size of long int... 8
checking size of size_t... 8
checking size of float... 4

Floating Point Features
-----------------------
checking limits usability... yes
checking limits presence... yes
checking for limits... yes
checking whether NaNs are supported... yes
checking cmath usability... yes
checking cmath presence... yes
checking for cmath... yes
checking whether NaNs can be identified using std::isnan()... no
checking whether NaNs can be identified using global isnan()... no
checking whether NaNs can be identified by comparison to themselves... no
checking whether infinite values are supported... yes
checking for cmath... (cached) yes
checking whether infinities can be identified using std::isinf()... no
checking whether infinities can be identified using global isinf()... no
checking whether infinities can be identified by comparison to the 
maximum value... yes

------

This output is from my system ...

gcc (SUSE Linux) 4.6.2:

Compare to above buildbot output ...

Language constructs and functions
---------------------------------
checking size of int... 4
checking size of long int... 4
checking size of size_t... 4
checking size of float... 4

Did /not/ even have "Floating Point Features" section on my system!!!

The plot thickens? mkl?

Post a reply to this message

Am 16.08.2014 12:49, schrieb James Holsenback:
> On 08/13/2014 07:28 AM, clipka wrote:
>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>
>>>>> narrowed a bit further ... this hash works fine:
>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>
>>>>>
>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>> think that's considerable less territory to cover.
>>>
>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>> commit (compiles and runs OTOTest.pov properly)
>>>
>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>> compile ./base/safemath.h is belching errors all over the place
>>
>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>> probably some more fixes).
>
> have you been able to (or are you even going to) look into why the
> implementation (re-factoring???) of this construct isn't compatible with
> my compiler (that's what appears to be happening) since you can't
> confirm on your end.

The "numeric_limits" in the global namespace (i.e. without "std::") 
isn't compatible with your compiler because it's not ISO C++. MS Visual 
C++ does support it, but other compilers (or, more precisely, the 
respective <limits> header file) may not.

Prior to that change, there was a statement "using namespace std;" which 
effectively says, "everything in namespace std should also be available 
in the current namespace", or, in other words, "std:: can be omitted 
everywhere". It had to be dropped because with some compilers it caused 
name conflicts between implementations of the shared_ptr class from 
different sources (boost, tr1 and C++11).

> it /really/ appears that this (OTOTest file) got broken @
> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
> just cleaned up the implementation so i could at least compile.

I wouldn't expect the issue #29 commits to do anything else. They're 
just there to use less ambiguous language constructs to satisfy some 
compilers that are less forgiving than MS Visual C++.

If I understand you correctly, you're saying that with issue #29 fixes 
in place commit 7502593 works while cf1c3fb doesn't. Is that right?

Post a reply to this message

Am 16.08.2014 14:00, schrieb James Holsenback:

> following up on the notion that it's compiler/configure related, I did a
> comparison of configure output the buildbot server and my system!

Does the buildbot-generated binary render the scene ok?

> This 1st output is from the buildbot server ...
>
> gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1:
>
> Just a few entries of interest here /not/ all of them ... compare them
> with below output!
>
> Language constructs and functions
> ---------------------------------
> checking size of int... 4
> checking size of long int... 8
> checking size of size_t... 8
> checking size of float... 4

That's typical for a 64-bit machine.

> Floating Point Features
> -----------------------
> checking limits usability... yes
> checking limits presence... yes
> checking for limits... yes
> checking whether NaNs are supported... yes
> checking cmath usability... yes
> checking cmath presence... yes
> checking for cmath... yes
> checking whether NaNs can be identified using std::isnan()... no
> checking whether NaNs can be identified using global isnan()... no
> checking whether NaNs can be identified by comparison to themselves... no
> checking whether infinite values are supported... yes
> checking for cmath... (cached) yes
> checking whether infinities can be identified using std::isinf()... no
> checking whether infinities can be identified using global isinf()... no
> checking whether infinities can be identified by comparison to the
> maximum value... yes

That's typical for g++ with floating-point optimizations enabled.

> ------
>
> This output is from my system ...
>
> gcc (SUSE Linux) 4.6.2:
>
> Compare to above buildbot output ...
>
> Language constructs and functions
> ---------------------------------
> checking size of int... 4
> checking size of long int... 4
> checking size of size_t... 4
> checking size of float... 4

That's typical for a 32-bit machine.

> Did /not/ even have "Floating Point Features" section on my system!!!

That's perfectly normal for any version prior to commit f1699ea.

> The plot thickens? mkl?

No plot-thickening yet.

Post a reply to this message

On 08/16/2014 10:17 AM, clipka wrote:
> Am 16.08.2014 12:49, schrieb James Holsenback:
>> On 08/13/2014 07:28 AM, clipka wrote:
>>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>>
>>>>>> narrowed a bit further ... this hash works fine:
>>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>>
>>>>>>
>>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>>> think that's considerable less territory to cover.
>>>>
>>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>>> commit (compiles and runs OTOTest.pov properly)
>>>>
>>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>>> compile ./base/safemath.h is belching errors all over the place
>>>
>>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>>> probably some more fixes).
>>
>> have you been able to (or are you even going to) look into why the
>> implementation (re-factoring???) of this construct isn't compatible with
>> my compiler (that's what appears to be happening) since you can't
>> confirm on your end.
>
> The "numeric_limits" in the global namespace (i.e. without "std::")
> isn't compatible with your compiler because it's not ISO C++. MS Visual
> C++ does support it, but other compilers (or, more precisely, the
> respective <limits> header file) may not.
>
> Prior to that change, there was a statement "using namespace std;" which
> effectively says, "everything in namespace std should also be available
> in the current namespace", or, in other words, "std:: can be omitted
> everywhere". It had to be dropped because with some compilers it caused
> name conflicts between implementations of the shared_ptr class from
> different sources (boost, tr1 and C++11).
>
>> it /really/ appears that this (OTOTest file) got broken @
>> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
>> just cleaned up the implementation so i could at least compile.
>
> I wouldn't expect the issue #29 commits to do anything else. They're
> just there to use less ambiguous language constructs to satisfy some
> compilers that are less forgiving than MS Visual C++.
>
> If I understand you correctly, you're saying that with issue #29 fixes
> in place commit 7502593 works while cf1c3fb doesn't. Is that right?

ac564f7 was the last time I was able to compile and run OTOTest file 
correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last 
issue #29) commit and it compiled fine but OTOTest file problem showed 
up again

Post a reply to this message

Am 17.08.2014 10:47, schrieb James Holsenback:

>> If I understand you correctly, you're saying that with issue #29 fixes
>> in place commit 7502593 works while cf1c3fb doesn't. Is that right?
>
> ac564f7 was the last time I was able to compile and run OTOTest file
> correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last
> issue #29) commit and it compiled fine but OTOTest file problem showed
> up again

Please note that the Git version history isn't linear: It has different 
branches that split and merge; and while ac564f7 is the last commit 
before cf1c3fb, it was done on a different branch, and so the immediate 
predecessor of cf1c3fb is the earlier commit 7502593. (Likewise, the 
later commit 914fff1 is a direct successor of ac564f7 but not of 
cf1c3fb, and is therefore likely to both compile and run OTOTest file.)

The following commits are still suspects for having broken OTOTest (in 
reverse chronological order):

     cf1c3fb
     7502593
     2a2d1a8
     2a41f04

7502593 is comparatively unlikely to be the culprit, as it just merges 
bugfix cc24c62, which was also merged into the other branch leading to 
ac564f7 and apparently didn't do any damage there.

2a2d1a8 is about as hot a candidate as cf1c3fb - probably even more so, 
as it is all about vectors and therefore relative position of items, 
while cf1c3fb is about blend maps (colour maps, pigment maps, normal 
maps etc.), which do not have any intrinsic relative positional 
component to them.

2a41f04 is a hot candidate for having caused GitHub issue #29, but 
shouldn't have brought about any functional changes, so I suspect it 
will run fine with the issue #29 fixes applied.

Post a reply to this message

Am 16.08.2014 16:24, schrieb clipka:
> Am 16.08.2014 14:00, schrieb James Holsenback:
>
>> following up on the notion that it's compiler/configure related, I did a
>> comparison of configure output the buildbot server and my system!
>
> Does the buildbot-generated binary render the scene ok?

Did you have time to test this by now?

Post a reply to this message

On 08/18/2014 08:20 AM, clipka wrote:
> Am 16.08.2014 16:24, schrieb clipka:
>> Am 16.08.2014 14:00, schrieb James Holsenback:
>>
>>> following up on the notion that it's compiler/configure related, I did a
>>> comparison of configure output the buildbot server and my system!
>>
>> Does the buildbot-generated binary render the scene ok?
>
> Did you have time to test this by now?
>

no I haven't ... didn't catch that previously. probably not today ... 
maybe tomorrow.

Post a reply to this message

On 08/18/2014 08:18 AM, clipka wrote:
> Am 17.08.2014 10:47, schrieb James Holsenback:
>
>>> If I understand you correctly, you're saying that with issue #29 fixes
>>> in place commit 7502593 works while cf1c3fb doesn't. Is that right?
>>
>> ac564f7 was the last time I was able to compile and run OTOTest file
>> correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last
>> issue #29) commit and it compiled fine but OTOTest file problem showed
>> up again
>
> Please note that the Git version history isn't linear: It has different
> branches that split and merge; and while ac564f7 is the last commit
> before cf1c3fb, it was done on a different branch, and so the immediate
> predecessor of cf1c3fb is the earlier commit 7502593. (Likewise, the
> later commit 914fff1 is a direct successor of ac564f7 but not of
> cf1c3fb, and is therefore likely to both compile and run OTOTest file.)
>
> The following commits are still suspects for having broken OTOTest (in
> reverse chronological order):
>
>      cf1c3fb
>      7502593
>      2a2d1a8
>      2a41f04
>
> 7502593 is comparatively unlikely to be the culprit, as it just merges
> bugfix cc24c62, which was also merged into the other branch leading to
> ac564f7 and apparently didn't do any damage there.
>
> 2a2d1a8 is about as hot a candidate as cf1c3fb - probably even more so,
> as it is all about vectors and therefore relative position of items,
> while cf1c3fb is about blend maps (colour maps, pigment maps, normal
> maps etc.), which do not have any intrinsic relative positional
> component to them.
>
> 2a41f04 is a hot candidate for having caused GitHub issue #29, but
> shouldn't have brought about any functional changes, so I suspect it
> will run fine with the issue #29 fixes applied.
>

OK ... this goes to some of my confusion. I'd suspected as much. Thanks 
for the sanity check!

When I downloaded source(s) I used the "clone" url, so I was pulling a 
snapshot of the entire branch (not just individual changes) at that 
commit, then doing separate builds for each. Give me some time to 
further narrow it down.

Appreciate your indulgence.

Post a reply to this message

Am 12.08.2014 19:08, schrieb James Holsenback:

>>> The Sam's test scene (OTOTest.pov) renders fine here with the latest
>>> POV-Ray and UberPOV stuff (Windows versions).
>>
>> here's what I'm doing:
>>
>> #declare Floor =
>> union {
>>      object {
>>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>> scale 1 } )
>>          }
>>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>>      rotate x*90
>>      rotate y*0
>>      }
>>
>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>> but not other git repos ... 32 vs 64 bit? compiler?? configure changes???
>
> found OTOTest.pov file laying around in some obscure corner ... here's
> results

I've got some good news: While I'm still unable to reproduce the error, 
I /am/ now able to exactly reproduce the output you're seeing (see 
attached image), by changing the OTO_FMask function

     #local OTO_FMask = function{ pattern{ pigment_pattern{
         checker 0, 1 warp{planar} } } }

to something that never returns 1; so it would seem that the error 
scrambles one of the statements in this function definition.

Can you please dig further in this direction to figure out exactly what 
part of this is broken? (I guess this will lead us much faster to the 
root cause than knowing exactly which commit introduced it.)

Post a reply to this message

Attachments:
Download 'ototest.png' (275 KB)

Preview of image 'ototest.png'

On 08/18/2014 10:13 AM, clipka wrote:
> Am 12.08.2014 19:08, schrieb James Holsenback:
>
>>>> The Sam's test scene (OTOTest.pov) renders fine here with the latest
>>>> POV-Ray and UberPOV stuff (Windows versions).
>>>
>>> here's what I'm doing:
>>>
>>> #declare Floor =
>>> union {
>>>      object {
>>>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>>> scale 1 } )
>>>          }
>>>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>>>      rotate x*90
>>>      rotate y*0
>>>      }
>>>
>>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>>> but not other git repos ... 32 vs 64 bit? compiler?? configure
>>> changes???
>>
>> found OTOTest.pov file laying around in some obscure corner ... here's
>> results
>
> I've got some good news: While I'm still unable to reproduce the error,
> I /am/ now able to exactly reproduce the output you're seeing (see
> attached image), by changing the OTO_FMask function

yes that IS good news ...

>
>      #local OTO_FMask = function{ pattern{ pigment_pattern{
>          checker 0, 1 warp{planar} } } }
>
> to something that never returns 1; so it would seem that the error
> scrambles one of the statements in this function definition.
>
> Can you please dig further in this direction to figure out exactly what
> part of this is broken? (I guess this will lead us much faster to the
> root cause than knowing exactly which commit introduced it.)
>

OK

Post a reply to this message

On 08/18/2014 10:13 AM, clipka wrote:
> Am 12.08.2014 19:08, schrieb James Holsenback:
>
>>>> The Sam's test scene (OTOTest.pov) renders fine here with the latest
>>>> POV-Ray and UberPOV stuff (Windows versions).
>>>
>>> here's what I'm doing:
>>>
>>> #declare Floor =
>>> union {
>>>      object {
>>>          OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>>> scale 1 } )
>>>          }
>>>      box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>>>      rotate x*90
>>>      rotate y*0
>>>      }
>>>
>>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>>> but not other git repos ... 32 vs 64 bit? compiler?? configure
>>> changes???
>>
>> found OTOTest.pov file laying around in some obscure corner ... here's
>> results
>
> I've got some good news: While I'm still unable to reproduce the error,
> I /am/ now able to exactly reproduce the output you're seeing (see
> attached image), by changing the OTO_FMask function
>
>      #local OTO_FMask = function{ pattern{ pigment_pattern{
>          checker 0, 1 warp{planar} } } }
>
> to something that never returns 1; so it would seem that the error
> scrambles one of the statements in this function definition.
>
> Can you please dig further in this direction to figure out exactly what
> part of this is broken? (I guess this will lead us much faster to the
> root cause than knowing exactly which commit introduced it.)
>

Well had some time after all ... I played with the OTO_FMask function, 
but hey there's not much to change right? I started looking at the 
numbers being passed to OTO_Get_Mask, on line 133 of the attached 
include I added a debug. Everything looked legitimate, so I dropped down 
a couple of lines and added debugs for the corner finding test. Those 
sets of vectors looked like legitimate formed vectors as well, but the 
wall is incomplete. Didn't notice that notice that the vectors were ALL 
falling into the 1st test until I changed condition to false on line 
136. Now the vectors pass through BOTH of the test and the wall in complete.

Post a reply to this message

Attachments:
Download 'us-ascii' (5 KB)

Am 18.08.2014 22:38, schrieb James Holsenback:

>> I've got some good news: While I'm still unable to reproduce the error,
>> I /am/ now able to exactly reproduce the output you're seeing (see
>> attached image), by changing the OTO_FMask function
>>
>>      #local OTO_FMask = function{ pattern{ pigment_pattern{
>>          checker 0, 1 warp{planar} } } }
>>
>> to something that never returns 1; so it would seem that the error
>> scrambles one of the statements in this function definition.
>>
>> Can you please dig further in this direction to figure out exactly what
>> part of this is broken? (I guess this will lead us much faster to the
>> root cause than knowing exactly which commit introduced it.)
>>
>
> Well had some time after all ... I played with the OTO_FMask function,
> but hey there's not much to change right? I started looking at the
> numbers being passed to OTO_Get_Mask, on line 133 of the attached
> include I added a debug. Everything looked legitimate, so I dropped down
> a couple of lines and added debugs for the corner finding test. Those
> sets of vectors looked like legitimate formed vectors as well, but the
> wall is incomplete. Didn't notice that notice that the vectors were ALL
> falling into the 1st test until I changed condition to false on line
> 136.

I... don't think I understand what you're saying.

Yes, the bug seems to be causing the corner finding test to always go to 
the same branch (but it's the else-branch according to my observation).

The mystery to be solved is, why is that?

I don't think the test itself ("#if(OTO_Get_Mask(Vec)=1)") is broken; 
that would surely affect too many other scenes. Likewise, I can't see 
how anything in the OTO_Get_Mask() macro could go wrong without messing 
up plenty of scenes as well.

My suspicion is therefore that the function OTO_FMask returns non-1 
values where it should return 1, and I was hoping you could do some 
toying around with that very function and compare its operation with (a) 
a working binary and (b) your broken version.

Something like:

  #macro OTO_Get_Mask(Cell)
   #local CX = Cell.x;
   #local CY = Cell.y;
   #local Result = OTO_FMask(CX,CY,0);
   #debug concat()
   Result
  #end

On a properly working binary and with the original OTOTest.pov scene, 
this should output:

--------------------------
<-8.00000,-5.00000,0.00000>: 1.00000000000000000000
<-7.00000,-5.00000,0.00000>: 0.00000000000000000000
<-6.00000,-5.00000,0.00000>: 1.00000000000000000000
<-5.00000,-5.00000,0.00000>: 0.00000000000000000000
<-4.00000,-5.00000,0.00000>: 1.00000000000000000000
<-3.00000,-5.00000,0.00000>: 0.00000000000000000000
<-2.00000,-5.00000,0.00000>: 1.00000000000000000000
<-1.00000,-5.00000,0.00000>: 0.00000000000000000000
<0.00000,-5.00000,0.00000>: 1.00000000000000000000
<1.00000,-5.00000,0.00000>: 0.00000000000000000000
<2.00000,-5.00000,0.00000>: 1.00000000000000000000
<3.00000,-5.00000,0.00000>: 0.00000000000000000000
<4.00000,-5.00000,0.00000>: 1.00000000000000000000
<5.00000,-5.00000,0.00000>: 0.00000000000000000000
<6.00000,-5.00000,0.00000>: 1.00000000000000000000
<7.00000,-5.00000,0.00000>: 0.00000000000000000000
<-8.00000,-4.00000,0.00000>: 0.00000000000000000000
<-7.00000,-4.00000,0.00000>: 1.00000000000000000000
<-6.00000,-4.00000,0.00000>: 0.00000000000000000000
<-5.00000,-4.00000,0.00000>: 1.00000000000000000000
<-4.00000,-4.00000,0.00000>: 0.00000000000000000000
<-3.00000,-4.00000,0.00000>: 1.00000000000000000000
<-2.00000,-4.00000,0.00000>: 0.00000000000000000000
<-1.00000,-4.00000,0.00000>: 1.00000000000000000000
<0.00000,-4.00000,0.00000>: 0.00000000000000000000
<1.00000,-4.00000,0.00000>: 1.00000000000000000000
<2.00000,-4.00000,0.00000>: 0.00000000000000000000
<3.00000,-4.00000,0.00000>: 1.00000000000000000000
<4.00000,-4.00000,0.00000>: 0.00000000000000000000
<5.00000,-4.00000,0.00000>: 1.00000000000000000000
<6.00000,-4.00000,0.00000>: 0.00000000000000000000
<7.00000,-4.00000,0.00000>: 1.00000000000000000000
...
--------------------------

If your broken build outputs the same, the problem must be in the macro 
or the comparison after all, but I doubt that, so I suspect that you'll 
get something different instead of "1.00000000000000000000".

In that case, a next step could be to use an all-1 pigment pattern 
instead and see what that does:

   #local OTO_FMask = function { pattern { pigment_pattern {
     colour 1.0 } } }

With an ok binary, this should give:

--------------------------
<-8.00000,-5.00000,0.00000>: 1.00000000000000000000
<-7.00000,-5.00000,0.00000>: 1.00000000000000000000
<-6.00000,-5.00000,0.00000>: 1.00000000000000000000
<-5.00000,-5.00000,0.00000>: 1.00000000000000000000
<-4.00000,-5.00000,0.00000>: 1.00000000000000000000
...
--------------------------

If your results differ there as well (which I suspect), we can rule out 
the warp{planar} and the checker pigment; using an entirely different 
pattern instead of pigment_pattern might also give some insight, such as:

   #local OTO_FMask = function{ pattern{ gradient x } }

which gives me:

--------------------------
<-8.00000,-5.00000,0.00000>: 0.00007000000000045858
<-7.00000,-5.00000,0.00000>: 0.00006000000000039307
<-6.00000,-5.00000,0.00000>: 0.00005000000000032756
<-5.00000,-5.00000,0.00000>: 0.00004000000000026205
<-4.00000,-5.00000,0.00000>: 0.00003000000000019654
<-3.00000,-5.00000,0.00000>: 0.00002000000000013102
<-2.00000,-5.00000,0.00000>: 0.00001000000000006551
<-1.00000,-5.00000,0.00000>: 0.00000000000000000000
<0.00000,-5.00000,0.00000>: 0.00000000000000000000
<1.00000,-5.00000,0.00000>: 1.00000000000000000000
<2.00000,-5.00000,0.00000>: 0.00000000000000000000
<3.00000,-5.00000,0.00000>: 0.00000000000000000000
<4.00000,-5.00000,0.00000>: 0.00000000000000000000
<5.00000,-5.00000,0.00000>: 0.00000000000000000000
<6.00000,-5.00000,0.00000>: 0.00000000000000000000
<7.00000,-5.00000,0.00000>: 0.00000000000000000000
...
--------------------------

Or use checker like this, which should give the same as the original 
from OTOc.inc albeit with a much simpler statement:

   #local OTO_FMask = function{ pattern{ checker } }


> Now the vectors pass through BOTH of the test and the wall in
> complete.

Pardon? You fixed it? How? The OTOc.inc you posted contains no changes 
except for the commented-out #debug lines and an additional blank at the 
end of the central test condition.

Post a reply to this message

On 08/18/2014 08:41 PM, clipka wrote:
> Am 18.08.2014 22:38, schrieb James Holsenback:
>
>>> I've got some good news: While I'm still unable to reproduce the error,
>>> I /am/ now able to exactly reproduce the output you're seeing (see
>>> attached image), by changing the OTO_FMask function
>>>
>>>      #local OTO_FMask = function{ pattern{ pigment_pattern{
>>>          checker 0, 1 warp{planar} } } }
>>>
>>> to something that never returns 1; so it would seem that the error
>>> scrambles one of the statements in this function definition.
>>>
>>> Can you please dig further in this direction to figure out exactly what
>>> part of this is broken? (I guess this will lead us much faster to the
>>> root cause than knowing exactly which commit introduced it.)
>>>
>>
>> Well had some time after all ... I played with the OTO_FMask function,
>> but hey there's not much to change right? I started looking at the
>> numbers being passed to OTO_Get_Mask, on line 133 of the attached
>> include I added a debug. Everything looked legitimate, so I dropped down
>> a couple of lines and added debugs for the corner finding test. Those
>> sets of vectors looked like legitimate formed vectors as well, but the
>> wall is incomplete. Didn't notice that notice that the vectors were ALL
>> falling into the 1st test until I changed condition to false on line
>> 136.
>
> I... don't think I understand what you're saying.
>
> Yes, the bug seems to be causing the corner finding test to always go to
> the same branch (but it's the else-branch according to my observation).
>
> The mystery to be solved is, why is that?
>
> I don't think the test itself ("#if(OTO_Get_Mask(Vec)=1)") is broken;
> that would surely affect too many other scenes. Likewise, I can't see
> how anything in the OTO_Get_Mask() macro could go wrong without messing
> up plenty of scenes as well.
>
> My suspicion is therefore that the function OTO_FMask returns non-1
> values where it should return 1, and I was hoping you could do some
> toying around with that very function and compare its operation with (a)
> a working binary and (b) your broken version.
>
> Something like:
>
>   #macro OTO_Get_Mask(Cell)
>    #local CX = Cell.x;
>    #local CY = Cell.y;
>    #local Result = OTO_FMask(CX,CY,0);
>    #debug concat()
>    Result
>   #end
>
> On a properly working binary and with the original OTOTest.pov scene,
> this should output:
>
> --------------------------
> <-8.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-7.00000,-5.00000,0.00000>: 0.00000000000000000000
> <-6.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-5.00000,-5.00000,0.00000>: 0.00000000000000000000
> <-4.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-3.00000,-5.00000,0.00000>: 0.00000000000000000000
> <-2.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-1.00000,-5.00000,0.00000>: 0.00000000000000000000
> <0.00000,-5.00000,0.00000>: 1.00000000000000000000
> <1.00000,-5.00000,0.00000>: 0.00000000000000000000
> <2.00000,-5.00000,0.00000>: 1.00000000000000000000
> <3.00000,-5.00000,0.00000>: 0.00000000000000000000
> <4.00000,-5.00000,0.00000>: 1.00000000000000000000
> <5.00000,-5.00000,0.00000>: 0.00000000000000000000
> <6.00000,-5.00000,0.00000>: 1.00000000000000000000
> <7.00000,-5.00000,0.00000>: 0.00000000000000000000
> <-8.00000,-4.00000,0.00000>: 0.00000000000000000000
> <-7.00000,-4.00000,0.00000>: 1.00000000000000000000
> <-6.00000,-4.00000,0.00000>: 0.00000000000000000000
> <-5.00000,-4.00000,0.00000>: 1.00000000000000000000
> <-4.00000,-4.00000,0.00000>: 0.00000000000000000000
> <-3.00000,-4.00000,0.00000>: 1.00000000000000000000
> <-2.00000,-4.00000,0.00000>: 0.00000000000000000000
> <-1.00000,-4.00000,0.00000>: 1.00000000000000000000
> <0.00000,-4.00000,0.00000>: 0.00000000000000000000
> <1.00000,-4.00000,0.00000>: 1.00000000000000000000
> <2.00000,-4.00000,0.00000>: 0.00000000000000000000
> <3.00000,-4.00000,0.00000>: 1.00000000000000000000
> <4.00000,-4.00000,0.00000>: 0.00000000000000000000
> <5.00000,-4.00000,0.00000>: 1.00000000000000000000
> <6.00000,-4.00000,0.00000>: 0.00000000000000000000
> <7.00000,-4.00000,0.00000>: 1.00000000000000000000
> ...
> --------------------------
>
> If your broken build outputs the same, the problem must be in the macro
> or the comparison after all, but I doubt that, so I suspect that you'll
> get something different instead of "1.00000000000000000000".
>
> In that case, a next step could be to use an all-1 pigment pattern
> instead and see what that does:
>
>    #local OTO_FMask = function { pattern { pigment_pattern {
>      colour 1.0 } } }
>
> With an ok binary, this should give:
>
> --------------------------
> <-8.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-7.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-6.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-5.00000,-5.00000,0.00000>: 1.00000000000000000000
> <-4.00000,-5.00000,0.00000>: 1.00000000000000000000
> ...
> --------------------------
>
> If your results differ there as well (which I suspect), we can rule out
> the warp{planar} and the checker pigment; using an entirely different
> pattern instead of pigment_pattern might also give some insight, such as:
>
>    #local OTO_FMask = function{ pattern{ gradient x } }
>
> which gives me:
>
> --------------------------
> <-8.00000,-5.00000,0.00000>: 0.00007000000000045858
> <-7.00000,-5.00000,0.00000>: 0.00006000000000039307
> <-6.00000,-5.00000,0.00000>: 0.00005000000000032756
> <-5.00000,-5.00000,0.00000>: 0.00004000000000026205
> <-4.00000,-5.00000,0.00000>: 0.00003000000000019654
> <-3.00000,-5.00000,0.00000>: 0.00002000000000013102
> <-2.00000,-5.00000,0.00000>: 0.00001000000000006551
> <-1.00000,-5.00000,0.00000>: 0.00000000000000000000
> <0.00000,-5.00000,0.00000>: 0.00000000000000000000
> <1.00000,-5.00000,0.00000>: 1.00000000000000000000
> <2.00000,-5.00000,0.00000>: 0.00000000000000000000
> <3.00000,-5.00000,0.00000>: 0.00000000000000000000
> <4.00000,-5.00000,0.00000>: 0.00000000000000000000
> <5.00000,-5.00000,0.00000>: 0.00000000000000000000
> <6.00000,-5.00000,0.00000>: 0.00000000000000000000
> <7.00000,-5.00000,0.00000>: 0.00000000000000000000
> ...
> --------------------------
>
> Or use checker like this, which should give the same as the original
> from OTOc.inc albeit with a much simpler statement:
>
>    #local OTO_FMask = function{ pattern{ checker } }
>
>
>> Now the vectors pass through BOTH of the test and the wall in
>> complete.
>
> Pardon? You fixed it? How? The OTOc.inc you posted contains no changes
> except for the commented-out #debug lines and an additional blank at the
> end of the central test condition.
>

Geez ... I never said I fixed it, and I'm getting rather bored with this 
back and forth. There's a problem ... fix it or don't.

Post a reply to this message

Am 19.08.2014 13:07, schrieb James Holsenback:

> Geez ... I never said I fixed it, and I'm getting rather bored with this
> back and forth. There's a problem ... fix it or don't.

I'd really like to fix it, but I need your help to diagnose the problem, 
because I really can't reproduce it here, and at present I know of 
nobody else who can.

Running the tests I described in my previous post should be a matter of 
just a few minutes, and might tell me more about the problem than all 
the back and forth so far.

So please help me a bit more with this.

... pretty please?

Post a reply to this message

On 08/19/2014 09:14 AM, clipka wrote:
> Am 19.08.2014 13:07, schrieb James Holsenback:
>
>> Geez ... I never said I fixed it, and I'm getting rather bored with this
>> back and forth. There's a problem ... fix it or don't.
>
> I'd really like to fix it, but I need your help to diagnose the problem,
> because I really can't reproduce it here, and at present I know of
> nobody else who can.
>
> Running the tests I described in my previous post should be a matter of
> just a few minutes, and might tell me more about the problem than all
> the back and forth so far.
>
> So please help me a bit more with this.
>
> ... pretty please?
>

I added some debug in OTO_Get_Mask like this:

#macro OTO_Get_Mask(Cell)
	#local CX = Cell.x;
   #local CY = Cell.y;
   #local Result = OTO_FMask(CX,CY,0);
   #debug concat ("OTO_Get_Mask <",vstr(3,Cell,",",2,4),"> 
Result:",str(Result,2,4),"\n")
   OTO_FMask(CX,CY,0)
  #end

and it produced the following output:

OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>

OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
else: <-6.96521,-4.79876,0.00000>, <-6.19790, -3.81513, 0.00000>

OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>

OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
else: <-4.73380,-4.96589,0.00000>, <-4.33468, -3.90749, 0.00000>

OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>

the 1st group shows a "Result" of 1 and it improperly falls into the 
else clause (yep got that backwards in previous post ... tired, dyslexia 
acting up) ... but notice in the 2nd group that even tho "Result" is 0 
(inside the OTO_Get_Mask macro) it /still/ falls into the else clause

I also used:
#local OTO_FMask = function{ pattern{ pigment_pattern{ color 1.0 } } }

with these results:

OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>

OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:1.0000
else: <-6.96521,-4.79876,0.00000>, <-6.19790, -3.81513, 0.00000>

OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>

OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:1.0000
else: <-4.73380,-4.96589,0.00000>, <-4.33468, -3.90749, 0.00000>

OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>

so it would seem that no matter what OTO_Get_Mask returns, it's /always/ 
falling into the else clause.

when I change the corner test to: #if(OTO_Get_Mask(Vec)=0)

things appear to go through the corner test properly (albeit reverse 
logic) and the image renders correctly without the gaps.

OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>

OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
if: <-6.81513,-4.96521,0.00000>, <-5.79876, -4.19790, 0.00000>

OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>

OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
if: <-4.90749,-4.73380,0.00000>, <-3.96589, -4.33468, 0.00000>

OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>

Post a reply to this message

Am 20.08.2014 14:29, schrieb James Holsenback:

> I added some debug in OTO_Get_Mask like this:
>
> #macro OTO_Get_Mask(Cell)
>      #local CX = Cell.x;
>    #local CY = Cell.y;
>    #local Result = OTO_FMask(CX,CY,0);
>    #debug concat ("OTO_Get_Mask <",vstr(3,Cell,",",2,4),">
> Result:",str(Result,2,4),"\n")
>    OTO_FMask(CX,CY,0)
>   #end
>
> and it produced the following output:
>
> OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
> else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>
>
> OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
> else: <-6.96521,-4.79876,0.00000>, <-6.19790, -3.81513, 0.00000>
>
> OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
> else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>
>
> OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
> else: <-4.73380,-4.96589,0.00000>, <-4.33468, -3.90749, 0.00000>
>
> OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
> else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>

Can you repeat this with a much higher precision for the result? 20 
digits should be enough. I wouldn't be surprised if this was some kind 
of precision issue in the function{pattern{pigment_pattern}} construct, 
as it would perfectly explain why it doesn't compare equal to 1.0. (I 
consider it unlikely that the comparison with 1.0 itself got broken 
somehow, and I think there /is/ a bit of code in the pigment_pattern 
that might be subject to rounding errors.)

Post a reply to this message

On 08/20/2014 08:29 AM, James Holsenback wrote:
> when I change the corner test to: #if(OTO_Get_Mask(Vec)=0)
>
> things appear to go through the corner test properly (albeit reverse
> logic) and the image renders correctly without the gaps.
>
> OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
> else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>
>
> OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
> if: <-6.81513,-4.96521,0.00000>, <-5.79876, -4.19790, 0.00000>
>
> OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
> else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>
>
> OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
> if: <-4.90749,-4.73380,0.00000>, <-3.96589, -4.33468, 0.00000>
>
> OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
> else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>

On a lark I also tried:
#if(OTO_Get_Mask(Vec))

and it works!!!
OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
if: <-7.69069,-5.08857,0.00000>, <-6.96521, -3.81513, 0.00000>

OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
else: <-6.96521,-4.79876,0.00000>, <-6.19790, -3.81513, 0.00000>

OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
if: <-6.19790,-4.79876,0.00000>, <-4.73380, -3.90749, 0.00000>

OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
else: <-4.73380,-4.96589,0.00000>, <-4.33468, -3.90749, 0.00000>

OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
if: <-4.33468,-4.96589,0.00000>, <-3.17163, -4.41528, 0.00000>

I'm confused now ... aren't

#if(OTO_Get_Mask(Vec)=1)

and

#if(OTO_Get_Mask(Vec))

functionally the same?

Post a reply to this message

On 08/20/2014 09:16 AM, clipka wrote:
> Am 20.08.2014 14:29, schrieb James Holsenback:
>
>> I added some debug in OTO_Get_Mask like this:
>>
>> #macro OTO_Get_Mask(Cell)
>>      #local CX = Cell.x;
>>    #local CY = Cell.y;
>>    #local Result = OTO_FMask(CX,CY,0);
>>    #debug concat ("OTO_Get_Mask <",vstr(3,Cell,",",2,4),">
>> Result:",str(Result,2,4),"\n")
>>    OTO_FMask(CX,CY,0)
>>   #end
>>
>> and it produced the following output:
>>
>> OTO_Get_Mask <-8.0000,-5.0000,0.0000> Result:1.0000
>> else: <-8.08857,-4.96521,0.00000>, <-6.81513, -3.69069, 0.00000>
>>
>> OTO_Get_Mask <-7.0000,-5.0000,0.0000> Result:0.0000
>> else: <-6.96521,-4.79876,0.00000>, <-6.19790, -3.81513, 0.00000>
>>
>> OTO_Get_Mask <-6.0000,-5.0000,0.0000> Result:1.0000
>> else: <-5.79876,-4.73380,0.00000>, <-4.90749, -4.19790, 0.00000>
>>
>> OTO_Get_Mask <-5.0000,-5.0000,0.0000> Result:0.0000
>> else: <-4.73380,-4.96589,0.00000>, <-4.33468, -3.90749, 0.00000>
>>
>> OTO_Get_Mask <-4.0000,-5.0000,0.0000> Result:1.0000
>> else: <-3.96589,-5.17163,0.00000>, <-3.41528, -4.33468, 0.00000>
>
> Can you repeat this with a much higher precision for the result? 20
> digits should be enough. I wouldn't be surprised if this was some kind
> of precision issue in the function{pattern{pigment_pattern}} construct,
> as it would perfectly explain why it doesn't compare equal to 1.0. (I
> consider it unlikely that the comparison with 1.0 itself got broken
> somehow, and I think there /is/ a bit of code in the pigment_pattern
> that might be subject to rounding errors.)
>
OTO_Get_Mask 
<-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
0000> Result:0.99999997764825820923

Hmmm ... OK I think this shows problem the above is output from inside 
the OTO_Get_Mask function ... I now see why reversing the logic (and my 
"on a lark" test) in corner test works

Post a reply to this message

Am 20.08.2014 15:16, schrieb James Holsenback:

> I'm confused now ... aren't
>
> #if(OTO_Get_Mask(Vec)=1)
>
> and
>
> #if(OTO_Get_Mask(Vec))
>
> functionally the same?

No,

   #if(OTO_Get_Mask(Vec))

and

   #if(OTO_Get_Mask(Vec) != 0)

are.

Post a reply to this message

Am 20.08.2014 15:26, schrieb James Holsenback:

> OTO_Get_Mask
> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
> 0000> Result:0.99999997764825820923
>
> Hmmm ... OK I think this shows problem the above is output from inside
> the OTO_Get_Mask function ... I now see why reversing the logic (and my
> "on a lark" test) in corner test works

Bingo!

Okay, you obviously have already figured a way around this problem by 
way of modifying OTOc.inc, and I think I now have enough information to 
go hunting for the root cause in the codebase.

I might come back to you for testing of some code modifications, if 
that's ok for you.

Post a reply to this message

On 08/20/2014 09:40 AM, clipka wrote:
> I might come back to you for testing of some code modifications, if
> that's ok for you.
ok fine

Post a reply to this message

Le 14-08-20 09:16, James Holsenback a écrit :

> I'm confused now ... aren't
>
> #if(OTO_Get_Mask(Vec)=1)
This is /true/ if and only if the result *is* 1 (one)

>
> and
>
> #if(OTO_Get_Mask(Vec))
This is /false/ if and only if the result *is* 0 (zero)

>
> functionally the same?

So, not at all *unless* the result can only be zero or one.
>
>
>

Alain

Post a reply to this message

On 08/20/2014 09:40 AM, clipka wrote:
> Am 20.08.2014 15:26, schrieb James Holsenback:
>
>> OTO_Get_Mask
>> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
>> 0000> Result:0.99999997764825820923
>>
>> Hmmm ... OK I think this shows problem the above is output from inside
>> the OTO_Get_Mask function ... I now see why reversing the logic (and my
>> "on a lark" test) in corner test works
>
> Bingo!
>
> Okay, you obviously have already figured a way around this problem by
> way of modifying OTOc.inc, and I think I now have enough information to
> go hunting for the root cause in the codebase.
>
> I might come back to you for testing of some code modifications, if
> that's ok for you.
>

curious if you've had any time to follow up

Post a reply to this message

Am 28.08.2014 19:41, schrieb James Holsenback:
> On 08/20/2014 09:40 AM, clipka wrote:
>> Am 20.08.2014 15:26, schrieb James Holsenback:
>>
>>> OTO_Get_Mask
>>> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
>>> 0000> Result:0.99999997764825820923
>>>
>>> Hmmm ... OK I think this shows problem the above is output from inside
>>> the OTO_Get_Mask function ... I now see why reversing the logic (and my
>>> "on a lark" test) in corner test works
>>
>> Bingo!
>>
>> Okay, you obviously have already figured a way around this problem by
>> way of modifying OTOc.inc, and I think I now have enough information to
>> go hunting for the root cause in the codebase.
>>
>> I might come back to you for testing of some code modifications, if
>> that's ok for you.
>>
>
> curious if you've had any time to follow up

Not yet, sorry.

Post a reply to this message

Am 28.08.2014 um 19:41 schrieb James Holsenback:
> On 08/20/2014 09:40 AM, clipka wrote:
>> Am 20.08.2014 15:26, schrieb James Holsenback:
>>
>>> OTO_Get_Mask
>>> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
>>> 0000> Result:0.99999997764825820923
>>>
>>> Hmmm ... OK I think this shows problem the above is output from inside
>>> the OTO_Get_Mask function ... I now see why reversing the logic (and my
>>> "on a lark" test) in corner test works
>>
>> Bingo!
>>
>> Okay, you obviously have already figured a way around this problem by
>> way of modifying OTOc.inc, and I think I now have enough information to
>> go hunting for the root cause in the codebase.
>>
>> I might come back to you for testing of some code modifications, if
>> that's ok for you.
>>
>
> curious if you've had any time to follow up

Now that I've returned from outer space, I have at last; can you please 
try the following patch:

At the beginning of source/base/colour.h, around line 95, replace the 
following lines:

const float kRedIntensity   = 0.297;
const float kGreenIntensity = 0.589;
const float kBlueIntensity  = 0.114;

with this:

const PreciseColourChannel kRedIntensity   = 0.297;
const PreciseColourChannel kGreenIntensity = 0.589;
const PreciseColourChannel kBlueIntensity  = 0.114;

I /think/ it should fix the issue. The culprit would then have been 
change 0ea2da4.

Post a reply to this message

On 01/06/2015 05:42 PM, clipka wrote:
> Am 28.08.2014 um 19:41 schrieb James Holsenback:
>> On 08/20/2014 09:40 AM, clipka wrote:
>>> Am 20.08.2014 15:26, schrieb James Holsenback:
>>>
>>>> OTO_Get_Mask
>>>> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
>>>> 0000> Result:0.99999997764825820923
>>>>
>>>> Hmmm ... OK I think this shows problem the above is output from inside
>>>> the OTO_Get_Mask function ... I now see why reversing the logic (and my
>>>> "on a lark" test) in corner test works
>>>
>>> Bingo!
>>>
>>> Okay, you obviously have already figured a way around this problem by
>>> way of modifying OTOc.inc, and I think I now have enough information to
>>> go hunting for the root cause in the codebase.
>>>
>>> I might come back to you for testing of some code modifications, if
>>> that's ok for you.
>>>
>>
>> curious if you've had any time to follow up
>
> Now that I've returned from outer space, I have at last; can you please
> try the following patch:

Well my job (10hrs a day 7 days a week) is a black hole ...

>
> At the beginning of source/base/colour.h, around line 95, replace the
> following lines:
>
> const float kRedIntensity   = 0.297;
> const float kGreenIntensity = 0.589;
> const float kBlueIntensity  = 0.114;
>
> with this:
>
> const PreciseColourChannel kRedIntensity   = 0.297;
> const PreciseColourChannel kGreenIntensity = 0.589;
> const PreciseColourChannel kBlueIntensity  = 0.114;
>
> I /think/ it should fix the issue. The culprit would then have been
> change 0ea2da4.

I will do my best, but can't promise any sort of time frame

Post a reply to this message

On 13-1-2015 20:02, James Holsenback wrote:
> Well my job (10hrs a day 7 days a week) is a black hole ...

No kidding? Slavery has been prohibited as far as I know... :-\

-- 
Thomas

Post a reply to this message

On 01/06/2015 05:42 PM, clipka wrote:
> Am 28.08.2014 um 19:41 schrieb James Holsenback:
>> On 08/20/2014 09:40 AM, clipka wrote:
>>> Am 20.08.2014 15:26, schrieb James Holsenback:
>>>
>>>> OTO_Get_Mask
>>>> <-8.00000000000000000000,-5.00000000000000000000,0.0000000000000000
>>>> 0000> Result:0.99999997764825820923
>>>>
>>>> Hmmm ... OK I think this shows problem the above is output from inside
>>>> the OTO_Get_Mask function ... I now see why reversing the logic (and my
>>>> "on a lark" test) in corner test works
>>>
>>> Bingo!
>>>
>>> Okay, you obviously have already figured a way around this problem by
>>> way of modifying OTOc.inc, and I think I now have enough information to
>>> go hunting for the root cause in the codebase.
>>>
>>> I might come back to you for testing of some code modifications, if
>>> that's ok for you.
>>>
>>
>> curious if you've had any time to follow up
>
> Now that I've returned from outer space, I have at last; can you please
> try the following patch:
>
> At the beginning of source/base/colour.h, around line 95, replace the
> following lines:
>
> const float kRedIntensity   = 0.297;
> const float kGreenIntensity = 0.589;
> const float kBlueIntensity  = 0.114;
>
> with this:
>
> const PreciseColourChannel kRedIntensity   = 0.297;
> const PreciseColourChannel kGreenIntensity = 0.589;
> const PreciseColourChannel kBlueIntensity  = 0.114;
>
> I /think/ it should fix the issue. The culprit would then have been
> change 0ea2da4.

I'm unable to get a clean build after beta6 and I don't have time to 
troubleshoot. Wooo hoo I'm getting my 1st day off (this coming sunday) 
since the 1st of the year, and I'm not inclined to spend that time 
trying to unravel. I DID however notice you made a change on the Wiki to 
the "Strings" documentation. What time frame are you looking at for a 
release? There have been other doc changes since last release and I'd 
like to pick up the changes and post the new doc sets if there aren't 
any more changes.

Post a reply to this message

Am 23.01.2015 um 19:25 schrieb James Holsenback:

> I'm unable to get a clean build after beta6 and I don't have time to
> troubleshoot.

beta6? Wait, that's UberPOV, isn't it?

It was my understanding that we were talking about fixing POV-Ray proper 
for now. Once we have that sorted out, it can be merged into UberPOV.

> Wooo hoo I'm getting my 1st day off (this coming sunday)
> since the 1st of the year, and I'm not inclined to spend that time
> trying to unravel.

Can't blame you :D

> I DID however notice you made a change on the Wiki to
> the "Strings" documentation. What time frame are you looking at for a
> release? There have been other doc changes since last release and I'd
> like to pick up the changes and post the new doc sets if there aren't
> any more changes.

As for a full-fledged official release, with installer and all, I guess 
you'll have to ask Chris about that one. He had intended to do a build 
earlier this month, but it seems like real life interfered.

I've just released a new semi-official development build (see 
povray.beta-test), but that's just a drop-in replacement for the binary, 
without any docs.

Post a reply to this message