Tor Olav Kristensen wrote in message
news:Xns### [at] 204213191226...
> Will W wrote in
> news:3e86277b@news.povray.org:

<snip>

> The first one is about the same two lines that I
> commented on earlier:
>
> #local dX = (toPt.x-fromPt.x)/Cols;
> #local dZ = (toPt.z-fromPt.z)/Rows;
>
> Remember that when you have N on a line, then there
> are only N - 1 intervals between them.
>
> So the resulting patch will be more "correct" if you
> change these lines to:
>
> #local dX = (toPt.x - fromPt.x)/(Cols - 1);
> #local dZ = (toPt.z - fromPt.z)/(Rows - 1);


I'll take another look at this. This is exactly the kind of feedback I
need-- another pair of eyes can immediately see goofs that my preconceptions
blind me to.


> You will see the effect from this better if you
> temporarily remove your clipped_by statemnt and add
> a colored sphere at each of the four corners of the
> patch. The pacth will now have an equally wide flat
> "border" at all the edges.


I've found marker spheres useful in developing this macro. But I don't
understand what you trying to tell me. I'll do the exercise, maybe your
point will become clear then.


>
>
> The next one is about this uv vectors statement:
>
> uv_vectors <(C-dX)/Cols,(R-dZ)/Rows>
>
> Here you have <Columns, Rows> while you have
> [Rows][Columns] when indexing your array:
>
> A[R][C][Y]

It is a bit odd, but I'm pretty sure that is right. I want the initial data
array to be intuitively obvious to the user, which means defining it as
Array[Row][Col]. This is imposed upon me by the way the array initializer in
POV works-- I really wanted to define the arrays as Array[Col][Row], which
is consistent with my spreadsheet experience, and with the cartesian
coordinate system used in POV's vectors. But I couldn't do that if I want
users to be able to cut and paste array content into an array initializer.

What's important is that the Cols and the x-coordinates and the Rows and
z-coordinates match up. (or in this case, Cols match with u and Rows match
with v). But it does end up looking strange.


> This looks a little bit odd to me, and I'm not sure
> if the result is what the user expects. (But I might
> be wrong here.)
>
>
> And another comment is about your intensive use of
> array lookups. This can be a very time consuming
> task for POV-Ray to do, so often it is better to
> look up a value once and put it in a 'plain' variable
> for later use.


True. There's a huge amount of room for performance optimization since this
was written to optimize human readability (and thus debugging).


> My last comment (for now) is about repeating calcu-
> lations that POV-Ray has already done earlier.
>
> Have a look at the code below code. (It does the same
> as yours but calculates iX + dX*C and iZ + dZ*R only
> once in each loop instead of 16 times.)

Again true. This is also to some degree an artifact of production, since it
let me easily play around with changing the points' offsets.

Thanks very much for your help with this, Tor.

Post a reply to this message