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