 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks Ron, this clarifys a lot.
Let me recapitulate to be sure I understood. Instead of imagining a Bpatch as a
set of triangles, it can be seen as a grid of bezier-splines. To stitch two
patches together you have to make sure that the controllpoints on each side of a
node are in one line (like making a smooth prism object with bezier spline).
So to make my object, I have to generate a few smooth "circular" bezier splines
and a set of smooth splines "standing upright". Make a cylindrical grid with
these splines in sutch a way that the endpoints of the spline segements
intersect (the O's in your ascii art). And so on for the X's and #'s. I'll have
a look at your inc file later tonight (bad connection:(
ingo
--
Met dank aan de muze met het glazen oog.
Ron Parker heeft geschreven in bericht <3720d6ef.0@news.povray.org>...
>......
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow, it looks so easy, but sure gives me something to think about and play with
this weekend.
Thank you Ron, have a nice weekend,
ingo
--
Met dank aan de muze met het glazen oog.
Ron Parker heeft geschreven in bericht <3720dadb.0@news.povray.org>...
>On Fri, 23 Apr 1999 21:48:09 +0200, ingo <ing### [at] ingo demonnl> wrote:
>>To get an idea of what I'm trying run the included
>
>Okay, so now I'm assuming you've just read my tutorial on patches.
>Here's the result of the tutorial as applied to your scene. Take
>note of the comments I've added.
>.........
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I posted a similar question in the newusers group and Ken
directed me over here(thanks Ken). I don't usually view the
advanced group, as I am not a jedi yet. But I'm working on it.
Anyhow my question is: What is the math behind keeping those
seams together, and from causing cracks in the patch?
The reason I ask is because I wanted to try animating the patches.
The ultimate goal is to make a face that can change expressions etc.
But I'll settle for just a couple patches working in harmony for
now.
Note: I originally posted this question in newusers because I'm
slightly math impared. So go easy on me...<he he>
--
...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just a side note:
Morphing from one patch(group) to another might be possible with a (near)
future version of the Colefax's PCM macro. He is working on it.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Apr 1999 13:38:03 -0400, Phil Clute <plc### [at] tiacnet> wrote:
>Anyhow my question is: What is the math behind keeping those
>seams together, and from causing cracks in the patch?
I find that it helps to look at a collection of connected patches as
a solid mesh composed of quadrilateral (four-sided) elements, rather
than as a bunch of independent patches. In my bedsheet code, I used
a whopping big array to store the control points for all of the
patches.
If you look at that code, you'll see a lot of 3's but not very many
4's. This might seem strange: after all, patches have a 4 x 4 array
of control points, right? So if you were going to have an n x n mesh
of patches, you would need a 4n x 4n array, right? No. You need a
(3n+1) x (3n+1) array. Why? Because to keep from having cracks in
your mesh, you must ensure that all of the points (four altogether)
on the boundary between two patches are the same for both patches.
Here's an ugly ASCII-art representation of a 2 x 1 mesh of patches:
0 1 2 3 4 5 6
0 O---O---O---O---O---O---O
| | |
| | |
1 O O O O O O O
| | |
| | |
2 O O O O O O O
| | |
| | |
3 O---O---O---O---O---O---O
(figure 1)
The lines mark patch boundaries. The O's are control points. The
numbers above and to the side are the indices of the points in the
array. Notice how every control point in column 3 is in both patches.
As long as you adhere to this model, you can never have a crack in
your patch mesh.
Now, let's draw that picture again, but with a 2 x 2 mesh:
A###B...B###A###B...B###A
# | | # | | #
# | | # | | #
B---C C---B---C C---B
. . .
. . .
B---C C---B---C C---B
# | | # | | #
# | | # | | #
A###B...B###A###B...B###A
# | | # | | #
# | | # | | #
B---C C---B---C C---B
. . .
. . .
B---C C---B---C C---B
# | | # | | #
# | | # | | #
A###B...B###A###B...B###A
(figure 2)
This is a little more complicated, because it's trying to get across
a more complicated point (I should really write this thing up as a web
page and put fancy graphics on it!)
The # signs are patch boundaries. So are the dots. The A's, B's,
and C's are control points. The other lines mean something else.
A points are the corners. It's already been noted that a patch will
always intersect its corner points. B points are the remaining edge
points. They exert an influence on the slope of the patch at the
adjacent A point. For the sake of discussion, these 'lines of
influence' are represented by the # signs. The dots are just there
to show the patch boundaries.
C points are the interior points. Each of them exerts an influence on
the slope of the patch at two undetermined points along the edge of the
patch, roughly corresponding to the adjacent B points.
Now, the payoff: if you want your patches to abut smoothly, without a
visible crease at the edges, all you have to do is make sure that
anywhere you see three control points joined by a straight line,
which is to say a line of #'s, -'s, or |'s but not a line of dots,
all of those control points must be in a straight line in 3D space.
This means that if you drew lines between their locations in 3D space,
you would not get a triangle but a straight line.
So, reverse your thinking about patches. They're not a 4 x 4 mesh of
control points, or even a 3 x 3 mesh of 'grid squares'. A patch mesh
consists of a grid of vertex points, represented by the points marked
'A' in figure 2. Each vertex point in the grid is surrounded by a
cloud of up to eight control points that determine the shape of the
surface at that point. The points marked 'B' in figure 2 directly
determine the normal of the surface at the vertex, while the points
marked 'C' have a more indirect effect, specifying the evolution of
the surface as you move away from the vertex point in each direction.
There's something I haven't addressed in this discussion. How do
you deal with a situation where your patches are not in a regular
grid, as shown below:
+----------+----------+
| # |
| # B |
| # |
| A *----------+
| # |
| # C |
| # |
+----------+----------+
My simplistic answer is "Don't do that!" It might be possible to
figure out the correct control points for patch A to make it pass
through the vertex marked *, but it'll be really hard to keep from
having a crack somewhere along the joint indicated with # signs.
Yes, it can be done. It will put severe constraints on the edges
of the B and C patches that abut the A patch. But the math is
almost certainly quite nasty, and you'd probably be better off just
splitting patch A in half. If someone has some foolproof math for
this case, I'd like to see it too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Apr 1999 13:38:03 -0400, Phil Clute <plc### [at] tiacnet>
wrote:
>Anyhow my question is: What is the math behind keeping those
>seams together, and from causing cracks in the patch?
>
>The reason I ask is because I wanted to try animating the patches.
>The ultimate goal is to make a face that can change expressions etc.
>But I'll settle for just a couple patches working in harmony for
>now.
Just to amplify a bit or Ron Parker's answer.
Suppose that the edge in question and the adjacent control points in
each patch are as follows:
--a-----e e-----i--
| | | |
| | | |
--b-----f f------j--
| | | |
| | | |
--c-----g g-----k--
| | | |
| | | |
--d-----h h-----l--
Then a, e and i must be collinear. So must b, f and j, c, g and k,
and d, g and ii. This can sometimes constrain a surface too much, so
there is an alternative method of guaranteeing some continuity. In
this case, the constraints are that a, e, i and f must be coplanar and
d, h, l and g must be coplanar and in this case b, c, j and k need not
be collinear with anything.
For what you describe yourself as wanting to do, you might want to
look into hierarchical b-splines, also known as h-splines. As b
splines, the interpatch continuity is automatic. B splines can also
be converted to beziers (so-called bicubic patches) with some
appropriate matrix math, but the process would probably not be
practical for speed and memory reasons without an external converter
or a patched pov that supports them directly.
If you want to see some examples of h spline techniques, check out the
Dragon Wing at:
http://www.cs.ubc.ca/nest/imager/contributions/forsey/dragon/top.html
Jerry Anning
clem "at" dhol "dot" com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the help!
I can see I'm in over my head a bit though...
if nothing else I've learned something for future
attempts.
Jerry Anning posted(in this thread)a pretty cool
link about hierarchical b-splines. I wandered around
there for a long time. The face animations are worth
the short download.
--
...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
If you want to see some examples of h spline techniques, check out the
Dragon Wing at:
http://www.cs.ubc.ca/nest/imager/contributions/forsey/dragon/top.html
This link has some great stuff. The dissapointment was that I
was looking around to see if a program was available but I didn't
see one there <boo, hiss>.
The animations function well, that's definitely the idea I had in mind
as an ultimate goal(somewhere waaay down the road).
thanks
--
...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
>
> While exploring the bezier patches, I can not find a way to attatch two, non
> flat, patches without a seam. To get an idea of what I'm trying run the included
> scene.
>
> Have been looking at the output of sPatch, but I'm still clueless.
>
> ingo
> --
In October last year Vidar Maddsen asked something similiar. I created a
small scene where I attached two patches.
The most important thing to understand is that only the four cornerpoint
represent positions of the patch while the rest tells where the 'curve
(spline)' is heading to. In order to get a seamless connection all four
points of seam have to be the same for both patches. In the follwing
example this are the last line of the blue and the first line of the red
patch.
I hopt this one helps:
camera {
rotate <0,180,0>
location <7,5,3>
look_at <1.5,0,3>
angle 60
}
light_source { <1.5,9,1.5> color rgb <1.0.0>}
plane {y,-4 pigment {checker rgb<1,1,1>, rgb <0.5,0.5,0.5>}}
//blue patch
bicubic_patch {
type 1
flatness 0.01
u_steps 10
v_steps 10
<0.0, 0.0, 0.0>, <0.0, 0.5, 0.0>, <3.0, 0.5, 0.0>, <3.0, 0.0, 0.0>,
<0.0, 0.5, 1.0>, <0.0, 3.0, 1.0>, <3.0, 3.0, 1.0>, <3.0, 0.5, 1.0>,
<0.0, 0.5, 2.0>, <0.0, 3.0, 2.0>, <3.0, 3.0, 2.0>, <3.0, 0.5, 2.0>,
<0.0, 0.0, 3.0>, <0.0, 0.5, 3.0>, <3.0, 0.5, 3.0>, <3.0, 0.0, 3.0> //
<-+
pigment {color rgb <0,0,1> } // |
} // |s
// |a
// |m
//red patch // |e
bicubic_patch { // | type 1 // |l
flatness 0.01 // |i
u_steps 10 // |n
v_steps 10 // |e
<0.0, 0.0, 3.0>, <0.0, 0.5, 3.0>, <3.0, 0.5, 3.0>, <3.0, 0.0, 3.0>, //
<-+
<0.0, -0.5, 4.0>, <0.0, -2.0, 4.0>, <3.0, -2.0, 4.0>, <3.0, -0.5,
4.0>,
<0.0, -0.5, 5.0>, <0.0, -2.0, 5.0>, <3.0, -2.0, 5.0>, <3.0, -0.5,
5.0>,
<0.0, 0.0, 6.0>, <0.0, 0.5, 6.0>, <3.0, 0.5, 6.0>, <3.0, 0.0, 6.0>
pigment {color rgb <1,0,0> }
}
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Arghh, I messed it up while editing, but I'm sure you can fix it! :-)
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
