Spherical Mapping

[Markus]

Hey,

I discovered an issue with the spherical texture mapping. When applying it to a NewtonMesh created from a sphere collision, the uv coordinates on the sides of the sphere are not correct. (See the picture below)

Using gluSphere I get better texture mapping. Is it possible to get a better mapping from Newton or is this a bug?

[Julio Jerez]

yes there are wrong.
I will look are a better mapping equation.
Maybe I can fodn teh same equation use by GL and use that, I will it check out.

how the gl look compared to the newton ones?

[Markus]

This is done using gluSphere and gluQuadricTexture(quadric, GL_TRUE); The code can be found here.

[Julio Jerez]

Oh yes they are very different. I will fix it.

[Julio Jerez]

Ok if you sync to SVN the spherical mapping Bug is fixed now.

[Markus]

Thanks for the fix, the distortion on the two ends of the sphere are gone and it looks just fine there. But overall I think it actually looks worse because the coordinates are wrong on one large strip of the sphere. The sides look perfect, but I think something is still wrong. Have a look yourself:

[Julio Jerez]

I think that distortion is because the orination of the map

try this this, in file c:\Users\Julio\Desktop\newton-dynamics\coreLibrary_200\source\physics\dgMeshEffect.cpp

find thsi funtion and chnage

Code: Select all

void dgMeshEffect::SphericalMapping (dgInt32 material)
{
   dgBigVector origin (GetOrigin());

   dgStack<dgBigVector>sphere (m_pointCount);
   for (dgInt32 i = 0; i < m_pointCount; i ++) {
      dgBigVector point (m_points[i] - origin);
      point = point.Scale (1.0f / dgSqrt (point % point));

//      dgFloat64 u = dgAtan2 (point.m_z, point.m_y);
//      if (u < dgFloat32 (0.0f)) {
//         u += dgFloat32 (3.141592f * 2.0f);
//      }
//      dgFloat64 v = ClampValue(point.m_x, dgFloat64(-0.9999f), dgFloat64(0.9999f)) * dgFloat64 (0.5f * 3.141592f);
//      sphere[i].m_x = dgFloat64 (1.0f) - u * dgFloat64 (1.0f / (2.0f * 3.141592f));
//      sphere[i].m_y = dgFloat64 (0.5f) * (dgFloat64 (1.0f) + v / dgFloat64 (0.5f * 3.141592f));

//here  try different
//      sphere[i].m_x = (dgFloat64 (1.0f) - point.m_x) * dgFloat64 (0.5f);
sphere[i].m_x = (dgFloat64 (1.0f) - point.m_z) * dgFloat64 (0.5f);
      sphere[i].m_y = (dgFloat64 (1.0f) - point.m_y) * dgFloat64 (0.5f);
   }

basically try tdiffrent permutation of point.m_x, point.m_y, point.m_z until you teh one th put teh distriton on north and sout pole of the sphere.

//here try different
sphere[i].m_x = (dgFloat64 (1.0f) - point.m_x) * dgFloat64 (0.5f);
sphere[i].m_y = (dgFloat64 (1.0f) - point.m_y) * dgFloat64 (0.5f);

[Julio Jerez]

Oh not I think it is still wrong,. bcause I see the distorion on the equator and not in one Pole,
The foruma I used is not right, I will try a different one.

[Markus]

I tried this approach:

sphere[i].m_x = point.m_x / (sqrt(point.m_x*point.m_x + point.m_y*point.m_y + point.m_z*point.m_z));
sphere[i].m_y = point.m_y / (sqrt(point.m_x*point.m_x + point.m_y*point.m_y + point.m_z*point.m_z));

instead of

sphere[i].m_x = (dgFloat64 (1.0f) - point.m_x) * dgFloat64 (0.5f);
sphere[i].m_y = (dgFloat64 (1.0f) - point.m_y) * dgFloat64 (0.5f);

with similar results....

[Julio Jerez]

I tried this approach:

sphere[i].m_x = point.m_x / (sqrt(point.m_x*point.m_x + point.m_y*point.m_y + point.m_z*point.m_z));
sphere[i].m_y = point.m_y / (sqrt(point.m_x*point.m_x + point.m_y*point.m_y + point.m_z*point.m_z));

instead of

sphere[i].m_x = (dgFloat64 (1.0f) - point.m_x) * dgFloat64 (0.5f);
sphere[i].m_y = (dgFloat64 (1.0f) - point.m_y) * dgFloat64 (0.5f);

with similar results....

That is the same I am using, if you look at the code you will see that point is a nomalize value.

That form of mapping is no really a spherical mapping, it is more of less and flat projection.

the method I was using before is the correct Spherical mapping but it looks wrong and I think I know why.
The raeson it looks differenet is because it is OpenGl that is wrong.
OpenGl is not really applying a Spherical Mapping, they are applying a cylindrical mapping.

to test my theory try applying a cylindrical mapping to the Sphere, and I beleive it will looks just like the OpenGl Mapping.
if that works the I will make teh change.


Fist I was confused, but now I see what happen.
The first image you show in the first post is a correct Sphercial Mapping
The OpenGl shere is not a Spherical Mapping, it is a Cylindrical mapping.
That is look better has nothing to do with correctness. But the fact that is looks better is a good reason to apply Cylidrical mapping to a spherial objects instead of spherical mapping.

Bascially openGl apply cylidrical mapping without capping,
I will make that change and if it looks just like openGL.

[Markus]

I tried to do that, but you removed the Cylindrical Mapping with _ASSERTE(0) and there are some compile errors in it. I couldnt fix them since I dont know the entire code.

[Julio Jerez]

No waight until I revisit the firt implemnetation.

This is what my interpretation of spherical mapping is:
the parametric value of a point is

p (x, y, z) = p (u, v)

the point has and oringion a 0, 0, 0
the mapping function can be a polar to corvertion

y = sin (u);
x = cos (u) * sin (v);
z = cos(u) * con(v);

the inverse mapping is

u = asin (y) [ -90 < y < 90]
v = atan2 (x, z) [ -180 < v < 180]

for here we mapp form angles to parametic u,v
u -> [0 < u < 1]
v -> [0 < v < 1]


that is what I used first, but and it should be correct, now I start to think that they is a Bug in the origin implementation.
I will check it again because they is nothing wrong with the arithmetic, therefore my implementation must have a Bug.

[Julio Jerez]

Ok I just check in that change, please sync to svmn and try again,
see if it looks like the Opengl one.

[Julio Jerez]

Upp sorry, I made another mistake, but I fixed it now,

pleases sync again to SVN and it should be perfect now.
let me know if it is Ok please.

[Markus]

Thats the result: EDIT: Result is in the next post.