....  thus narrowing the problem down to
> > why #local U = 0; "fixes" the issue.
>
> Huh? I thought the problem was that some variation of "0*N <= 0" didn't
> seem to work out; now you're saying that "U=0" wasn't holding?

Debugging developments, my Dear Boy.  The Game is afoot!

> But the output you posted from the `#debug concat ("Testing Y = ...`
> statement clearly showed that at least the debug output accessed the
> expected element of UArray, so why should the subsequent `#if` statement
> access a different element of UArray, if they both access element [U]?

Yeah - no kidding.  I have tried my best to pore over this, and am gonna go
blind or insane - which is usually the point at which I ask for genuine help.

At Line 318, I even threw in:
#if (U = 0) #debug "U = ZERO \n" #end


> > This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
> > (both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
> > tower at work.
>
> I presume that comma after "3.7.0.msvc10.win64" stands for "and", not
> further qualification; i.e. it happens in official POV-Ray for Windows
> as well as in QtPOV-Ray.

Correct - one runs on the win partition, and the other runs on the Mint
partition of the exact same laptop.

> That pretty much rules out the tenth level of floating point hell
> hypothesis, because the official POV-Ray for Windows binaries use
> "proper" floating point math.

Which is why I switched over to Windows, to see if there was an issue with
running it on the QTPOV-Ray build.

> It also means that we both /should/ get exactly the same results,
> because official version 3.7.0.msvc10.win64 is precisely the versions
> I've just verified my results with the code you posted prior to posting
> my most recent replies.


> So the `#if` clause MUST be entered in the first loop iteration (which
> /should/ be, and /is/, U=0, with UArray[U]=<0,0,1.047something) -
> because that's what is to be expected, and that's what I am absolutely
> positively seeing here, double-checked and all, with the exact same
> piece of software - unless your CPU is buggy, or some gremlin has pooped
> on your RAM, or whatever.

I think I'm reading that correctly.
You are now as officially perplexed as I am.
{But perhaps a ram has pooped on my Gremlin - and then I'd need a car wash.}

> Sounds like not a minimal scene.

It's the whole "closed system", to give you the most "precise" (accurate) way to
replicate what I'm seeing over here.  Now we can reference exact decimal line
numbers and everything.  The code you're working with "should be" good enough
.....  and that exact code (minus line break artefacts) was what I ran on my work
machine before copy-pasting it, so ....

> Is it any more enlightening than the code you posted earlier?

It "shouldn't be" - but precise is precise.  Running the scene in the zip with
the includes leaves no room for "that's not the exact code you posted..." and so
there shouldn't be ANY ambiguity, and you can tell me if the values I'm looking
at - out to 32 decimal places - are off, or I'm using one wrong variable name,
or syntax, or ---- something else I'm completely "familiarity-blind" to at this
point.

(I know, I know - the upper limit for that range (as shown below) is now
0.89759790102565518 - where it ought to be, but I'm not testing against the
upper limit now, am I?)

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





I mean, I'd love to get this worked out, and understand what the problem is -
but I'm getting that "He's gonna KILL me when he finally finds ..... whatever
stupid thing is wrong" feeling.  :(

But I mean, paste
#local U = 0;
into there and watch it go...
It'll loop endlessly, obviously.... but it doesn't step up to a U value
referencing an uninitialized array element either.

I'll play with some flags and also try converting it to a
#while (U < Usize)
loop tomorrow....




(I can only imagine the insanity that must occur on projects with tens of
thousands or millions of lines of code....)


If you haven't completely oriented yourself to the flow yet,
around Line 662 starts a new section of code that just "adds onto" the scene
generated by the prior code.
Loop from 0 to 1
Calculate x and y values (u and v) and pass those to the PatchUV macro at Line
361.   That calls ThisPatch macro which gives the array element corresponding to
an individual bicubic_patch, and then the rest of the PatchUV macro is supposed
to locate exactly where on that bicubic patch the point lies.

I was working on getting PatchUV to give me the desired and expected final scene
results when the current issue popped up.

Post a reply to this message