Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Alan W. I. <ir...@be...>]

On Sat, 9 Nov 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > I haven't looked at the code in detail, but I am just going on the
>  > documentation here.  All pltr2 seems to do is interpolate (with boundary
>  > checks).  So shouldn't it be straightforward to make variations on pltr2
>  > that accept and use a PLPointer which includes either the nx(j) information
>  > or ny(i) information?  I realize that such variations are not all that needs
>  > to be done by a long shot, but if these fundamental bits are possible, then
>  > I think the rest should be straightforward for all 3D API's that currently
>  > reference an interpolater such as pltr2.
>
> I don't think this belongs in pltr(), because it is called so deep in the
> loop.  You need something that can influence the control structure, so we're
> probably talking about function arguments e.g. (*fnx)(j) & (*fny)(i), for
> which the default is to return a constant (nx & ny, respectively).
>
> The bigger problem is reordering the loops in order to support *both* nx(j)
> and ny(i) -- the varying one needs to be in the inner loop of course.  So in
> general you'll need two versions of each plotter.  One of those will have the
> loop order swapped from what it is now, which means lots of logic changes in
> the interior of the loop (go look).  An additional complication is that the
> shade & contour plotters use different loop ordering already.  I haven't
> looked at the 3d plotters.
>
> Looks like an awful lot of work.

In my own case, the nx(y) and ny(x) limits are monotonic so my data can be
transformed from one form to the other.  Thus, I would need only one
choice implemented which would greatly simplify the change.  OTOH, this
would introduce a certain lack of generality which would disappoint other
users with irregularly defined regions which cannot be transformed from
the nx(y) form to the ny(x) form.

Perhaps the other idea of filling out the undefined region of the rectangle
with constant z(i,j), x(i,j), and y(i,j) from the last point on the boundary
would work instead.  Naively, I would think the contourer, shader, and other
3D routines would just keep hammering at the boundary values as it swept
through i,j of the extended region and thus produce acceptable results.

Alan