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