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