> From: "Vished Kumar" <[EMAIL PROTECTED]>
> I have been trying to run the TextureImage example using a 45Mb 256 color
> GIF image.
Wow! That is a *big* image. What is the size, 10K x 10K?
> Even though the machine I am using (a SGI VisualPC with a pentium
> III processor) has 512Mb of physical memory, the application stills exits
> with an "Out of memory" exception.
This makes sense. The source is a 256 color compressed image. The image will
be loaded into a 24 or 32 bit uncompressed image internally (I think it is
always a 32 bit image, but I'm not positive). So take your image dimensions
and the expected memory footprint is: width * height * 4 bytes.
Assuming that your image has a 8x compression ratio (going from 8 bit compressed
to 32 bit uncompressed), it will have a memory footprint of 360MB. This should
fit, but creating a J3D texture requires two copies of the texture to be in
memory for a short time (the source ImageComponent2D and the resulting Texture).
The multiple copies are needed because J3D needs to have it's own copy of the
image (look for improvements in this for J3D 1.2). Loading the image into
OpenGL may force yet another copy, although I believe that the with careful
coding an image can be loaded so that it temporary memory usage is 2x the image
size and its persistent usage is only 1x the image size (uncompressed).
> Are there known problems or limitations
> with how Java3D handles Textures? Can anyone suggest workarounds to this
> without compromising on the quality of the texture?
Breaking the image up into sub-images each of which is loaded as a separate
texture (and rendered on a separate polygons) would solve the "multiple copies
in memory" problem. This is still tricky though, because it will be difficult
to break up the original image into pieces without having two copies of the
image in memory (the complete image and the tiles). Once you have the image in
smaller chunks, it will take less memory to load the textures into J3D since you
will only need to have two copies of each chunk in memory during the loading
process.
> Would generating MIPMAPs help or worsen the problem?
Well, generating MIPMAPs will be hard since they also require multiple copies of
the image to be loaded into memory. Each MIPMAP level will use 1/4 the memory
of the level above it, but also have 1/4 the resolution of the level above it.
Using MIPMAPS will probably improve your performance when the image is displayed
large enough that the screen resolution is smaller than the texture resolution
(i.e. when displaying a 4K x 4K image on a 1K x 1K display, a 1K x 1K MIPMAP
will have the same appearance but use 1/4 the memory).
Note that the a MIPMAP'd image takes up to 1.5 times the memory of the
non-MIPMAP'd image.
If you can manage the memory, I think that MIPMAPs will help your performance
significantly.
> FYI, I eventually want to texture map aerial imagery over a Digital
> Elevation Model. The TextureImage example is just the first step.
A better way might be to break use a standalone program to break the image up
into smaller gifs and then display each of those on a section of your DEM. If
you could manage your scene so that only the visible portion of the texture
needs to be in memory you can further reduce the memory required.
Doug Gehringer
Sun Microsystems
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
