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

Micha Riser wrote:
> mesh support uv_mapping as well.

I had forgotten that. However, I still want to use mesh2, because it
cuts down the number of calculations to one sixth. That's quite a big
difference.

> 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!

Yes. :)

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

I just saw now that the method I used doesn't create an even
distribution. The triangles are a bit bigger towards one of the sides,
probably the w one (even though the control points are the same for the
three sides). However, when looking at your method, it produces the
exact same result, which is also not evenly distributed. Perhaps this is
related to the 'normalisation property'?

If that is the case, making the implementation hold the normalisation
property would be important for UV mapping (and of course it's also
nicest in general if the triangles are evenly distributed). However, at
least the uneven distribution doesn't affect the joining of patches,
since it doesn't affect the edges of the patch.

I'll post some code to povray.binaries.scene-files which shows how to
use a double loop to generate the triangles, and which also show the
uneven distribution clearly (both with the subdivision and the double
loop approach).

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

I can imagine. I hope you manage to implement them anyway.

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:

> Micha Riser wrote:
>> mesh support uv_mapping as well.
> 
> I had forgotten that. However, I still want to use mesh2, because it
> cuts down the number of calculations to one sixth. That's quite a big
> difference.

I have modified my recurisve version so that it passes the points along, so 
that all points/normals are calculated only once (has the side effect that 
normals are calculated even with non-smooth, but this could be changed as 
well).

>> 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!
> 
> Yes. :)

But here it the problem. We just use two of the three symmetric vectors 
u,v,w for the mapping. This means that in uv-space two sides of the 
triangle have size 1 but the third has length sqrt(2)!

> I just saw now that the method I used doesn't create an even
> distribution. The triangles are a bit bigger towards one of the sides,
> probably the w one (even though the control points are the same for the
> three sides). However, when looking at your method, it produces the
> exact same result, which is also not evenly distributed. Perhaps this is
> related to the 'normalisation property'?

No, I have modified it to hold the 'normalisation property'. There is a 
change but hardly noticeable. I have also added uv-mapping and the example 
shows the problem with it: the w-side (where w=0) crosses uv-space from 
<0,0> to <1,1>.

New version in p.b.s-f.
 
> --
> 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

If you'd use '-- ' as signature separator I would not be tempted to quote 
your signature as my news reader would recognise it as signature then and 
automatically cut aways on replying.

- Micha

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

Post a reply to this message

Micha Riser wrote:
> I have modified my recurisve version so that it passes
> the points along, so that all points/normals are
> calculated only once (has the side effect that normals
> are calculated even with non-smooth, but this could be
> changed as well).

That's a big improvement then. But since mesh2 objects are still much
smaller in size, I still think I'll try to make it into a mesh2. It's
not in a big hurry now though, so I'll wait little with that until more
important issues have been solved.

> But here it the problem. We just use two of the
> three symmetric vectors u,v,w for the mapping.
> This means that in uv-space two sides of the
> triangle have size 1 but the third has length
> sqrt(2)!

No, that's just because of the UV vectors you used. You didn't add
support for custom UV vectors, but simply used <0,0>, <1,0> and <0,1>.
With custom UV vectors each side could have any length you want.

The real problem is that the distribution of the triangles is (still)
not even. Apparently it's not related to the normalisation property
then, because I can't see any difference from before.

If, instead of applying UV mapping, you color the individual triangles
individually (like in the version I posted), you will see that at the
third edge the triangles are (still) bigger than at the other edges. I
suppose you don't know how that can be fixed? :/

> If you'd use '-- ' as signature separator

Outlook Express' fault. But I really thought that the program
OE-QuoteFix was supposed to take care of this problem. Maybe it
doesn't... :(

By the way, should the third character be a regular space, or some
different character that looks the same way as a regular space (if such
a thing exists)?

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:
> The real problem is that the distribution of the
> triangles is (still) not even. Apparently it's
> not related to the normalisation property then,
> because I can't see any difference from before.
>
> If, instead of applying UV mapping, you color the
> individual triangles individually (like in the
> version I posted), you will see that at the third
> edge the triangles are (still) bigger than at the
> other edges. I suppose you don't know how that
> can be fixed? :/

Hmm, I found the solution. Change the value of epsilon1 from 0.001 to
1.0. I don't know why, but it fixes the distortion and makes the
distribution completely even. :)

As I assumed, it was something with how the w value was calculated.
Apparently, if 1-2*u*v is smaller than 1.0, then no division should
happen at all (or a division by 1). I found out by coincidence more or
less, so don't ask me why...

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:
> 
>> But here it the problem. We just use two of the
>> three symmetric vectors u,v,w for the mapping.
>> This means that in uv-space two sides of the
>> triangle have size 1 but the third has length
>> sqrt(2)!
> 
> No, that's just because of the UV vectors you used. You didn't add
> support for custom UV vectors, but simply used <0,0>, <1,0> and <0,1>.
> With custom UV vectors each side could have any length you want.
> 
> The real problem is that the distribution of the triangles is (still)
> not even. Apparently it's not related to the normalisation property
> then, because I can't see any difference from before.

In uv-space the triangles are ditributed even. If you make patch that has 
the shape of an isosceles , rectangulare triangle then you will 
see that all triangles are of (nearly) same size (because uv-space has the 
same distances as realspace). Try:

 object{ bezier3triangles( 
                 <0,0,0>,<1/3,0,1/3>,<2/3,0,2/3>,  // under line 
                 <1,0,1>,<2/3,0,1>,<1/3,0,1>,  // right line 
                 <0,0,1>,<0,0,2/3>,<0,0,1/3>, // left line 
                 <0.25,0,0.4>,<0.6,0,0.8>,<0.2,0,0.8> // inner points
                 ,5,1,0) // depth, smoothing, enable visible control points
        texture{uv_mapping pigment{checker Red, Green scale .1}}
        }

Now imagine this rectangular triangle being transformed into a equilateral 
one.. the result is what you see in your example.

> 
> If, instead of applying UV mapping, you color the individual triangles
> individually (like in the version I posted), you will see that at the
> third edge the triangles are (still) bigger than at the other edges. I
> suppose you don't know how that can be fixed? :/

The program works as expected. It just depends on the shape of the triangle 
how equally the triangles are sized. I could tweak it so that they were 
equally-sized on equilateral patch size.. but this would not change the 
uv-mapping. To solve your problem one probably has to add support for 
arbitrary edge points in uv-space for the triangle.

> By the way, should the third character be a regular space, or some
> different character that looks the same way as a regular space (if such
> a thing exists)?

Just a plain simple regulare space.

- Micha

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

Post a reply to this message

A few more comments...

I did a new comparing of the patch with and without the normalisation
property, and there is indeed a quite visible difference, so I think
it's a good thing it was implemented, even though it slows down the
calculations.

And about optimisation - the fact that your recursive version passes the
points along doesn't mean that they are only calculated once. They are
calculated twize, because each edge is shared by two triangles, and when
you divide an edge in two, you do it for both triangles.

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

Micha Riser wrote:
> In uv-space the triangles are ditributed even.
> If you make patch that has the shape of an isosceles,
> rectangulare triangle then you will see that all
> triangles are of (nearly) same size (because uv-space
> has the same distances as realspace).

But by this, you are saying that the w value is not like the u and v
values. I don't think this fits with the ideology behind the 3-sided
bezier patch. There is not supposed to be any difference between the
three sides.

> It just depends on the shape of the triangle how
> equally the triangles are sized. I could tweak it so
> that they were equally-sized on equilateral patch size..

As I wrote, when you change the epsilon1 value to 1, then the
distribution is even for a equilateral triangle and there is no
difference between the three sides. I'm pretty convinced that this is
how it's actually supposed to work, and I don't think it's a random
"tweak" but rather a correction.

> The program works as expected.

Now it does. :)

> To solve your problem one probably has to add support
> for arbitrary edge points in uv-space for the triangle.

The uneven distribution and the UV mapping are two completely different
issues. The UV mapping never was a problem, and as I said earlier, I do
indeed intent to add support for custom UV vectors for the UV mapping.
The uneven distribution was the actual problem, but I found the solution
for that (changing the epsilon) so now there's no problem at all...

> Just a plain simple regulare space.

There is a white space in the messages I send. If it's not there when
they arrive, then Outlook Express must somehow remove them. :(

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:

> 
> Hmm, I found the solution. Change the value of epsilon1 from 0.001 to
> 1.0. I don't know why, but it fixes the distortion and makes the
> distribution completely even. :)
> 
> As I assumed, it was something with how the w value was calculated.
> Apparently, if 1-2*u*v is smaller than 1.0, then no division should
> happen at all (or a division by 1). I found out by coincidence more or
> less, so don't ask me why...

NOO! What you get is no longer a bezier patch! You lose the C-1 continuity 
at the borders! You can clearly see this when you set the tanget vectors to 
0.7 in your example. 

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

Post a reply to this message

Rune wrote:

> 
>> The program works as expected.
> 
> Now it does. :)

It does no more :(

> 
>> To solve your problem one probably has to add support
>> for arbitrary edge points in uv-space for the triangle.
> 
> The uneven distribution and the UV mapping are two completely different
> issues. The UV mapping never was a problem, and as I said earlier, I do
> indeed intent to add support for custom UV vectors for the UV mapping.
> The uneven distribution was the actual problem, but I found the solution
> for that (changing the epsilon) so now there's no problem at all...

As the distribution exactly uses the uv-points which I it is the same 
problem. In regards to the formula u,v,w are exactly symmetric (as long as 
you do not chang epislon1). 
lain simple regulare space.

> 
> There is a white space in the messages I send. If it's not there when
> they arrive, then Outlook Express must somehow remove them. :(
> 
evil program

- Micha

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

Post a reply to this message

Rune wrote:

> A few more comments...
> 
> I did a new comparing of the patch with and without the normalisation
> property, and there is indeed a quite visible difference, so I think
> it's a good thing it was implemented, even though it slows down the
> calculations.

it just doubled the formula's length..

> 
> And about optimisation - the fact that your recursive version passes the
> points along doesn't mean that they are only calculated once. They are
> calculated twize, because each edge is shared by two triangles, and when
> you divide an edge in two, you do it for both triangles.

That's true indeed.

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

Post a reply to this message

Micha Riser wrote:
>> As I assumed, it was something with how the w
>> value was calculated. Apparently, if 1-2*u*v is
>> smaller than 1.0, then no division should happen
>> at all (or a division by 1). I found out by
>> coincidence more or less, so don't ask me why...
>
> NOO! What you get is no longer a bezier patch!
> You lose the C-1 continuity at the borders!

Argh, sighhhh.

That's what I get from changing variables at random...

Maybe there's still hope. With only a 200% increase in parse time we
could calculate each point three times, each with a different edge being
the w edge. Then average those three points.

What? What's wrong with that??

...

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:

> Maybe there's still hope. With only a 200% increase in parse time we
> could calculate each point three times, each with a different edge being
> the w edge. Then average those three points.
> 
> What? What's wrong with that??
> 
> ...

Try it, I could not bring this idea working. I do not really understand 
what causes the different sizes of the triangles. 

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

Post a reply to this message

Micha Riser wrote:
> Rune wrote:
>> Maybe there's still hope. With only a 200% increase
>> in parse time we could calculate each point three
>> times, each with a different edge being the w edge.
>> Then average those three points.
>>
>> What? What's wrong with that??
>>
>> ...
>
> Try it, I could not bring this idea working. I do
> not really understand what causes the different
> sizes of the triangles.

I think I have a solution, and this time it might even work correctly...
;)

I did some #debug work and I found out that the w value is indeed
"skewed" and that changing the epsilon1 value to 1.0 makes it
"straight".

However, when u, v and w are all straight, the patch does not join up
smoothly with other patches. Making any one of the u, v or w value
skewed makes it smooth again, and it doesn't matter which of them it is.

So instead of having one of them completely skewed, I tried making all
of them 1/3 skewed and 2/3 straight. It seems to work. The patch seems
to be smooth, and the triangles are distributed evenly. Also, there is
practically no slow-down, as the averaging part is done to the u, v and
w values before the actual points are calculated.

I'll post the code when it's cleaned up.

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

> 
> I think I have a solution, and this time it might even work correctly...
> ;)
> 

OK, sound good. I will have a look at it when I get some time. I will try 
the 5-sided (and eventually the 6-sided) then too.

- Micha

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

Post a reply to this message

Micha Riser wrote:
> OK, sound good. I will have a look at it when I get
> some time. I will try the 5-sided (and eventually
> the 6-sided) then too.

Sounds good! :)

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

in news:3d6571f8$1@news.povray.org 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.

More or less falling in the middle of a thread, just back from the UK 
Gathering. Just before I left, I plugged Micha's equations into param.inc, 
it produces mesh2 and does uv-mapping, not sure though if the mapping is 
as you want it.

Ingo

Post a reply to this message

ingo wrote:
> More or less falling in the middle of a thread,
> just back from the UK Gathering. Just before I
> left, I plugged Micha's equations into param.inc,
> it produces mesh2 and does uv-mapping, not sure
> though if the mapping is as you want it.

I'd like to have a look. I already made the code generate a mesh2 and
for the mapping I plan to work on some non-linear mapping, but to see
alternative solutions can never hurt. There might be some things that
could be optimized or something like that. :)

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

in news:3d6bd332$1@news.povray.org Rune wrote:

> I'd like to have a look.

Posted the scene as a follow-up to Micha's first post in p.t.s-f

Newsgroups: povray.text.scene-files
Subject: Re: 3-sided bezier
From: ingo <ing### [at] homenl>
Message-ID: <Xns### [at] povrayorg>
Date: 27 Aug 2002 16:28:33 -0400
Xref: news.povray.org povray.text.scene-files:3199

Ingo

Post a reply to this message