|
 |
I started using UV-POV a few months ago when I did my "From the desk of
F. Mulder" image (posted to p.b.i.) primarily because I wanted to uv map
text on to slightly curved patches rather than a flat box for the pieces
of paper. I managed to get it to work with a single bicubic_patch but
until recently I hadn't done any multiple patches. Here's what I found
out, maybe it will help someone else.
I create all my patches by hand so that they are lying in the xz plane.
It makes a difference in which order the points appear. I chose to make
the code look something like the patch itself. i.e. the first listed
line of points actually represents the four control points of the patch
that are furthest from <0,0,0> and the bottom line is the control points
that actually start at <0,0,0>.
Example:
bicubic_patch{
type 1
flatness 0
u_steps 3
v_steps 3
uv_vectors <.666,0>,<1,.5> //Lower Left Patch
<0,0,1><.333,0,1><.666,0,1><1,0,1>
<0,0,.666><.333,0,.666><.666,0,.666><1,0,.666>
<0,0,.333><.333,0,.333><.666,0,.333><1,0,.333>
<0,0,0><.333,0,0><.666,0,0><1,0,0>
uv_mapping
}
This patch would be part of a union{} with an overall texture using an
image_map, like this:
pigment{image_map{
tga
"f16hl.tga"
once
interpolate 2
}
rotate z*90 translate x*1
}
The rotate and translate statements are necessary to align the image
properly. I don't know why, but I assume it has something to do with
the internals of how the patch is stored. This may be a case where I'm
making things harder for myself; perhaps if I defined the patch in the
xy or yz planes the image would line up properly without the
transformations, but I haven't tried it becuase I find the way I'm using
easier to visualize.
I create the other patches in a similar manner, just adjusting the
control points values so that the patches lie side by side.
I found, through trial and error, that the uv_vectors work as follows:
The u-vector has its 0 point at the far z-end of the patch and increases
as it moves in a negative z direction.
The v-vector starts at the lower left of the patch (as least as my
patches are defined) and increases as it moves in a positve x direction.
(crappy diagram follows)
0 ^
| |
| z
u x->
|
|
1
0---v---1
If you keep in mind that this 0 to 1 range covers all the patches
regardless of how many there are, it becomes easy to figure out the
uv-vectors for any rectangle of patches in the xz plane.
For example, a union with 6 patches (2 in the x direction and 3 in z
direction) would use the following uv_vectors statments assuming you are
looking down on the patch as it lies in the xz plane:
<0,0>,<.333,.5> <0,.5>,<.333,1>
<.333,0>,<.666,.5> <.333,.5>,<.666,1>
<.666,0>,<1,.5> <.666,.5>,<1,1>
Even though the docs say something how it doesn't matter if
transformations are applied before or after the the texture is put on, I
found that I need to scale the patches before applying the image_map to
correct the aspect ratio. For example, with a 3 by 2 grid of unit-size
patches as shown above I need to scale them with scale<2,1,1> before
applying a 640x480 pixel image_map.
Mike Wilson
Phil Clute wrote:
>
> I found a thread on this before but I can't seem to find it twice...
>
> I am trying to apply 1 image_map to 45 bicubic_patches but I am getting
> 45 image_maps applied to each bicubic_patch, some are even turned in the
> wrong direction.
> In the thread I can't seem to find now, Nathan mentioned using
> uv_vectors
> to correct this. But I'm not sure how this works. I tried fiddling with
> it
> but didn't notice any changes.
> I suppose I could try breaking up the image_map into several pieces and
> apply them individually to each patch but I'd rather learn how
> uv_vectors
> works.
>
> For those who are curious I'm making a flag.
>
> TIA
> --
> Phil
> ...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
