![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Most of us are aware of the phenomenon when it comes to bezier patches, and
programs like spatch, which produce 3 point patches.
That is, they always have a wrinkle in one corner, because it's actually
two corners scrunched together.
Well, The situation need not be the case!
As I understand, internally, bezier patches are converted by triangles by
simply taking grid UV samples from the bicubic patch function.
suppose, the UV samples were altered, so that instead of taking a 13 by 13
grid of samples, or 17 by 17 grid of samples as is the case now, the
algorithem could detect when two points touch, and if that is the case,
start at the edge where the two points touch, For example, if edge*1 is
actually a point, start with one sample in V=0.5 when U=0, then two samples
at V=0 and V=1 when U=1/16, then 3 samples at V=0,0.5 and 1 when U=2/16
etc.... until U=16..
In the case of a 3 point patch, this should result in no wrinkles, as in
this diagram I've prepared http://zenpsycho.com/wrinkle.gif
Perhaps this could either be implemented as a patch in povray itself, or as
a feature of Jpatch, the promising new patch modeller written in java, 3
point patches could simply be exported as a triangle mesh, using my UV
sampling scheme.
Discontinuities at the edges shouldn't be more of a problem than usual,
since each edge will have the same amount of samples as connecting 4 point
patches.
I'd try and implement this stuff myself, but I'm afraid I'm not smart
enough or have the time, but I figured that there should be a solution to
this problem that I should share.
anyways, thoughts? questions?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Rune
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 28 Jul 2003 11:24:48
Message: <3f254040@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Using a different amount of samples won't change anything I'm afraid.
You will probably just get a less detailed wrinkle instead of a highly
detailed one...
To see a discussion on making a real 3 point bezier patch, see:
http://news.povray.org/povray.advanced-users/26671/
To see it implemented (in pov-ray SDL):
http://news.povray.org/povray.text.scene-files/26676/
To see an animation where it's implemented:
http://news.povray.org/povray.binaries.animations/26690/
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Jul 25**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: sascha
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 28 Jul 2003 14:33:48
Message: <3f256c8c@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
You're right and I'm aware of this problem. I've taken two different
approaches to this problem for the next version of JPatch:
1)
Subdivide a 3-sided patch into 3 4-sided patches (like 5-sided patches
will be subdivided into 5 4-sided patches). The new patches are formed by:
* computing the center of the patch.
* deCasteljau'ing the edges
* Connecting the center with the mid-points of each edge
This works more or less for 5-point patches (I still have some minor
discontinuity problems, I think this is because the 5-point-patch is
somehow "overconstrained" and it's not clear to me how to exactly
compute the center-point - suggestions are appreciated :-)
This works too for 3-point patches which connect only to 4-point patches
but causes hughe problems when two 3-point patches meet.
2)
sPatch places two corner-points (and their tangents) at the same
position - this of course makes it impossible to calculate the surface
normal of this corner - when triangulizing the patch two triangles will
have bad normals resulting in visible artifacts (REYES is more robust
because it will subdivide until the triangles are smaller than a pixel,
but POV has problems when the u/v_steps setting is too low).
I tried to place this two corner points not on the same point but move
one slightly away - this seems to work well (no more discontinuities or
artifacts), but I'm not sure if it will make troubles with U/V mapping -
I haven't implemented u/v mapping yet so I have to try it later...
Your approach with triangulizing natively and exporting the
triangle-mesh is an option too - if you've got an implementation let me
know, I can easily integrate it into JPatch...
I'll do some tests with bezier-triangles too, but these will also have
to be exported as triangle-meshes...
-sascha
Breton Slivka wrote:
> Most of us are aware of the phenomenon when it comes to bezier patches, and
> programs like spatch, which produce 3 point patches.
>
> That is, they always have a wrinkle in one corner, because it's actually
> two corners scrunched together.
>
> Well, The situation need not be the case!
>
> As I understand, internally, bezier patches are converted by triangles by
> simply taking grid UV samples from the bicubic patch function.
>
> suppose, the UV samples were altered, so that instead of taking a 13 by 13
> grid of samples, or 17 by 17 grid of samples as is the case now, the
> algorithem could detect when two points touch, and if that is the case,
> start at the edge where the two points touch, For example, if edge*1 is
> actually a point, start with one sample in V=0.5 when U=0, then two samples
> at V=0 and V=1 when U=1/16, then 3 samples at V=0,0.5 and 1 when U=2/16
> etc.... until U=16..
>
> In the case of a 3 point patch, this should result in no wrinkles, as in
> this diagram I've prepared http://zenpsycho.com/wrinkle.gif
>
> Perhaps this could either be implemented as a patch in povray itself, or as
> a feature of Jpatch, the promising new patch modeller written in java, 3
> point patches could simply be exported as a triangle mesh, using my UV
> sampling scheme.
>
> Discontinuities at the edges shouldn't be more of a problem than usual,
> since each edge will have the same amount of samples as connecting 4 point
> patches.
>
> I'd try and implement this stuff myself, but I'm afraid I'm not smart
> enough or have the time, but I figured that there should be a solution to
> this problem that I should share.
>
> anyways, thoughts? questions?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: sascha
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 28 Jul 2003 15:34:38
Message: <3f257ace@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Btw, here are some images showing the current look of all kind of
patches (3,4,5- point and hooks) in JPatch:
http://jpatch.sourceforge.net/?page=next
There are some minor discontinuity problems with 5-point patches, but
you won't notice them unless the surface has sharp highlights or is
reflective - normal matte or diffuse surfaces look quite smooth...
-sascha
sascha wrote:
> You're right and I'm aware of this problem. I've taken two different
> approaches to this problem for the next version of JPatch:
>
> 1)
> Subdivide a 3-sided patch into 3 4-sided patches (like 5-sided patches
> will be subdivided into 5 4-sided patches). The new patches are formed by:
>
> * computing the center of the patch.
> * deCasteljau'ing the edges
> * Connecting the center with the mid-points of each edge
>
> This works more or less for 5-point patches (I still have some minor
> discontinuity problems, I think this is because the 5-point-patch is
> somehow "overconstrained" and it's not clear to me how to exactly
> compute the center-point - suggestions are appreciated :-)
> This works too for 3-point patches which connect only to 4-point patches
> but causes hughe problems when two 3-point patches meet.
>
> 2)
> sPatch places two corner-points (and their tangents) at the same
> position - this of course makes it impossible to calculate the surface
> normal of this corner - when triangulizing the patch two triangles will
> have bad normals resulting in visible artifacts (REYES is more robust
> because it will subdivide until the triangles are smaller than a pixel,
> but POV has problems when the u/v_steps setting is too low).
> I tried to place this two corner points not on the same point but move
> one slightly away - this seems to work well (no more discontinuities or
> artifacts), but I'm not sure if it will make troubles with U/V mapping -
> I haven't implemented u/v mapping yet so I have to try it later...
>
> Your approach with triangulizing natively and exporting the
> triangle-mesh is an option too - if you've got an implementation let me
> know, I can easily integrate it into JPatch...
>
> I'll do some tests with bezier-triangles too, but these will also have
> to be exported as triangle-meshes...
>
> -sascha
>
> Breton Slivka wrote:
>
>> Most of us are aware of the phenomenon when it comes to bezier
>> patches, and programs like spatch, which produce 3 point patches.
>>
>> That is, they always have a wrinkle in one corner, because it's
>> actually two corners scrunched together.
>>
>> Well, The situation need not be the case!
>>
>> As I understand, internally, bezier patches are converted by triangles
>> by simply taking grid UV samples from the bicubic patch function.
>>
>> suppose, the UV samples were altered, so that instead of taking a 13
>> by 13 grid of samples, or 17 by 17 grid of samples as is the case now,
>> the algorithem could detect when two points touch, and if that is the
>> case, start at the edge where the two points touch, For example, if
>> edge*1 is actually a point, start with one sample in V=0.5 when U=0,
>> then two samples at V=0 and V=1 when U=1/16, then 3 samples at V=0,0.5
>> and 1 when U=2/16 etc.... until U=16..
>>
>> In the case of a 3 point patch, this should result in no wrinkles, as
>> in this diagram I've prepared http://zenpsycho.com/wrinkle.gif
>>
>> Perhaps this could either be implemented as a patch in povray itself,
>> or as a feature of Jpatch, the promising new patch modeller written in
>> java, 3 point patches could simply be exported as a triangle mesh,
>> using my UV sampling scheme.
>> Discontinuities at the edges shouldn't be more of a problem than
>> usual, since each edge will have the same amount of samples as
>> connecting 4 point patches.
>> I'd try and implement this stuff myself, but I'm afraid I'm not smart
>> enough or have the time, but I figured that there should be a solution
>> to this problem that I should share.
>> anyways, thoughts? questions?
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: sascha
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 29 Jul 2003 06:04:37
Message: <3f2646b5$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>http://zhengjj.freeyellow.com/html/publications.html
>"Control point surfaces over non-four-sided surfaces"
This is really interesting, I was looking for such a paper for weeks,
thanks Rune!
The cubic version (degree 3) of both, 3- and 5-sided patches should
smoothly connect to regular 4-sided cubic bezier patches (as supported
by POV) - I'll try to implement those into JPatch.
It would be interesting if it is possible to subdivide these patches
into 3 or 5 4-sided patches respectively without loosing continuity, as
described here
http://jpatch.sourceforge.net/developer/hash_complete/hash.html
under "5-Point Patches". This is beyond my math skills, maybe someone
here can help?
If splitting the 3- and 5-sided patches into smaller 4-sided patches is
possible the modeler could export bezier-patches only (no triangels) and
thus leave the triangulation to the renderer (which would result in
smaller files and better quality because the detail level can be set at
render time).
Thanks,
-Sascha
Rune wrote:
> Using a different amount of samples won't change anything I'm afraid.
> You will probably just get a less detailed wrinkle instead of a highly
> detailed one...
>
> To see a discussion on making a real 3 point bezier patch, see:
> http://news.povray.org/povray.advanced-users/26671/
>
> To see it implemented (in pov-ray SDL):
> http://news.povray.org/povray.text.scene-files/26676/
>
> To see an animation where it's implemented:
> http://news.povray.org/povray.binaries.animations/26690/
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision: http://runevision.com **updated Jul 25**
> POV-Ray Ring: http://webring.povray.co.uk
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
sascha <sas### [at] users sourceforge net> wrote in
news:3f256c8c@news.povray.org:
> You're right and I'm aware of this problem. I've taken two different
> approaches to this problem for the next version of JPatch:
>
> 1)
> Subdivide a 3-sided patch into 3 4-sided patches (like 5-sided patches
> will be subdivided into 5 4-sided patches). The new patches are formed
> by:
>
> * computing the center of the patch.
> * deCasteljau'ing the edges
> * Connecting the center with the mid-points of each edge
>
> This works more or less for 5-point patches (I still have some minor
> discontinuity problems, I think this is because the 5-point-patch is
> somehow "overconstrained" and it's not clear to me how to exactly
> compute the center-point - suggestions are appreciated :-)
> This works too for 3-point patches which connect only to 4-point
> patches but causes hughe problems when two 3-point patches meet.
>
This is a vague idea, from a vague understanding, and you're probably
already way ahead of me on this...
as I understand it, it is a fairly simple matter to subdivide a 4 point
patch into two 4 point patches, by just substituting boundary points,
with control points, and interpolating intermediate control points.
(Which in itself would be a nice feature in a patch model, to arbitrarily
subdivide a patch)
Anyways, with the paper on 3 5 and 6 sided patches, you are provided with
mathematical definitions (A bit hard to swallow) for 3 and 5 points
patches, along with patterns for control points.
Couldn't the same principle for subdividing 4 point patches into 2 4
point patches be applied here? You could start with a 5 point patch
definition, and then subdivide into 5 4-point patches by substituting
control points in the 5 point patch definition into boundary edges for
new 4 point patches, and interpolate the individual control points in the
same manner you would when subdividing a 4 point patch?
Stop me if this all sounds stupid, or obvious...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: sascha
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 30 Jul 2003 03:29:03
Message: <3f2773bf@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Breton Slivka wrote:
> This is a vague idea, from a vague understanding, and you're probably
> already way ahead of me on this...
>
> as I understand it, it is a fairly simple matter to subdivide a 4 point
> patch into two 4 point patches, by just substituting boundary points,
> with control points, and interpolating intermediate control points.
> (Which in itself would be a nice feature in a patch model, to arbitrarily
> subdivide a patch)
>
> Anyways, with the paper on 3 5 and 6 sided patches, you are provided with
> mathematical definitions (A bit hard to swallow) for 3 and 5 points
> patches, along with patterns for control points.
>
> Couldn't the same principle for subdividing 4 point patches into 2 4
> point patches be applied here? You could start with a 5 point patch
> definition, and then subdivide into 5 4-point patches by substituting
> control points in the 5 point patch definition into boundary edges for
> new 4 point patches, and interpolate the individual control points in the
> same manner you would when subdividing a 4 point patch?
>
> Stop me if this all sounds stupid, or obvious...
Let's use the five-point patch as an exaple. I'd like to subdivid it in
a way where a center (of the patch) connects to the center of each
edge-curve-segment - this way I'll get 5 4-sided patches (see the paper
by Martin Hash I mentioned in my previous porting for a diagram).
Subdividing the edge-bezier-curves is a simple de Casteljau operation -
I've had some problems with finding the patch center, put the paper
posted by Rune has the solution for that (at least I think so). The only
problem that needs to be solved is finding the control-points for the 5
new curves that origin from the center. And - all in all - I'm not sure
that those five new patches will connect 100 percent smoothly.
All I can do is playing around with patches by trail and error, but it
would be better to have a sort of a mathematical proove, but that's
beyond my means...
-sascha
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
sascha <sas### [at] users sourceforge net> wrote in
news:3f2773bf@news.povray.org:
I've been playing around with bezier curves and math, and after some
thinking, I think I may have found a solution.
However it seems kind of obvious so I wonder if I'm missing something.
Understanding that C1 continuity is defined that 3 control points, that is
the two curve control points, and the two connecting points (one point)
they surround, must all lie on the same tangent line.
Applying this to the 5 point patch structure (contructed of 4 point
patches) I came across these findings:
#1. The center point, and the 10 control points that immediately surround
it, must all lie on the same plane, due to the fact that under the
constraint mentioned above, their positions all become interdependant.
#2. the center point must lie on the intersection of lines drawn between
its 10 surrounding points. Consequently, lines drawn between these 10
surrounding control points must all intersect at a single point.
For the bezier lines eminating from the center point you said you were
having trouble with, this takes care of 2 control points on each.
The rest of the relationships are difficult to explain verbally, so I shall
give you a diagram I made, where green lines are drawn between points that
must lie on the same line for continuity.
http://zenpsycho.com/images/pentdiag.gif
what remains is the problem of continuity with adjacent patches, due to the
fact that each edge now has 7 points, which must seamlessly connect with a
patch with 4 control points, and also, the center control point on each
edge must lie on the same line as its surrounding two edge points. I wonder
if this is mathematical conflict, or if it can be solved.
If I'm incorrect about any of this, let me know, I love learning about this
stuff.
Thanks
> Let's use the five-point patch as an exaple. I'd like to subdivid it
> in a way where a center (of the patch) connects to the center of each
> edge-curve-segment - this way I'll get 5 4-sided patches (see the
> paper by Martin Hash I mentioned in my previous porting for a
> diagram).
>
> Subdividing the edge-bezier-curves is a simple de Casteljau operation
> - I've had some problems with finding the patch center, put the paper
> posted by Rune has the solution for that (at least I think so). The
> only problem that needs to be solved is finding the control-points for
> the 5 new curves that origin from the center. And - all in all - I'm
> not sure that those five new patches will connect 100 percent
> smoothly.
>
> All I can do is playing around with patches by trail and error, but it
> would be better to have a sort of a mathematical proove, but that's
> beyond my means...
>
> -sascha
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> what remains is the problem of continuity with adjacent patches, due
> to the fact that each edge now has 7 points, which must seamlessly
> connect with a patch with 4 control points, and also, the center
> control point on each edge must lie on the same line as its
> surrounding two edge points. I wonder if this is mathematical
> conflict, or if it can be solved.
>
Hold on, I see my mistake regarding the edges, disregard that comment.
I shall investigate this further,
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: sascha
Subject: Re: Wrinkle free 3 point patch -or- Jpatch anticipation
Date: 4 Aug 2003 10:53:08
Message: <3f2e7354$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Breton Slivka wrote:
> what remains is the problem of continuity with adjacent patches, due
to the
> fact that each edge now has 7 points, which must seamlessly connect
with a
> patch with 4 control points, and also, the center control point on each
> edge must lie on the same line as its surrounding two edge points. I
wonder
> if this is mathematical conflict, or if it can be solved.
That's easy, the only thing you need is the so called de Casteljau
algorithm (e.g. http://users3.ev1.net/~charlesliu/graphics/bez/alg.html )
I will prepare some screenshots that show how I subdivided the
five-point-patch and where the problems are.
-sascha
> sascha <sas### [at] users sourceforge net> wrote in
> news:3f2773bf@news.povray.org:
>
> I've been playing around with bezier curves and math, and after some
> thinking, I think I may have found a solution.
>
> However it seems kind of obvious so I wonder if I'm missing something.
>
> Understanding that C1 continuity is defined that 3 control points, that is
> the two curve control points, and the two connecting points (one point)
> they surround, must all lie on the same tangent line.
>
> Applying this to the 5 point patch structure (contructed of 4 point
> patches) I came across these findings:
>
> #1. The center point, and the 10 control points that immediately surround
> it, must all lie on the same plane, due to the fact that under the
> constraint mentioned above, their positions all become interdependant.
>
> #2. the center point must lie on the intersection of lines drawn between
> its 10 surrounding points. Consequently, lines drawn between these 10
> surrounding control points must all intersect at a single point.
>
> For the bezier lines eminating from the center point you said you were
> having trouble with, this takes care of 2 control points on each.
>
> The rest of the relationships are difficult to explain verbally, so I shall
> give you a diagram I made, where green lines are drawn between points that
> must lie on the same line for continuity.
>
> http://zenpsycho.com/images/pentdiag.gif
>
>
>
> what remains is the problem of continuity with adjacent patches, due to the
> fact that each edge now has 7 points, which must seamlessly connect with a
> patch with 4 control points, and also, the center control point on each
> edge must lie on the same line as its surrounding two edge points. I wonder
> if this is mathematical conflict, or if it can be solved.
>
>
> If I'm incorrect about any of this, let me know, I love learning about this
> stuff.
>
> Thanks
>
>
>
>
>
>
>>Let's use the five-point patch as an exaple. I'd like to subdivid it
>>in a way where a center (of the patch) connects to the center of each
>>edge-curve-segment - this way I'll get 5 4-sided patches (see the
>>paper by Martin Hash I mentioned in my previous porting for a
>>diagram).
>>
>>Subdividing the edge-bezier-curves is a simple de Casteljau operation
>>- I've had some problems with finding the patch center, put the paper
>>posted by Rune has the solution for that (at least I think so). The
>>only problem that needs to be solved is finding the control-points for
>>the 5 new curves that origin from the center. And - all in all - I'm
>>not sure that those five new patches will connect 100 percent
>>smoothly.
>>
>>All I can do is playing around with patches by trail and error, but it
>>would be better to have a sort of a mathematical proove, but that's
>>beyond my means...
>>
>>-sascha
>>
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |