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