# Sphere mesh problem (solved: not a problem at all)

Hi guys,

I’m working on a sky in my project and I decided to use vertex coloring to color the sky (and possibly make a dynamic sky).

Here is my code to generate the sphere (very basic):

[java]

Sphere sphereMesh = new Sphere(10, 10, 900, false, true);

[/java]

Before looping through the vertices, I do a vertex count. Based on the sphere setup I expected to find 82 vertices. But the vertex count gives me a total of 90 vertices. So there are an extra 8 vertices somewhere. I decided to color the vertices one by one to find these extra vertices and here is what I found.

http://imgur.com/LQM5c

In this image, the blue vertices are the one I never colored, the red vertex is the one I’m coloring now, and the green vertices are the ones I colored in a previous test.

The vertices seem to be generated one loop at a time. Following this image, they are generated from the right most vertex and go through the loop in a counter-clockwise fashion. The last vertex of the loop seems to be generated over the first one. The color gradient shows that the first and last vertices are not the same.

Would that be a problem for performance / mapping, etc? (unnecessary vertices)

I think the last triangle in the loop should be attached to the first vertex (to close the mesh) and the last vertex of the list should not be generated at all.

I looked at the sphere class, but it is too complicated for me: I’m not strong with math (yet), and it seems too hard for me to debug this. Is the person who created this class still around?

Sorry to dump the problem on you guys. :S

Thanks!

Hum… Strange, I found a comment in the sphere class saying this:

[java]

// compute slice vertices with duplication at end point

[/java]

So there must be a reason for this duplication. Not a bug? Does anyone knows why this duplication is wanted?

Thanks!

If you start to think about what texture coordinate you would give a shared vertex at that seam it might become clearer. For example, if you were completely mapping a texture 0-1 around the sphere then if you set that shared vertex to 1 you’ll get nearly an entire copy of the texture squished between 1 and 0.1 (or whatever)… and if you set it to 0 you’ll get nearly an entire stretched copy of the texture on the other side of the seam.

Oh, ok I think I got it. I never would have thought of that.

Thanks for the explanation pspeed.