OK, I'm back, refreshed!

> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
> For   F1+A, F2+A,   substitute
> "<",vstr(3,F1+A,",",0,0),"> ", "<",vstr(3,F2+A,",",0,0),"> ",
>

Yes, this works--but ONLY when #writing the data file, I've discovered; it
generates a fatal error when the HF_Cylinder macro is run normally. (POV
doesn't seem to like that particular string syntax being fed straight into it.)
So to get around THAT little snafu, I added a simple #if/#else block so the fix
*always* works.

The original, pristine block of code around line 981 is written as
...........
#local A = J*zRes;
      #while (mod(A+1,zRes))
         F1+A, F2+A,
         #local A = A+1;
      #end
      #local J = J+1;
...........

My 'latest' fix is this:
...........
#local A = J*zRes;
      #while (mod(A+1,zRes))
       #if(WriteFile)
     "<",vstr(3,F1+A,",",0,0),"> ", "<",vstr(3,F2+A,",",0,0),"> ",
      #else
      F1+A, F2+A,
       #end
  #local A = A+1;
      #end
      #local J = J+1;
...........

POV-Ray has no problem dealing with F1+A, F2+A internally; it just needs to be
in a different format when #written to a text file. The fix eliminates
exponential notation from the face_indices vectors--a necessity at hi-res-- and
changes it to integers.  Could probably be written with more elegance, but works
as-is. BTW, it's 'global,' affecting all the mesh generators that use the
HF_Create() macro.

This code is to prevent a whopping near-crash of POV, a 'hang,'when a HF over
certain critical res values is #written.  (The #writing isn't the problem, it's
the reading back of the mesh2 file.) That res limit on my machine, running
32-bit POV-Ray, is 1000 X 999 or almost exactly 1,000,000. (An interesting
number!)  The problem, as I see it, basically concerns the way face_indices
work, and how POV #writes data to the vectors there. Face_indices need steadily
increasing integers. The first value of its first vector is zero--"zero based,"
as the docs say--and simply counts up from there. By default (or so it seems),
POV #writes those integer values into the vectors with a maximum of only 6
digits--like 999999--then for larger values, switches to exponential format,
such as  1.22714e+06. That, by itself, isn't a problem--POV can read those
back.  But as the resolution of the HF increases and the vector values likewise
increase, the 'difference' between any two vectors becomes less and less, until
at really hi-res, the difference is extremely small. The way exponential
notation is #written by POV--with only 5 (or 6) digits after the decimal
point-- there comes a point where the notation can't differentiate between such
tiny values, and #writes two or more *identical* vectors.  This creates a
problem, as the up-count effectively stops there. It's at that point, I
believe, that POV generates its fatal error.

Vertex_vectors are 'different' from face_indices; they're the actual points of
the generated triangles. Since they vary in position, and seem to use as many
decimal places as needed, (though exponents still have only 6), they have
less(?) of a chance of duplicating each other....although it *is* possible, I
suppose. I'm guessing that any duplicated values would only create a few tiny
degenerate triangles. Ideally, vertex_vectors should get the code fix too;
still working on that.

This current hang-up is NOT the res *limit* of the mesh generators; far from it.
Only when #writing to a file. ALL of this may have been fixed by now in the 3.7
betas??

KW

Post a reply to this message