I just got done working out some code to generate spheres from traingles and
smooth_triangles, but when I texture the sphere with both a texture (red) and an
interior_texture (green), it appears to me that some of the surface normals are
the opposite of what they should be.  I tried playing around with the order of
the vertices, but that didn't seem to accomplish much.

Switch the value of P between true and false to render either the
icosahedron-based sphere or the octahedron-based sphere.

Thanks for any helpful insights

Post a reply to this message

Attachments:
Download 'subdivided_mesh_sphere.pov.txt' (11 KB)

Am 17.08.2016 um 21:11 schrieb Bald Eagle:

> I just got done working out some code to generate spheres from traingles and
> smooth_triangles, but when I texture the sphere with both a texture (red) and an
> interior_texture (green), it appears to me that some of the surface normals are
> the opposite of what they should be.  I tried playing around with the order of
> the vertices, but that didn't seem to accomplish much.

- Can you be more specific what playing around with the order of the
vertices /did/ accomplish, and what it /didn't/?

- The interior/exterior texture issues seen with the /flat/ triangles
version are most certainly due to inconsistent ordering of the vertices.

- The interior/exterior texture issues seen with the /smooth/ triangles
version in the image posted on povray.binaries.images are known
artifacts of smooth triangles.

What happens is this:

- To determine whether we see the inside or outside of an object,
POV-Ray tests whether the surface normal computed at a given point is
oriented somewhat towards us (in which case POV-Ray concludes that we
see the outside) or somewhat away from us (in which case POV-Ray
concludes that we see the inside).

- With flat triangles, the surface normal is computed as the cross
product of the vectors P2->P1 and P2->P3, respectively. As a result, the
direction of the surface normal is determined by the ordering of the
vertices, and if you get the ordering wrong on a triangle you will see
the inside texture where you expect the outside texture and vice versa.
To fix this, you have to re-order the vertices.

- With smooth triangles, the surface normal is instead interpolated from
the normal vectors given for the vertices. If we see the triangle almost
edge-on, it may happen that the normal vectors of one or more vertices
point away from us even though we see what would normally be considered
the front side of the triangle. In such a case, parts of the smooth
triangle will show the exterior texture while others will show the
interior texture, and unfortunately there is nothing you can do to fix this.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> - Can you be more specific what playing around with the order of the
> vertices /did/ accomplish, and what it /didn't/?

I'll try again and see if I can get a more structured experiment and post
results.
I worked most of this out in 15 min bursts.
I probably won't get to that until later, but it certainly appeared to me that
changing the ordering of the vertices did - absolutely nothing.

(If I have a triangle, and swap 2 vertices, then that should flip the triangle.
 I'm pretty sure I didn't just reorder them and accidentally maintain the
original handedness)

> - The interior/exterior texture issues seen with the /flat/ triangles
> version are most certainly due to inconsistent ordering of the vertices.

I would have thought so, which is why I started reordering the vertices in the
declarations.

It appears that almost all of my green texture is showing on that "lower right"
portion of the sphere.  IIRC, I tried to rotate the result 90 and 180 deg to
show the side and back (to check for holes / green) and it didn't appear that
such a rotation accomplished much - I thought more green would be toward the
camera, but all that appeared to happen was a slight change in the border
between red & green.

ALL of my polyhedra are colored that way.
The octahedron, the icosahedron, and the dodecahedron.
You'd think that it would be more random / haphazard, especially with the
dodecahedron - where I had to keep track of 60 vertices and their
handedness/ordering and then expand that to a whole second array where all of
the pentagons were broken down into 5 triangles each - all hand-coded and
without a test render.
This seems far too coincidental.

But as I said, I will do more testing.


> - The interior/exterior texture issues seen with the /smooth/ triangles
> version in the image posted on povray.binaries.images are known
> artifacts of smooth triangles.
.....
> - With smooth triangles, the surface normal is instead interpolated from
> the normal vectors given for the vertices. If we see the triangle almost
> edge-on, it may happen that the normal vectors of one or more vertices
> point away from us even though we see what would normally be considered
> the front side of the triangle. In such a case, parts of the smooth
> triangle will show the exterior texture while others will show the
> interior texture, and unfortunately there is nothing you can do to fix this.

"it may happen that the normal vectors of one or more vertices 'point away from
us'  "

I would have thought that since the sphere/polygon is convex on all faces, that
everything would always be "out".
All I did was use the [normalized] vertex coordinate as the normal, since
Vertex-<0, 0, 0> = Vertex .

Though your description does explain why the smooth_triangle sphere is mostly
red with only a few of the aforementioned artifacts at the edges.

Thanks as always

Post a reply to this message

Am 18.08.2016 um 13:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> - Can you be more specific what playing around with the order of the
>> vertices /did/ accomplish, and what it /didn't/?
> 
> I'll try again and see if I can get a more structured experiment and post
> results.
> I worked most of this out in 15 min bursts.
> I probably won't get to that until later, but it certainly appeared to me that
> changing the ordering of the vertices did - absolutely nothing.

Hrrmpf... When it comes to error reports, I prefer precision. "not much"
!= "absolutely nothing".

> (If I have a triangle, and swap 2 vertices, then that should flip the triangle.
>  I'm pretty sure I didn't just reorder them and accidentally maintain the
> original handedness)

I've just done a bit of toying around myself, and it seems that you may
be onto /something/. Here's the kicker: If you replace the "union"
around the flat triangles with "mesh", and leave everything else
uncganged, the octahedron version gives you a nice consistent texture
(though it's the inside texture, but that's easy to fix by flipping the
basic vertices at the z axis). That shouldn't happen -- the texturing of
triangles in a union should be the same as in a mesh.

(Even when using a mesh, the icosahedron is still textured
inconsistently, so my guess is that you have some individual basic
vertices wrong there.)

>> - With smooth triangles, the surface normal is instead interpolated from
>> the normal vectors given for the vertices. If we see the triangle almost
>> edge-on, it may happen that the normal vectors of one or more vertices
>> point away from us even though we see what would normally be considered
>> the front side of the triangle. In such a case, parts of the smooth
>> triangle will show the exterior texture while others will show the
>> interior texture, and unfortunately there is nothing you can do to fix this.
> 
> "it may happen that the normal vectors of one or more vertices 'point away from
> us'  "
> 
> I would have thought that since the sphere/polygon is convex on all faces, that
> everything would always be "out".
> All I did was use the [normalized] vertex coordinate as the normal, since
> Vertex-<0, 0, 0> = Vertex .

Of course everything is always "out" in a sphere or a convex polygon,
but how is POV-Ray supposed to know that you're trying to model such an
object?

Post a reply to this message

I just flipped ALL the triangles in the scene.

Lines 248 & 249 determine the loop order of the triangle vertices.
I switched from 0 to 2, to 2 to 0 step -1.
The results are identical.

This troubles me.

Post a reply to this message

Attachments:
Download 'dodecahedron.pov.txt' (22 KB)

Am 18.08.2016 um 16:11 schrieb Bald Eagle:
> I just flipped ALL the triangles in the scene.
> 
> Lines 248 & 249 determine the loop order of the triangle vertices.
> I switched from 0 to 2, to 2 to 0 step -1.
> The results are identical.
> 
> This troubles me.

Don't let it trouble you any longer; let it trouble me from now on.

In the meantime, you can work around it by using meshes instead of
unions of triangles.

Post a reply to this message

One thing is for sure: You've seriously screwed up on the icosahedron.

Apparently you misinterpreted the positions of the individual points,
probably thinking that Phi<1, but in fact Phi>1.

Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
regular icosahedron.

You also got the front top cap's ordering of points wrong. Fixing that
will give you a nicely textured mesh.


As for the union of individual triangles, I'm still working on that one;
I must confess that so far I don't really have a clue where things go wrong.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> One thing is for sure: You've seriously screwed up on the icosahedron.

It's indeed probable.
When I rendered it the first time around, it was a heinously grotesque form.
Then when I saw that Phi equals approx 1.618, I thought that maybe that was the
problem and vnormalize( )ed all the vertices and it just _looked_ like it was
ok.
Such are the dangers of "massaging the data".

The interesting thing is how well the macro outputs looked - it wasn't obvious
that the basis array of points was wrong.

> Apparently you misinterpreted the positions of the individual points,
> probably thinking that Phi<1, but in fact Phi>1.
>
> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.
>
> You also got the front top cap's ordering of points wrong. Fixing that
> will give you a nicely textured mesh.

Thanks for looking that over and spotting the errors.
"Do not correct a fool - or he will hate you; correct a wise man, and he will
appreciate you."

> As for the union of individual triangles, I'm still working on that one;
> I must confess that so far I don't really have a clue where things go wrong.

I'm actually surprised that such a thing hasn't come to anyone's attention until
now.

While you work on that, I'll start working on breaking something else.   :D

Post a reply to this message

Am 18.08.2016 um 18:13 schrieb clipka:
> As for the union of individual triangles, I'm still working on that one;
> I must confess that so far I don't really have a clue where things go wrong.

Yikes!

I've found the culprit.


You see, after parsing the triangle vertices, POV-Ray invokes a piece of
code that precomputes certain values for the triangle that will be
required in each and every intersection test.

That code first computes the surface normal from the vertices, as well
as the distance between the coordinate origin and the plane in which the
triangle lies.

The code then goes on to enforce a certain ordering of vertices that
allows for certain shortcuts in intersection testing. You may note that
this shouldn't be a problem for the interior/exterior texture test,
since the surface normal has already been computed at this point.


It /does/ become a problem, however, as soon as you invoke any
transformation on the triangle -- because such an operation changes the
position of the vertices, and therefore requires a re-computation of the
precomputed stuff.

And this time the precomputation will operate on potentially rearranged
vertices.


As I said: Yikes!

Post a reply to this message

Am 18.08.2016 um 18:40 schrieb Bald Eagle:

> Thanks for looking that over and spotting the errors.
> "Do not correct a fool - or he will hate you; correct a wise man, and he will
> appreciate you."
> 
>> As for the union of individual triangles, I'm still working on that one;
>> I must confess that so far I don't really have a clue where things go wrong.
> 
> I'm actually surprised that such a thing hasn't come to anyone's attention until
> now.
> 
> While you work on that, I'll start working on breaking something else.   :D

Be my guest -- I'm in a wise mood :)

Post a reply to this message