>Vished,
>At 10:13 AM 4/29/99 -0700, you wrote:
>> I have been trying to run the TextureImage example using a 45Mb 256 color
>
>One of the techniques I use is to make sure that the size of the texture is
>appropriate to the display resolution. So, if you had a very large display,
>of 2048 x 1536, 24bit colour,
>your image size should be no bigger than 2048 x 1536 pixels = 3,145,728
>pixels x 3 (bytes) = 9,437,184 MB frame buffer (1 frame).
>
>
>>FYI, I eventually want to texture map aerial imagery over a Digital
>>Elevation Model. The TextureImage example is just the first step.
>
It might be helpful for you to check out an Internet-based orthophoto
server that I worked on last year to see if it gives you any ideas
on how to help develop your project:
http://ri.mit.edu
We serve up the entire State of Rhode Island. Users have the ability
to zoom from 200m / pixel resolution down to 1m /pixel resolution.
Each 1 meter res DOQ is about 45 MB, but the server clips on the fly
only those pixels needed to fill the viewport. We resample the original
1 meter res DOQs into a tree of lower res images (ie. 2m, 5m, ..., 200m).
Each DOQ at 200m / pixel resolution is only about 2Kb. Thus, it is easy
to view the entire State at once. You could probably prepare a similar
tree of images, and then swap in textures depending on how much of the
DOQ needs to be visible. Thus, you would try to avoid loading in the
entire 45Mb image at once, but instead would clip out only the portion needed
to texture map the visible part of the DEM. We were doing our clipping
using perl and the netpbm graphics utilities, doing all the processing
on the fly in memory, and streaming the bytes to the client's browser
without writing the intermediate image to the server's disk. Maybe you
could read in the 45MB image, clip out a new image for the pixels that
cover the DEM in the current view, and then set that as your textured
image? I'm not really sure how all this would run in real time as you
navigate over the DEM. It is easier in our case where the viewport
doesn't change so rapidly.
Good luck,
Steve Schweibinz
In case your curious, some other orthosites to check out are:
http://ortho.mit.edu
http://coast.mit.edu
/*******************************************************
Stephen E. Schweibinz
Planning Support Systems Group, MCP candidate, MIT
(617) 679-0360
[EMAIL PROTECTED]
http://www.vcp.com
*******************************************************/
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
