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

> 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