I've been spending a great deal of time lately with
the HF_Cylinder macro in shapes.inc,
getting to know its behavior (and the shapes.inc code in general), but running
into a few problems. I'm preparing a newsgroup post concerning some small
changes I've come up with, to help make it a bit more useful. In the process,
I've taken a look at two recent bug-report posts dealing with some proposed
fixes to the code (to correct a problem when #WRITEing high-resolution
height_fields to a file, something I've run into as well)--most of which I've
successfully incorporated into my own shapes.inc file, and work as advertised.
But there's still one proposed fix in those posts that I've had trouble adding,
either because I'm just not writing it correctly or because there's a small
error in the fix somewhere; don't know which.

The original posts are here:
http://news.povray.org/povray.general/thread/%3C41d6bd46%40news.povray.org%3E/
and
http://news.povray.org/povray.bugreports/message/%3Cgk91u0h8lh17tscq6hplsijdfpcsmdt5j5%404ax.com%3E/#%3Cgk91u0h8lh17tsc
q6hplsijdfpcsmdt5j5%404ax.com%3E

My trouble concerns the fix that's written (in the posts) as:
"<",str((F1+A).x,0,0),",",str((F1+A).y,0,0),",",str((F1+A).z,0,0),">",
"<",str((F2+A).x,0,0),",",str((F2+A).y,0,0),",",str((F2+A).z,0,0),">",

which is meant to replace   F1+A, F2+A,   at line 981 in the face_indices part
of the HFCreate_ () macro.)

My many attempts at adding this new code always result in fatal errors (probably
just a string syntax error on my part, but I can't figure it out.)  Could
someone correctly re-write line 981 for me, replacing it with this fix?

My understanding of those posts is that they concern only the #write commands
re: floats written in exponential format for the various mesh2 'headers'--
vertex_vectors, face_indices, etc.-- and I see the reasons for the code fixes;
yet this one fix doesn't (to my eyes) deal with #write. What does it do? Is it
to eliminate 'extreme' exponents in the actual triangle data? (In
successfully-#written lower-resolution HF data files, there are still floats in
exponential format in many of the triangle vectors, which cause no problems.)

BTW, one of my own additions to the code is adding int (or ceil or floor) to
lines 771 and 772 in the HF_Cylinder macro, like this--
#local xRes = int((< 1, 1>*Res).x);
and
#local zRes = int((< 1, 1>*Res).y);

My reason for that is...complicated...so I'll leave my explanation for a later
post. But it solves a problem when the macro is given NON-integer resolution
values. (Of course, that wouldn't ordinarily happen in the usual use of the
macro; but I decided to run it 'unusually' for various reasons--all good!)
Without int added, a fatal parse error is generated at line 840,

#declare PArr[J][K] = P + H*Dir*Depth;

which states, "Array subscript out of range." It's not because the arrays there
are presented with non-integers for their sizes--POV takes care of that
internally--so I'm wondering what's generating the error? I'm also wondering
whether my little int addition *might* eliminate the necessity for the
F1+A, F2+A,  code fix. Just crazy intuition.

Ken Walker

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> In the process, I've taken a look at two recent bug-report posts...

Not so recent; kind of old, in fact. (Just looked at the dates!)

KW

Post a reply to this message

There's something important I forgot to mention when #writing a file (at least
with the HF_Cylinder macro)--only because I've been working with shapes.inc so
long that I've used to dealing with it:

In order to #write a data file, the macro (in your SDL) needs a file name in
double quotes. That's covered in the docs, of course.  But there's a problem if
you happen to #declare the HF macro (either with or without an object wrapper):
Putting any file name into the double quotes in the macro causes it to
fail--with one of two fatal error messages: either "Expected RValue to
declare..." or "Expected object,..." Depending on whether or not the #declared
HF object is enclosed in an object wrapper. (It fails either way.) Adding a
semi-colon separator after the macro doesn't help.  BUT, the good news is that
the data file HAS been successfully #written and saved, and can be used. I
discovered that by chance!

This problem doesn't occur when running the HF macro 'raw' (i.e., no #declare.)

And there's no #declare problem if the macro is left in its 'default'
(non-#writing) mode, with just the two default double quotes (an empty string.)
But then, of course, no data file is #written.

These little problems probably need fixing, but they're not scene-killers, once
you get used to their behavior. I suppose most people wouldn't #declare the HF
macro anyway, if they were planning on #writing it's data file and using THAT
as the object. In which case, this entire problem goes away!

Just thought I would mention this stuff for those wanting to experiment with my
original problems.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
< My trouble concerns the fix that's written (in the posts) as:
< "<",str((F1+A).x,0,0),",",str((F1+A).y,0,0),",",str((F1+A).z,0,0),">",
< "<",str((F2+A).x,0,0),",",str((F2+A).y,0,0),",",str((F2+A).z,0,0),">",

< which is meant to replace   F1+A, F2+A,   at line 981 in the face_indices part
< of the HFCreate_ () macro.)

SUCCESS! After an all-night crash course in subtle string syntax, I was finally
able to write something that worked!

For   F1+A, F2+A,   substitute

"<",vstr(3,F1+A,",",0,0),"> ", "<",vstr(3,F2+A,",",0,0),"> ",

just as written. Works beautifully, but that may not be the end of the high-res
#write problem, as I discovered while working this out.

But time to sleep...more later....

Ken W.

Post a reply to this message

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

I figured out how to eliminate exponential notation from the HFCreate_() macro's
vertex_vectors, too.

At line 903 in the original shapes.inc file, the code is this:
..........
#local J = 1;
   #while (J<=xRes)
      #local K = 1;
      #while (K<=zRes)
         PArr[J][K],
         #declare K = K+1;
      #end
      #declare J = J+1;
..........


Replace it with this:
.........
#local J = 1;
   #while (J<=xRes)
      #local K = 1;
      #while (K<=zRes)
           #if(WriteFile)
           "<",vstr(3,PArr[J][K],",",0,12),"> ",
           #else
           PArr[J][K],
           #end
        #declare K = K+1;
      #end
      #declare J = J+1;
.........

Again, this is a 'global' fix for all the mesh generators using HFCreate.

Frankly, I didn't think such string syntax would work in this case (plugging a
multi-dimensional array into a single vstr statement.) But somehow, POV-Ray
knows what to do, and #writes the 3-value vectors found in both [J] and [K]
correctly.  Amazing!

The only remaining question was, How many decimal places to use for the
triangle-vertex precision? Using the unmodified, orignal shapes.inc, POV-Ray
for Windows #writes a max of 6 decimal places (or rather, always 6 USEFUL
places, if there happen to be zeros to the left.)  But I wonder if that's
enough precision when #writing a high-resolution HF file? I decided to use 12
decimal places. Probably overkill (difficult to determine!) And it does make
the #written file larger (in bytes)...but on fast modern computers, that's a
very small price to pay.

SO...the only things remaining to be fixed in the HFCreate macro (to eliminate
exponential notation) are uv_vectors and normal_vectors. They can both be
updated using similar string syntax and #if/#else commands (although
normal_vectors looks to be particularly difficult!)

Ken W.

Post a reply to this message

Just tying up some loose ends:

Kenneth wrote:
> I'm also wondering whether my little int addition *might* eliminate the
> necessity for the F1+A, F2+A,  code fix. Just crazy intuition.

Nope, the fix is still needed. Oh well, can't win 'em all!

Kenneth wrote:
> In order to #write a data file, the macro (in your SDL) needs a file name in
> double quotes. That's covered in the docs, of course.  But there's a problem
> if you happen to #declare the HF object (either with or without an object
> wrapper): Putting in any name for the file causes the macro, or *something*,
> to fail...
> ....This problem doesn't occur when running the HF macro 'raw' (i.e., with no
> #declare.) [and no object wrappers.]...

I gave this situation some thought, and realized my own wrong assumption about
how the shapes.inc macros work. The mesh2 macros there function in two
different, mutually exclusive ways--depending on if they are #WRITEing data or
not.  Either the macro creates an 'object' in the scene (when NOT #writing), or
becomes just 'a set of instructions for #writing a file.' It's an either/or
situation, not both. What I had *expected* was for the macro to #write data AND
produce an object which POV renders, all at the same time.  That's not the way
the code is written--and probably for good reason. In order to do BOTH things
at once, the code would have to first #write the data to a file, then #read(?)
back that data in order to generate the object. (Which would slow things down.)
Or else, a great deal of the code would need to be duplicated--one set
exclusively for #writing, the other for feeding directly into POV-Ray for a
'simultaneous' object render. (In which case, both code sets would have to be
parsed, again taking extra time.)

By adding a #declare (and/or object wrappers) to the HF_Cylinder macro during
the #write pass, I had inadvertently given shapes.inc some 'extra' code
snippets that it wasn't designed to handle; thus the fatal error. So the
reality is: When #writing data, use the 'raw' macro in your SDL.

Ken W.

Post a reply to this message

Kenneth wrote:
> In order to do BOTH
> things at once, the code would have to first #write the data to a file,
> then #read(?) back that data in order to generate the object. 

You #include the file back, since it's valid POV-Ray syntax.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Kenneth wrote:
> > In order to do BOTH
> > things at once, the code would have to first #write the data to a file,
> > then #read(?) back that data in order to generate the object.
>
> You #include the file back, since it's valid POV-Ray syntax.

Ah, yes.  Sorry, my poor brain was quite dead after all that thinking. :-)

KW

Post a reply to this message