"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in
news:3e8783bc@news.povray.org: 

> These are interesting ideas. I'll look into them once I'm satisfied
> the control hull is good enough. I'm pretty sure it is, but I'm going
> to wait a few days on that and see if there are any other opinions.
> I'm sort of abusing the bicubic_patch by treating the points of the
> control hull as if they were controlling bezier vectors attached to
> the nearest data point. There may well be better forms of abuse than
> the one I've chosen (doing it right would entail a lot of cubic
> expressions and I think slow things down to a huge amount-- and not be
> anywhere near as much fun). 

I have some ideas on how to define all the
control points. It's quite simple, but I'm
too tired to explain it right now.


> I am confused about the translation you are proposing-- I don't think
> that, for instance,  (iX+dX*C) can be subtracted out from all the
> points in the bicubic. Wouldn't that imply that  dX*C + 0.5 = dX*(C +
> 0.5) which I think breaks the law of distribution of multiplication
> over addition? 


No. Here is an example of how you can rewrite
one of the expressions:

<
  iX + dX*(C + 1/2),
  dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
  iZ + dZ*(R + 1)
>

=

<
  iX + dX*C + dX/2,
  dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
  iZ + dZ*R + dZ
>

=

<
  dX/2,
  dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
  dZ
>
+<iX + dX*C, 0, iZ + dZ*R>

=

<
  0.5,
  A[R+1][C+1][Y] - A[R+1][C+1][X],
  1.0
>
*<dX, dY, dZ> + <iX + dX*C, 0, iZ + dZ*R>


> I think your corrections to the expressions defining dX and dZ are
> right, and I had them wrong.
> 
> I've gaining a better understanding of the uv_mapping problem. What is
> happening is the image is being mapped correctly to the entire
> patchwork, which includes the pseudodata rows and columns. So the
> margins of the image are lost when the patchwork is clipped to its
> final size, and the image has also undergone the equivalent of a scale
> <1+2*dX, 1, 1+2*dZ>. I'm at a loss about how to correct for these
> problems. That is, unless I turn the uv_mapping statement into
> something really ugly. 

Why don't you just scale down the pigment that
is going to be used in the mapping (prior to
the mapping).

E.g.:
If it is an image map, then you first translate
the image map pigment so that it is centered at
the origin, scale it and then translate it back.


Tor Olav


> 
> "Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
> news:Xns### [at] 204213191226...
>> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in
>> news:Xns### [at] 204213191226:
>>
>> ...
>>
>> > 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.)
>> >
>> >
>> > // This first line should be placed outside the loops
>> > #local vXYZ = <dX, dY, dZ>;
>> > .
>> > <snip>
>> > .
>> >   bicubic_patch {
>> >     type 1  flatness 0 u_steps 3 v_steps 3
>> > .
>> > <snip>
>> > .
>> >     <0.0, A[R  ][C  ][Y]                 , 0.0>*vXYZ
>> >     <0.5, A[R  ][C  ][Y] + A[R  ][C  ][X], 0.0>*vXYZ
>> > .
>> > <snip>
>> > .
>> >     <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>*vXYZ
>> >     <1.0, A[R+1][C+1][Y]                 , 1.0>*vXYZ
>> >     translate <iX + dX*C, 0, iZ + dZ*R>
>> >   }
>>
>>
>> I forgot to mention that you can probably move the
>> vXYZ vector into a scale statement at the end to save
>> further calculations. Like this:
>>
>>
>>   bicubic_patch {
>>     type 1  flatness 0 u_steps 3 v_steps 3
>> .
>> <snip>
>> .
>>     <0.0, A[R  ][C  ][Y]                 , 0.0>
>>     <0.5, A[R  ][C  ][Y] + A[R  ][C  ][X], 0.0>
>> .
>> <snip>
>> .
>>     <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>
>>     <1.0, A[R+1][C+1][Y]                 , 1.0>
>>     scale vXYZ
>>     translate <iX + dX*C, 0, iZ + dZ*R>
>>   }
>>
>>
>> Tor Olav
> 
>

Post a reply to this message