This works fine with megapov 0.5a (the bicubic patch has a checker pigment
applied to it) but in megapov 0.6a the bicubic patch is just white:

camera { location -z*8 look_at 0 angle 35 }
light_source { -z*10, 1 }

bicubic_patch
{ type 1 flatness 0 u_steps 4 v_steps 4,
  0, x, x*2, x*3,
  y, x+y, x*2+y, x*3+y,
  y*2, x+y*2, x*2+y*2, x*3+y*2,
  y*3, x+y*3, x*2+y*3, x*3+y*3

  uv_mapping
  pigment { checker rgb x, rgb 1 scale .125 }
  translate <-1.5,-1.5,0>
}


-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a0d3d1d@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   This works fine with megapov 0.5a (the bicubic patch has a checker 
>   pigment applied to it) but in megapov 0.6a the bicubic patch is 
>   just white:

UV-mapping of bicubic patches changed between the two versions. I think 
it is explained under "8.6.4. Other changes related to UV mapping" in 
the MegaPOV manual.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> >   This works fine with megapov 0.5a (the bicubic patch has a checker
> >   pigment applied to it) but in megapov 0.6a the bicubic patch is
> >   just white:
>
> UV-mapping of bicubic patches changed between the two versions. I think
> it is explained under "8.6.4. Other changes related to UV mapping" in
> the MegaPOV manual.

A change that was made in version 0.6a is that the uv_vectors need to be
specified AFTER the patch vectors and before the uv_mapping keyword.
Warp's example renders properly if specified as:

bicubic_patch
{

  type 1
  flatness 0
  u_steps 4
  v_steps 4,
  0, x, x*2, x*3,
  y, x+y, x*2+y, x*3+y,
  y*2, x+y*2, x*2+y*2, x*3+y*2,
  y*3, x+y*3, x*2+y*3, x*3+y*3
  uv_vectors <0, 0>, <1, 0>, <1, 1>, <0, 1>

  uv_mapping
  pigment { checker rgb x, rgb 1 scale .125 }
  translate <-1.5,-1.5,0>
}

But there is still a bug present, since it should render properly without
ANY uv_vectors specified.  I'm not positive, but I think that when someone
moved the code:

MSquareQuad(Object->ST, Object->Mapping); /* mapping matrix */

in parse.c, it caused that section of the code to not execute unless
uv_vectors are specified with the patch.  The result is that mapping
transform is not performed on the uv_vectors created with the patch by
default, and thus the texture is not mapped correctly.  Again, not sure but
I think that's the problem.

-Mike

Post a reply to this message

Yes, it would make sense that <0,0>,<1,0>,<1,1>,<0,1> would be the default
if none is specified.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message