texture mapping/memory leak?

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

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
variable

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:

RegionPlot[-2<=x<=2&&-1<=y<=1,{x,-3,3},{y,-2,2}
,MeshStyle->None
,Mesh->Reverse[grid]

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;
Timing[Graphics3D[{
First[SphericalPlot3D[
1.0,
,{\[Theta],0,Pi}
,{\[CurlyPhi],0,2 Pi}
,Mesh->Reverse[grid]
,MeshStyle->None
,MeshFunctions->{#5 &,-#4&}
]]
,Red,Thick,Line[{{0,0,-1.5},{0,0,1.5}}]
}
,ImageSize->{400,400}
]]

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
ok.

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
battery.

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

TIA,
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?