next »

[Marvin Fröhlich]

I have abstracted the abstractable parts of the TextureLoader and ported it to JAGaToo. Fortunately there are only a few changes, that affect the Xith3D API. Please refer to this posting to read about them.

The new TextureLoader uses implementations of TextureFormatLoader and TextureImageFormatLoader to directly load from image files into Texture instances. Only if there is no implementation for the requested format, the fallback-loader is used, which uses ImageIO.

The currently implemented TextureImageformatLoaders and TextureFormatLoaders are added to the TextureLoader by default, so that faster texture loading can be done, if there's a compatible loader.

The fallback-loader now uses ImageInputStreams to load the texture-data directly without the use of (standard) BufferedImages. This is about 25% faster. Unfortunately it is still much slower than the other TextureImageFormatLoaders. As an example I loaded a 512x512 JPEG 50 times. It took about 11 seconds. Loading it 50 times from a TGA for example takes 2.2 seconds. Unfortunately the JPEG format seems to be quite complicated, so implementing a direct loader will not be too simple.

Mipmaps are now also generated without using temporary memory or BufferedImages, but are directly generated into the TextureImages' ByteBuffers. This should be slightly faster and in any case less (temporary) memory intensive.

The new TextureLoader now supports loading of Texture3Ds.

I have added valid implementation of duplicateNodeComponent() for Texture2D and Texture3D. This way you can load a Texture, apply some filters, etc. to it, then use cloneNodeComponent( false ) to get a shared copy of the texture and apply different filters to it.

Marvin

[qbproger]

The TextureStreamLoader resides in JAGaToo now and has been renamed to TextureFormatLoader.
The TextureComponentLoader resides in JAGaToo now and has been renamed to TextureImageFormatLoader.
Most of the TextureStreamLoaders have been converted to TextureImageFormatLoaders.
You don't need to manually add TextureFormatLoaders or TextureImageFormatLoaders to the TextureLoader, since all standard implementations are added by default.

What's the difference between a TextureFormatLoader and TextureImageFormatLoader?  I had written my own format loader, and trying to move it to the new system I changed it to a TextureImageFormatLoader.  It was previously a TextureStreamLoader.

I'm calling TextureLoader.getInstance().addTextureImageFormatLoader(myImageFormatLoader).  It seems to be using the IOImage reader, and throwing an exception.

Here is the exception:

Code:

java.lang.IllegalArgumentException: ImageReadParam num source & dest bands differ!
at javax.imageio.ImageReader.checkReadParamBandSettings(Unknown Source)
at com.sun.imageio.plugins.png.PNGImageReader.readImage(Unknown Source)
at com.sun.imageio.plugins.png.PNGImageReader.read(Unknown Source)
at org.jagatoo.loaders.textures.formats.TextureImageFormatLoaderImageIOImageInputStream.loadFromStream(TextureImageFormatLoaderImageIOImageInputStream.java:87)
at org.jagatoo.loaders.textures.formats.TextureImageFormatLoaderImageIOImageInputStream.loadTextureImage(TextureImageFormatLoaderImageIOImageInputStream.java:247)

Also one thing to note, if you chose to use a ImageInputStream (in javax.imageio.stream IIRC).  You get some nice image reading functions like readUnsignedInt() readInt() readByte() etc.  I found out about it recently.  It helps with binary formats.  Unsigned types are still needed in java though.

[Marvin Fröhlich]

As you can see in the stacktrace the exception is coming from the fallback-format-loader. So your own format loader doesn't seem to be able to load your image.

the difference between TextureFormatLoader and TextureImageFormatLoader is, that a TextureFormatLoader also loads all the mipmaps, if requested. In very most cases, this is not necessary. The only case, where this is necessary in the existing format-loaders is the DDS-loader, where the mipmaps are read from the file itself and cannot be auto-generated.

What kind of images does your loader load? Would it make sense to put your loader into the JAGaToo project (if it is for a general, but not specialized case)?

Marvin

[qbproger]

All of my images are of the same type and should use my loader.  For some reason the bytes don't seem to be getting read correctly now.  I put a breakpoint in my loader, it's going into it and returning null because the first 2 bytes aren't right (for sgi (.rgb, .sgi or .rgba) images they're supposed to be 474 of 01DA in hex).  Right now i'm getting -119 for the first byte and 80 for the second.  I end up 35152 for the first 2 bytes of the file.

I'll keep looking at it.  I guess I didn't move to the new system correctly.  I'll keep debugging it.

[qbproger]

I used this file as a starting point, but it didn't load the entire format, so more needed to be added.  I found it online somewhere, but I think it may have been taken down.  The format is fairly well documented.

Here are a few sources with documentation:
http://local.wasp.uwa.edu.au/~pbourke/dataformats/sgirgb/sgiversion.html
ftp://ftp.sgi.com/graphics/SGIIMAGESPEC
http://www.fileformat.info/format/sgiimage/

[qbproger]

Disregard what I said about my loader not working.  I forgot that I do have 1 PNG file and that seems to be causing a problem.  Let me see if it happens with other PNG files.

[Marvin Fröhlich]

Disregard what I said about my loader not working.  I forgot that I do have 1 PNG file and that seems to be causing a problem.  Let me see if it happens with other PNG files.

Well, the default fallback format loader has problems loading gif images. I don't know, why. Since I've added a custom loader for GIF images, this is not a problem anymore. But your exception looks like what you would get when the fallback loader tries to load a GIF image.

You can use a difference facllback-loader, that is capable of loading GIF files and possibly your PNG, too by adding this line to your appplication code before loading the image:

Code:

TextureLoader.getInstance().setFallbackTextureImageFormatLoader( new TextureImageFormatLoaderImageIOBufferedImage() );

Of course it is still interesting, why the ImageInputStrea-based loader isn't capable of loading your PNG.

Marvin

[Marvin Fröhlich]

btw.

Also one thing to note, if you chose to use a ImageInputStream (in javax.imageio.stream IIRC).  You get some nice image reading functions like readUnsignedInt() readInt() readByte() etc.  I found out about it recently.  It helps with binary formats.  Unsigned types are still needed in java though.

You don't need an ImageInputStream. A DataInputStream is sufficient to load primitive java data types including unsigned bytes/shorts/ints.

Marvin

[qbproger]

Just some more general information about image formats...

There are a few image implementations on jogl.  You can see the formats supported here.
http://download.java.net/media/jogl/builds/nightly/javadoc_public/

SGI Images happen to be one of them.  They also support TGA and DDS.  I don't know if you can use this though.

Also, LWJGL used to use DevIL for loading images (they stopped using it in 2.0.0 beta 1).  It can load a whole slew of image types.  It's in LWJGL-optional-1.1.4.zip.  It looks like it's used very similarly to the C API, which can be hard to use.  When I used DevIL on a project (C++ project), I had to look at the header files to find where the information I wanted was.

http://www.lwjgl.org/javadoc/index.html?org/lwjgl/devil/package-summary.html

For a list of supported image types you can look here:
http://openil.sourceforge.net/

I found out about both of these after I had written the TextureStreamLoader, but these might be of use in the future.

[qbproger]

Disregard what I said about my loader not working.  I forgot that I do have 1 PNG file and that seems to be causing a problem.  Let me see if it happens with other PNG files.

Well, the default fallback format loader has problems loading gif images. I don't know, why. Since I've added a custom loader for GIF images, this is not a problem anymore. But your exception looks like what you would get when the fallback loader tries to load a GIF image.

You can use a difference facllback-loader, that is capable of loading GIF files and possibly your PNG, too by adding this line to your appplication code before loading the image:

Code:

TextureLoader.getInstance().setFallbackTextureImageFormatLoader( new TextureImageFormatLoaderImageIOBufferedImage() );

Of course it is still interesting, why the ImageInputStrea-based loader isn't capable of loading your PNG.

Marvin

My Jagatoo is updated to revision number 223 (as far as I can tell the TextureLoader was not touched much after that).  I believe this is happening when trying to load a PNG.  It's taking many seconds, and eventually I get an out of memory error if I let it run.  The CPU usage sits at 100% while this is running.

The image is 1024 x 2048  Pixels and 1.68 MB PNG.  I'm using the FallbackLoader that you said to above.  Any ideas?

[qbproger]

I made an image that exhibits the problem.  When I load this image, the JVM shoots up really high in memory usage, and eventually has to be shutdown.

It was too big to attach in the forum, so here is a link.
http://www.quibb.org/problem_image.png

[Marvin Fröhlich]

The texture loads perfectly for me. On some images the default fallback loader fails to load the texture. In these cases you could use a different fallback loader by adding the following line in your initialization code (before the texture is loaded):

Code:

TextureLoader.getInstance().setFallbackTextureImageFormatLoader( new TextureImageFormatLoaderImageIOBufferedImage() );

btw. What do you mean by "I am using the fallback loader"? Are you using it explicitly in some way? Or did you simply check, which format loader actually loads your texture? I guess hope and assume, it's the latter case.

Marvin

[qbproger]

The texture loads perfectly for me. On some images the default fallback loader fails to load the texture. In these cases you could use a different fallback loader by adding the following line in your initialization code (before the texture is loaded):

Code:

TextureLoader.getInstance().setFallbackTextureImageFormatLoader( new TextureImageFormatLoaderImageIOBufferedImage() );

btw. What do you mean by "I am using the fallback loader"? Are you using it explicitly in some way? Or did you simply check, which format loader actually loads your texture? I guess hope and assume, it's the latter case.

Marvin

Yea, I have that line of code in there, and it's using the Fallback loader.  Odd that it loads fine for you, and memory usage shoots way up for me.  I was testing it in Windows XP with Java 6.  I'll try it on my Linux box and see if the results are different.

[qbproger]

Ok, my mistake.  Thanks for the response.  I was setting a TextureStreamLocatorURL and when trying to load the texture passing in the full URL.  It's working now.  Thanks.

On the bright side of things, I'm up to revision 1463 now