|
 |
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
|
|
