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]
,MeshShading->Map[RGBColor,map[[1]],{2}]]
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&}
,MeshShading->Map[RGBColor,map[[1]],{2}]
]]
,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