I have worked out the large majority of what needs to be done to get 16 points
to sit directly ON an array of 9 bicubic_patches, or rather, have smoothly
contoured patches align with the data.

At this juncture, I can't seem to be able to get the edges of the bezier patches
to stay aligned with one another, no matter what I do.   Blind brute-force
defining all four edge points did not seem to work, and even seemed to make
things worse.   Which means I've probably looked at the code for too long and
I'm probably mentally overlooking, filtering, or wrongly thinking or assuming
something.

If someone could look over what I've got and see if there's anything that's
obviously wrong, that would be great.   I'd like to get this working and have it
be a robust tool that can be adapted, used, and improved upon.

Also, if anyone can explain how to get the inside_texture to point downward
along -y in a way that does not involve rotating the patch(es) around x or z by
180 degrees, that would be very helpful.

Thanks!

Post a reply to this message

Attachments:
Download 'bicubic.zip' (8 KB)

Am 10.03.2016 um 12:14 schrieb Bald Eagle:

> Also, if anyone can explain how to get the inside_texture to point downward
> along -y in a way that does not involve rotating the patch(es) around x or z by
> 180 degrees, that would be very helpful.

Arranging the control points the other way round ("clockwise" vs.
"counter-clockwise") should to the job.

Post a reply to this message

On 3/10/2016 11:14 AM, Bald Eagle wrote:
>

#include "TempGradient.inc" ?


-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Arranging the control points the other way round ("clockwise" vs.
> "counter-clockwise") should to the job.

I thought so too, since it ought to be just like triangles, but using either
  uv_vectors <0,0> <1,0> <1,1> <0,1>
or
  uv_vectors <0,0> <0,1> <1,1> <1,0>

gave me the same result.

bicubic_patch {
  type 1
  flatness 0.1

  u_steps 4 // number of triangles to subdivide (1 to 5)
  v_steps 4 // number of triangles to subdivide (1 to 5)
  //uv_vectors <0,0> <1,0> <1,1> <0,1>
  uv_vectors <0,0> <0,1> <1,1> <1,0>

  <-2, 0,  2>, <-1, 0,  2>, <1, 0,  2>, <3, 0,  2>,
  <-2, 0,  1>, <-1, 0,  1>, <1, 0,  1>, <3, 0,  1>,
  <-2, 0, -1>, <-1, 0, -1>, <1, 0, -1>, <3, 0, -1>,
  <-2, 0, -2>, <-1, 0, -2>, <1, 0, -2>, <3, 0, -2>

 uv_mapping
   interior_texture  { pigment { image_map { png "Numbered_Grid-Red-Blue.png"  }
scale 1} finish {phong 0.6 phong_size 20}}
     texture { pigment { image_map { png "Numbered_Grid-Red-Green.png" } scale
1} finish {phong 0.6 phong_size 20}}

  scale <1, 1, 1> rotate <180, 0, 0> translate <0, 0, 0>
} // end of bicubic_patch
----------------------------------------------------------

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
Oh, sorry - that's just a sorta HSV colormap.

Post a reply to this message

Attachments:
Download 'tempgradient.inc.txt' (3 KB)

On 3/10/2016 7:43 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
> Oh, sorry - that's just a sorta HSV colormap.
>

No worries.

-- 

Regards
     Stephen

Post a reply to this message

Am 10.03.2016 um 20:42 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> Arranging the control points the other way round ("clockwise" vs.
>> "counter-clockwise") should to the job.
> 
> I thought so too, since it ought to be just like triangles, but using either
>   uv_vectors <0,0> <1,0> <1,1> <0,1>
> or
>   uv_vectors <0,0> <0,1> <1,1> <1,0>
> 
> gave me the same result.

It's not the uv_vectors you need to rearrange -- it's the control points.

> bicubic_patch {
...
>   <-2, 0,  2>, <-1, 0,  2>, <1, 0,  2>, <3, 0,  2>,
>   <-2, 0,  1>, <-1, 0,  1>, <1, 0,  1>, <3, 0,  1>,
>   <-2, 0, -1>, <-1, 0, -1>, <1, 0, -1>, <3, 0, -1>,
>   <-2, 0, -2>, <-1, 0, -2>, <1, 0, -2>, <3, 0, -2>

Flip these points around the diagonal.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> It's not the uv_vectors you need to rearrange -- it's the control points.
> Flip these points around the diagonal.

Hmmm.   Interesting.
That seems to be ... right-handed rule, no?

  <-2, 0,  2>, <-2, 0,  1>, <-2, 0, -1>, <-2, 0, -2>,
  <-1, 0,  2>, <-1, 0,  1>, <-1, 0, -1>, <-1, 0, -2>,
  < 1, 0,  2>, < 1, 0,  1>, < 1, 0, -1>, < 1, 0, -2>,
  < 3, 0,  2>, < 3, 0,  1>, < 3, 0, -1>, < 3, 0, -2>

Moving left to right across the rows:
u gets defined in the POV -z direction,
(1st finger)

Moving top to bottom down the columns:
v gets defined in the POV +x direction,
(2nd finger)

and so u x v is in the +y direction
(thumb)


Has anyone written a matrix / array transposition macro for POV-Ray?

Post a reply to this message