Am 16.09.2018 um 14:46 schrieb clipka:

> `BezierStitching_Test_3.pov` gives me a `Cannot find file
> 'GridMacro.png' in line 91, which I /think/ is not the problem we're
> talking about.

Okay, now that I've just bypassed that offending image_map and bump_map,
I get an error in line 324, the `#debug` line printing `Testing YVal =
...`, at what appears to be index U=7.


If I place a `#debug "***MATCH!***\n"` in line 327 in front of the
commented-out `#if` statement, I get the following output:

------------------------------------------------------------------
[...]
_X = 0.00000, _Y = 0.00000
Starting macro PatchUV
Starting macro ThisPatch
U = ZERO
Testing YVal = 0.00000000 vs
 [U=0.00000000] <0.00000000000000000000000000000000,
0.00000000000000000000000000000000, 0.89759790102565518000000000000000>

***MATCH!***
Testing YVal = 0.00000000 vs
 [U=1.00000000] <1.00000000000000000000000000000000,
0.89759790102565518000000000000000, 1.79519580205131040000000000000000>

Testing YVal = 0.00000000 vs
 [U=2.00000000] <2.00000000000000000000000000000000,
1.79519580205131040000000000000000, 2.69279370307696550000000000000000>
[...]
------------------------------------------------------------------

Note how this clearly and unambiguously demonstrates that the `#if`
condition in line 326 is met in the first loop iteration, i.e. POV-Ray
properly recognizes that YVal = 0 falls neatly inside the range
[0...whatever), and is consistent with it properly examining array
element 0, not anything else.


So my current hypothesis is that you /think/ the error at U=7 is not the
one you're looking for, but it's the one you're actually fighting with
at the moment.

This is also perfectly consistent with your observation that a `#local U
= 0;` right at the beginning of the loop "fixes" this issue, because
then the loop is stuck at U=0 and never reaches the offending index U=7.


Now if I weed out the cruft that's in the way - the one you say you
hoped to fix later - and change the `#for` loops in lines 316 and 337,
to run not to `Usize` and `Vsize` respectively, but `Usize-1` and
`Vsize-1`, this part of the code starts to run smoothly...


... and, hey presto! *NOW* I can at last witness the "Attempt to access
uninitialized array element" error you're presumably /really/ trying to
solve. /Now/ that /I/ have weeded out the cruft (as I had earlier
suggested /you/ do), I can at last get down to the bottom of it, rather
than fight with you about ghosts you're seeing that I'm not seeing.

And I find that while you've been trying to debug the "U side" of the
macro, the actual error message pertains to array elements initialized
by the "V side" of the macro; and indeed, there's a neat little debug
message:

    _Patch [3] V not defined

which confirms that the V side has failed to kick in, not the U side.

And if I look closely at the case at hand, I see why: The error happens
at _X (which goes into the V side) = 6.300; the ranges in VArray[] only
go up to ~6.283 though, so no matching range is found. Now theoretically
the problem might be that VArray is too short, and should be initialized
longer; but since the upper bound of the last tested array element is
equal to 2*pi, it seems plausible that VArray is fine, so _X must be at
fault.

Now all we have to figure out is why _X goes beyond 2*pi in the first
place, and we have the whole case solved.

Or you have to make _X wrap around to the range [0..2*pi) if it goes out
of that range.


I leave the rest as an exercise to you. Let me know if you hit another
impasse.


Isn't it fascinating how quickly one can get to the bottom of a problem
once a little bit of cruft, which you /thought/ was insignificant but
totally obstructed my view on things and skewed yours, has been moved
out of the way?

Post a reply to this message