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