MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

texture mapping/memory leak?

  • To: mathgroup at
  • Subject: [mg86772] texture mapping/memory leak?
  • From: "Fred Klingener" <gigabitbucket at>
  • Date: Thu, 20 Mar 2008 02:57:42 -0500 (EST)
  • Reply-to: "Fred Klingener" <gigabitbucket at>

Ref: Mathematica 6.0.2, WinXP, mid-range Intel dual core, 1GB RAM.

Lately, I've been trying to work out texture mapping with Mathematica.
By 'texture mapping' I mean transforming and applying the contents of
an image file onto the surface of a 3D object.

I'll describe the approach I've taken, the results so far, then try to pose 
some questions. The example problem I'll use is a more-or-less standard 
one - mapping a Mercator global map onto a sphere.

I copied a map image from Google Images ("earth map Mercator"), picking a 
small thumbnail, maybe 100 or 130 pixels wide, and using it to define a 

map = First[*paste image here*]

map is a Raster, in my case specified as a List of 3-Lists interpreted as 
RGBColors. After a long time foundering around, I discovered that the 
specification for the Option Mesh-> has to be:

grid = Take[Dimensions[map[[1]], 2] - 1

This gives a pixel count of the form {width, height}.

Testing with a rectangular mapping:


seems to do what I want after, for completely inscrutable reasons, I Reverse 
the Mesh Option spec to represent {height, width}.

Then  I tried a sphere, added a red axis line, and finally got this:

grid = Take[Dimensions[map[[1]]], 2]-1;
,{\[CurlyPhi],0,2 Pi}
,MeshFunctions->{#5 &,-#4&}

and the result is at least recognizable. If you choose an image that's not a 
true Mercator, Greenland and South America might extend to the poles - 
insignificant details. At least North, South, East, and West are right.

To get this to work required a vast amount of thrashing, not helped at all 
by SphericalPlot3D's parameterization inverting that advanced by Mathworld. 
I can't even dope out whether SP3D is internally consistent, considering the 
odd form required for the MeshFunctions. The (/[CurlyPhi]) is the azimuth, 
the second in the SP3D parameter list, but first in the return order (#4 
before the #5 (/[Theta]) elevation.)

I can't quite make sense of the minus sign in front of the #4 either. Even 
though \[Theta] runs the direction opposite to latitude, its direction is 
consistent with the direction of x in the 2D example, which seemed to work 

Converting #5 to latitude is evidently not necessary, because the image rows 
count from the top.

I'm left, though, with a pile of imponderables.

1. Why so slow? As written, Timing[] in the code fragment above reports 
around 1.5 seconds, but the actual meat clock elapsed time is more like a 
minute. How come?

2. Is there a pattern I can't discern in the way the coordinate defnitions 
relate to the MeshFunctions and the orientation of the MeshShading.

3. Are there any reported memory leakage problems associated with these 
calculations? When I work with MeshShading, my page file usage (as reported 
in my Windows Task Manager) gradually climbs to a point where the system 
hangs. If I put it into a Manipulate, I've had to pull the power and the 

4. Is there a faster or otherwise preferred way to do this?

Fred Klingener 

  • Prev by Date: Re: N::meprec warning with Solve
  • Next by Date: Re: The size of a 3D plot
  • Previous by thread: Re: Saving Packages (was: Re: importing nb files)
  • Next by thread: Re: texture mapping/memory leak?