4-sided bezier patches alone simply don't work for irregular topology.
Therefore, the shapes that can be created with just 4-sides bezier
patches are very limited, which is a shame, since bezier patches are
otherwise very flexible and useful shapes...

I've wanted 3, 5 and 6-sided bezier patches for a looong time, and
occasionally tried to figure out a way to implement them (as a macro
generating a mesh, not as a patch.) However, it's not very easy to come
up with the right method, and I have not succeeded at that.

Then, when searching the net for the topic, I found this page:
http://zhengjj.freeyellow.com/html/publications.html

Now that's interesting! The publication "Control point surfaces over
non-four-sided surfaces" explain exactly how to implement 3, 5 and
6-sided bezier patches! Unfortunately I'm not able to comprehend all
those formulas that they use, and thus I won't be able to implement it
myself, neither as a patch nor as macros.

But it is my hope that someone else here will implement it, actually
preferably as macros. The thing is that I have plans to create a system
to make modeling with bezier patches easier, and for the features I'm
planning, I'd need the capability to modify how the patches work.

I hope that one of you great POVers with abilities to read and
understand scientific papers will create some macros based on the
above-mentioned papers. I'm aware that the syntax for an n-sided bezier
patch would be much more confusing (code-wise, visually) than that of a
4-sided bezier patch, but it doesn't matter so much, since it's my
intention to create macros that take care of calculating the control
points for the bezier patches.

Anybody up for the challenge?

By the way, note that this is very high on my wish-list. I would happily
give up features such as isosurfaces and photon mapping in exchange for
n-sided bicubic patches. That's because I'm into character design and
animation, but I know that many others have different priorities...

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Here we go. I just had a quick look at the paper and used the formula from 
the 3-sided beziers. First I implemented it as parametric surface which 
more or less worked but is slow as hell. But from that it was not too hard 
to create a version that produces a mesh. It could be extended to generate 
smoot_triangles.

You can find both versions in p.t.s-f. Hope it works as intended. If so, 
tell me and I will try the 5 and 6 sided as well.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

I had only read the first two pages of the paper before writing the macros. 
Now I realize that there are different version with different numbers of 
control points. You probably prefer those with 4 control points on each 
side as the can be combined with pov's bicubic patches, right?

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Micha Riser wrote:
> I had only read the first two pages of the paper
> before writing the macros. Now I realize that
> there are different version with different numbers
> of control points. You probably prefer those with
> 4 control points on each side as the can be
> combined with pov's bicubic patches, right?

Right.

I'll still have a look at the code you already posted, but I probably
won't be able to modify it to "degree 3" as they call it when there's
four control points per side. So if you have any success at implementing
the version with 4 control points, it would be great. I really
appreciate your efforts!

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> won't be able to modify it to "degree 3" as they call it when there's
> four control points per side. So if you have any success at implementing
> the version with 4 control points, it would be great. I really
> appreciate your efforts!

Ok, I have worked futher through the paper. I have a version with 3 sides 
and degree 3 working now and could provide higher degrees but I don't think 
this would be useful (or?). I used formulas 3.1-3.5 for m=3. I am not sure 
about the 'normalisation property' (2.5). As far as I see my current 
implementation does not hold this. (what will this have for consequences?)

I have added support for generating smooth triangles. I think this shape 
could be used for subdividing smooth triangles. Can you tell me what the 
conditions are for joining triangluar patches smootly?

Please test the macros and try to join some patchs smootly.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Micha Riser wrote:
> I have a version with 3 sides and degree 3 working
> now and could provide higher degrees but I don't
> think this would be useful (or?).

Thank you very much. This is perfect so far! :)

Degree 3 is all I need.

> I used formulas 3.1-3.5 for m=3. I am not sure
> about the 'normalisation property' (2.5). As far
> as I see my current implementation does not hold
> this. (what will this have for consequences?)

I don't know. The patch looks very nice in the one test scene I've made
so far.

> I have added support for generating smooth triangles.

It looks perfect!

> I think this shape could be used for subdividing
> smooth triangles.

I'm not sure about that. See below.

> Can you tell me what the conditions are for
> joining triangluar patches smootly?

Well, the triangular patches are meant to fill in the holes between the
regular rectangular patches. I don't think you can create smooth
surfaces consisting entirely of triangular patches. The reason is this:
At the corner points, there should be always exactly four patches
meeting, no matter how many sides each of those patches have. For
example three rectangular patches and one triangular patch.

You could make a sphere-like shape out of just eight triangular patches,
but I think that's about it...

> Please test the macros and try to join some patchs smootly.

Yes, see the animation in p.b.a and the source code in p.t.s-f

If there could also be UV mapping, it would be great. This should be
based on three UV vectors specified by the user (one for each corner).
Of course that means that the macro need to generate a mesh2.

I'm also highly interested in the patches with 5 and 6 edges, as the one
with 3 edges proved to work perfectly... :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> Thank you very much. This is perfect so far! :)

Great! :)
 
>> I used formulas 3.1-3.5 for m=3. I am not sure
>> about the 'normalisation property' (2.5). As far
>> as I see my current implementation does not hold
>> this. (what will this have for consequences?)
> 
> I don't know. The patch looks very nice in the one test scene I've made
> so far.

Tell me if you encouter problems which could be related to this.

> 
>> Can you tell me what the conditions are for
>> joining triangluar patches smootly?
> 
> Well, the triangular patches are meant to fill in the holes between the
> regular rectangular patches. I don't think you can create smooth
> surfaces consisting entirely of triangular patches. The reason is this:
> At the corner points, there should be always exactly four patches
> meeting, no matter how many sides each of those patches have. For
> example three rectangular patches and one triangular patch.

Hmm.. ok, but I am still trying to figure out which control points have to 
lie on a line to make a smooth join.

> 
> Yes, see the animation in p.b.a and the source code in p.t.s-f

Looks cool.

> 
> If there could also be UV mapping, it would be great. This should be
> based on three UV vectors specified by the user (one for each corner).
> Of course that means that the macro need to generate a mesh2.

I do not know much about uv-mapping. Never used it so far. But maybe 
someone else can add support for it.

> 
> I'm also highly interested in the patches with 5 and 6 edges, as the one
> with 3 edges proved to work perfectly... :)

Just gimme some time..

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Micha Riser wrote:
> Tell me if you encouter problems which could be
> related to this.

To be honest, I have no clue what "normalization property" even means.
But I'll let you know if the patches behave unexpected in any ways.

> Hmm.. ok, but I am still trying to figure out
> which control points have to lie on a line to
> make a smooth join.

It's the same way as for the regular bicubic patches. If you can figure
out how to make a join, just not a smooth join, then it's only the three
inner points that you need to adjust. These should be handled the same
way as the four inner points in a regular rectangular bicubic patch.

If needed, I can post an illustration to povray.binaries.images.

> I do not know much about uv-mapping. Never used it so far.
> But maybe someone else can add support for it.

Well, I can try to see if I can figure out your code enough to implement
UV mapping, but don't count on it... ;)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> Well, I can try to see if I can figure out your
> code enough to implement UV mapping, but don't
> count on it... ;)

Actually, uv-mapping should be easy to make, as the whole patch seems to
be based on uv coordinates in the first place. Well, the tricky part is
to write the triangles as a mesh2 rather than a regular mesh.

When writing the patch as a mesh2, the vertices have to come in a
logical order. The subdivision algorithm doesn't calculate the vertices
in a very intuitive order, but I've found out that the subdivision
approach isn't needed at all - the triangles can be made in a simple
double loop. This also means that the number of triangles per edge is
not limited to a power of two, but can be any number.

Writing the patch as a mesh2 will also cut down the number of
calculations to one sixth, as each vertex and normal is shared by six
triangles, which is taken advantage of in the mesh2 object.

I have not yet written the actual code, but I'll report back again when
it's done.

By the way - even though I can modify a few aspects of the code, I still
have no clue about the math behind it and the functions used, so I won't
be able to make the 5 and 6 sided patches myself. I'm still looking
forward to get my hands on those. :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:

> Actually, uv-mapping should be easy to make, as the whole patch seems to
> be based on uv coordinates in the first place. 

That's true. There is also w which is dependant of u and v.

> Well, the tricky part is
> to write the triangles as a mesh2 rather than a regular mesh.

mesh support uv_mapping as well. So you can add support for uv_mapping when 
you add 'uv_vectors uv1,uv2,uv3' in the triangle and smooth_triangle 
definition (just after all points, this is about line 50 and 57). 

However you have to see that not the whole uv space from <0,0> to <1,1> is 
mapped onto the triangle but only half of it! 

> 
> When writing the patch as a mesh2, the vertices have to come in a
> logical order. The subdivision algorithm doesn't calculate the vertices
> in a very intuitive order, but I've found out that the subdivision
> approach isn't needed at all - the triangles can be made in a simple
> double loop. This also means that the number of triangles per edge is
> not limited to a power of two, but can be any number.

I do not really see an easy non-recursive way that does an equally sized 
subdivison. 

> 
> By the way - even though I can modify a few aspects of the code, I still
> have no clue about the math behind it and the functions used, so I won't
> be able to make the 5 and 6 sided patches myself. I'm still looking
> forward to get my hands on those. :)
> 

I'll try 5 and 6 sided as well. But these formulas probalby are quite a bit 
messy.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message