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

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

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

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

>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

sascha <sas### [at] userssourceforgenet> 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

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

sascha <sas### [at] userssourceforgenet> 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

> 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

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] userssourceforgenet> 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