The revised code for bigPatch is now available at
http://will.thornhenge.net/bigpatch/index.html New in this version are fixes
to the control hull code and corrections of a couple of problems with
incorrect orientations. A last minute repair error prevented the earlier
code from working properly in many situations; this has been fixed, too.

The only remaining problem I am aware of at this moment is that uv_mapping
is not as well controlled as I'd like it to be. That is, I've got it
working, but I would like to be able to fine tune the image map to the
contours of the mesh-- is there a way to do this? You can see the problem on
the example images at the web site.

I think I've made the licensing more clear-- that bigPatch is to be free for
individual use, including modifications and extensions, but is not public
domain. I've read the discussion about licensing issues that happened last
autumn (thanks for the pointer to those, Tor) and I think what I now have
would satisfy the objections I saw in that thread. I'm open to more
discussion on this if need be.

Please take a look and give me your feedback. Especially about the
uv_mapping stuff.


TIA,
Will
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

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

...
> The only remaining problem I am aware of at this moment is that
> uv_mapping is not as well controlled as I'd like it to be. That is,
> I've got it working, but I would like to be able to fine tune the
> image map to the contours of the mesh-- is there a way to do this? You
> can see the problem on the example images at the web site.
> 
> I think I've made the licensing more clear-- that bigPatch is to be
> free for individual use, including modifications and extensions, but
> is not public domain. I've read the discussion about licensing issues
> that happened last autumn (thanks for the pointer to those, Tor) and I
> think what I now have would satisfy the objections I saw in that
> thread. I'm open to more discussion on this if need be.
> 
> Please take a look and give me your feedback. Especially about the
> uv_mapping stuff.

OK, I have some further comments for you...

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);

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.


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]

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.


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.)


// 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>
  }



Tor Olav

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

...
> Remember that when you have N on a line, then there
> are only N - 1 intervals between them.
...


Err... of course I meant this:

Remember that when you have N points on a line, then
there are only N - 1 intervals between them.


Tor Olav

Post a reply to this message

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

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

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 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?

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.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net



"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

"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

Tor wrote in message
news:Xns### [at] 204213191226...
> Will wrote in news:3e8783bc@news.povray.org:
>
<snip>
> 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.


Looking forward to hearing from you about this!


> > I am confused about the translation you are proposing-- I don't think
<snip>
> No. Here is an example of how you can rewrite
<snip>

Nice explanation. Thanks. I've tried this and I'm adopting the translation
idea as it does make the code cleaner (easier to maintain). To my mind the
scaling makes it harder for me to see what's happening-- I mean that when I
come back to this 6 months from now, I would have a more difficult time
relearning the code if I adopt your scaling concept. That just might be me
and my foibles, YMMV.

As far as optimization for speed, I was disappointed with both of these
techniques, and also with moving the array references into earlier
declarations as you had also suggested. Even when used all together, these
only speed up processing incrementally. Except on possibly a very large
patchwork, I'd need a fine stopwatch to see the improvement. Bummer.

OTOH, I've found that excluding the clipped_by segment speeds up processing
a very great amount. I'm wondering if the clipped_by is disabling POV's
implicit bounding box construction.

I'm going to spend a few hours playing with an alternate approach that might
get around the need for the clipped_by and also correct the uv_mapping
problems. If I can't do that, I'll see what happens if I construct an
explicit bounding box.



> 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.

For a one-shot, that would be acceptable to me. For a tool that I want to
use over and over again, and share with others, it is not. Either the macro
handles uv_mapping in the normally expected way, or it gets an attached
disclaimer that says uv_mapping is only supported to a limited degree.



--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

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

...
>> 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.
> 
> For a one-shot, that would be acceptable to me. For a tool that I want
> to use over and over again, and share with others, it is not. Either
> the macro handles uv_mapping in the normally expected way, or it gets
> an attached disclaimer that says uv_mapping is only supported to a
> limited degree. 

OK, but you could have let a macro do the necessary adjustments
to the pigment.


An alternative is to change your uv_vectors to this:

<C-1, R-1>/<Cols-1, Rows-1>,
<C  , R-1>/<Cols-1, Rows-1>,
<C  , R  >/<Cols-1, Rows-1>,
<C-1, R  >/<Cols-1, Rows-1>


To see the effect, uncomment your clipped_by statement, and use
these statements:

union {
  sphere { <-5, -0, -5>, 0.1 }
  sphere { < 5, -0, -5>, 0.1 }
  sphere { < 5, -0,  5>, 0.1 }
  sphere { <-5, -0,  5>, 0.1 }
  pigment { color rgb <2, 2, 2> }
}

light_source { <-1, 2, -2>*100 rgb <1, 1, 1> }

background { color blue 1 }

camera {
  orthographic
  location 12*y
  look_at 0*y
}

object {
  bigPatch(<-5, 0, -5>,<5, 0.02, 5>, PiThing)
  texture {
    uv_mapping
    pigment {
      object {
        box { <0, 0, 0>, <1, 1, 1> }
        color red 1
        color green 1
      }
    }
/*
    pigment {
      image_map {
        png "test"
//        png "mtmandj"
        once
        interpolate 2
      }
    }
*/
  }
}


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:

> I have attached two images
>  [Image]
> 
>  [Image]

Um... Tor...

-- 
Ken Tyler

Post a reply to this message