Sometime in June of last year, I submitted for MegaPOV an alternate method
for calculating the parametric mapping for patches.  The intention was to
have the option of providing an arbitrary quadrilateral represent the
texture coordinates of the patch but at the time a seemingly minor problem
was present.  Basically any time the texture coordinates deviated from a
rectangle a perspective distortion was introduced.  Recently I noticed that
the paper I adapted the code from was interested in inferred perspective
mapping for raster projection.  The net result is that in many cases,
texture coordinates that should stitch smoothly at the edge of two patches
do not do so and this problem is still present in the 3.5 beta.

I've spent the entire weekend working on a fix because this is close to
being official and think I have found a good solution.  Only 3 files need to
be changed.  The following is using the original code from MegaPOV.

Starting with matrices.c, we can get rid of the function MSquareQuad()
altogether since it's no longer necessary to compute the 3x3 homogenous
matrix when a patch is parsed.  A little further up in the file, the
function MTransUVPoint needs to be changed to the following:

void MTransUVPoint(p, st, t)
UV_VECT st[4];
double p[2], t[2];
{ 
 UV_VECT u1, u2;
 
    u1[0] = st[0][0] + p[0] * (st[1][0] - st[0][0]);
    u1[1] = st[0][1] + p[0] * (st[1][1] - st[0][1]);

    u2[0] = st[3][0] + p[0] * (st[2][0] - st[3][0]);
    u2[1] = st[3][1] + p[0] * (st[2][1] - st[3][1]);

    t[0] = u1[0] + p[1] * (u2[0] - u1[0]);
    t[1] = u1[1] + p[1] * (u2[1] - u1[1]);
 
}

Notice that this function is no longer using the tranformation matrix - instead we get
the mapping directly using the texture coordinates ST.  Therefore we need to change
every use of this function in bezier.c to take object->ST instead of object->mapping. 
There's a few of these.  In other words,

This:

MTransUVPoint(uv_point, Shape->Mapping, tpoint);

Becomes this:

MTransUVPoint(uv_point, Shape->ST,
 tpoint);

Since we have switched from using the mapping matrix to using texture
coordinates, we must copy the texture coordinates when we copy a patch.
Near the bottom of bezier.c change:

for (m = 0; m < 3; m++)
  {
    for (h = 0; h < 3; h++)
    {
      New->Mapping[m][h] = ((BICUBIC_PATCH *)Object)->Mapping[m][h];
    }
  }

Into this:

for (m = 0; m < 4; m++)
  {
    for (h = 0; h < 2; h++)
    {
      New->ST[m][h] = ((BICUBIC_PATCH *)Object)->ST[m][h];
    }
  }

Lastly, since MSquareQuad function was removed, it should be removed from
Parse_Bicubic_Patch in parse.c since it appears there at least once.  At
this point everything should work correctly.

I will be posting an example render of what the mapping looked like in 3.5
beta and how it looks with these changes in p.b-t.b.  Here is a code example
for testing.  The texture along the top edge of the bottom patch and the
bottom edge of the top patch should blend smoothly.

#include "colors.inc"
camera {location <0, 0, -2> angle 40}
light_source {<10, 10, -20> color White}

#declare test_pigment =
pigment {
average
pigment_map {
[1
gradient x
sine_wave
frequency 12
color_map {
[0 color White transmit 0]
[1 color Black transmit 0]
}

]
[1 gradient y
frequency 12
sine_wave
color_map {
[0 color Blue]
[1 color White]
}
scale 1
]
}

}
/*
#declare test_pigment =
pigment {
image_map {
tga "gradient.tga"
interpolate 4
}
}
*/

#declare test = union {
bicubic_patch {
type 1
u_steps 4
v_steps 4
uv_vectors <0, 0>, <1, .25>, <1, .5>, <0, .5>
<-3, -3, 0>, <-1, -3, 0>, <1, -3, 0>, <3, -3, 0>,
<-3, -1, 0>, <-1, -1, -3>, <1, -1, -3>, <3, -1, 0>,
<-3, 1, 0>, <-1, 1, -3>, <1, 1, -3>, <3, 1, 0>,
<-3, 3, 0>, <-1, 3, -3>, <1, 3, -3>, <3, 3, 0>
uv_mapping
scale 1/6
pigment {test_pigment}
finish {ambient 1}
}

bicubic_patch {
type 1
u_steps 4
v_steps 4
uv_vectors <0, .5>, <1, .5>, <1, 1>, <0, 1>
<-3, -3, 0>, <-1, -3, -3>, <1, -3, -3>, <3, -3, 0>,
<-3, -1, 0>, <-1, -1, -3>, <1, -1, -3>, <3, -1, 0>,
<-3, 1, 0>, <-1, 1, -3>, <1, 1, -3>, <3, 1, 0>,
<-3, 3, 0>, <-1, 3, 0>, <1, 3, 0>, <3, 3, 0>
uv_mapping
scale 1/6
pigment {test_pigment}
finish {ambient 1}
translate 1*y
}

}


object {test translate -.5*y scale <1, .5, 1>} /* test that patch data is
being copied correctly */

Post a reply to this message

I notice that the effect of tiling/breaks is greatly reduced and there's a
smooth joint between them. I like that. Please add this guys!

Post a reply to this message

"Mike Hough" <Ama### [at] aolcom> wrote...
>
> I've spent the entire weekend working on a fix because this is close to
> being official and think I have found a good solution.  Only 3 files need
to
> be changed.  The following is using the original code from MegaPOV.

Thanks for working on this.  The results in p.b-t.b look great!  Your
contribution is appreciated and I will work to incorporate this fix into POV
3.5.

I have two comments and questions:
You completely rewrote MTransUVPoint.  Really, what you've created is a new
function, not a new version of MTransUVPoint.  Your function takes
completely different inputs and yeilds a different output.  This new
function deserves a new name.  Do you have a suggestion?

Also, since MSquareQuad does not need to be called, we'll probably remove
the call, but leave the function.  It is part of the general collection of
matrix functions, so it will probably stay in case sombody needs to use it
in the future.  Also, if Shape->Mapping is no longer used, we should remove
it completely.  I'm not sure if it is used anywhere else - do you know?

One more question:  Do you have a simple test scene that I could use for
testing?  (Maybe with two patches with a pattern-based texture.)  Thanks!!!

-Nathan

Post a reply to this message

> Thanks for working on this.  The results in p.b-t.b look great!  Your
> contribution is appreciated and I will work to incorporate this fix into
POV
> 3.5.

Glad to have done it.  Just wanted to get it right.

> You completely rewrote MTransUVPoint.  Really, what you've created is a
new
> function, not a new version of MTransUVPoint.  Your function takes
> completely different inputs and yeilds a different output.  This new
> function deserves a new name.  Do you have a suggestion?

I thought about this.  The 'M' in the name stands for matrix so that can go.
It is still a transform of the uv point into the parametric space of the
texture quadrilateral as it exists in 2d texture space.  To avoid confusion,
it might be a good idea to keep the name TransUVPoint or at least keep some
indication that it is a 2D tranformation of a point.  I'm not really sure
what the appropriate name for the mapping would be but it seems to be a
bilinear mapping.  The function uses the parametric form of the edges of the
quadrilateral and inserts the u and v parameters into the equation.  It
first finds the two U intersections along sides and then uses the line
defined by those two point to find the V intersection.  The parametric
representation of a line is:

x = x1 + t(x2-x1)
	y = y1 + t(y2-y1)

where t is the parameter.

the input is
p - uv parameters
st - four corners of quadrilateral (texture coords)
output
t - intersection

> Also, since MSquareQuad does not need to be called, we'll probably remove
> the call, but leave the function.  It is part of the general collection of
> matrix functions, so it will probably stay in case sombody needs to use it
> in the future.  Also, if Shape->Mapping is no longer used, we should
remove
> it completely.  I'm not sure if it is used anywhere else - do you know?

If you keep MSquareQuad, it might be a good idea to add a note to the effect
that it finds the projective mapping matrix and infers a perspective
mapping.  The Shape->Mapping isn't used anywhere else so yes it can be
removed completely.

> One more question:  Do you have a simple test scene that I could use for
> testing?  (Maybe with two patches with a pattern-based texture.)
Thanks!!!

Scroll to the bottom of my original post.  I included a small test scene
there with two patches and a pattern for the texture.

Post a reply to this message

"Mike Hough" <Ama### [at] aolcom> wrote...

> Recently I noticed that
> the paper I adapted the code from was interested in inferred perspective
> mapping for raster projection.  The net result is that in many cases,
> texture coordinates that should stitch smoothly at the edge of two patches
> do not do so and this problem is still present in the 3.5 beta.
>
> I've spent the entire weekend working on a fix because this is close to
> being official and think I have found a good solution.  Only 3 files need
to
> be changed.  The following is using the original code from MegaPOV.

This has been added to POV 3.5 and should be available in the next public
beta.  Thanks for your contribution.

-Nathan

Post a reply to this message