TGAImage

[vydias]

Is this the only Image option for loading textures currently available for jogl? If so when will there be support for other image options, like the Texture class that lwgl uses?

I’m only asking because I am interested in porting our 2d rts game engine over to jogl. We already have all of our 2d images sprite rendered so I am looking at building a 3d engine that simply displays the unit sprites as images on a transparent Rect. So all unit Rects would always be facing the user and depending on their move direction/camera angle I’d simply change the Rect with a different unit facing (ala Myth 1/2).

I’ve never used TGA images but I’m guessing that they only have opaque support. Any tips available?

Thanx,
Mark

[abies]

I’ve never used TGA images but I’m guessing that they only have opaque support. Any tips available?

TGA has support for full alpha (8-bit). Just be sure that you use non-compressed TGAs - simple loaders do not support compression.

[cfmdobbie]

Yeah, TGAs are very cool - they can be raw or run-length encoded, support up to 32-bit colour, including an 8-bit alpha plane, support using the lower left as the origin etc. Well worth looking at.

(I personally think SGIs/RGBs are cooler, but TGAs come a close second!)

However, if you already have all your sprites generated, you’ll either have to convert all your graphics to TGA or write a loader for your current format.

[vydias]

Only problem with using TGA that I can see is when you have 30 different unit images with 300-400 frames of animation each and you have 2d sprites of these (high poly) already rendered out and the file size of the TGA images are 10-20mb each compared with their gif file sizes of 400-800kb each. Our program is downloaded and I don’t think people would appreciate us going from 33mb to a 300mb download size :o

No doubt I’d have to drop some frames but even still the download would be at least a 4x increase in size just for unit images, not to mention buildings, terrain and terrain objects.

So I will have to write my own gif-to-TGA file format conversion class. Has anyone already done this who could share their code? Or at least provide a link for the TGA format, after a few searches on this I’ve come up empty. If one of the developers could comment about the possibility of future support in this area I’d shelf my plans in this area and wait for a Sun solution.

[system]

It’s not exactly what you’re looking for, but http://www.xnview.com is a nice freeware converting programm supporting so many formats.

[vydias]

I’d have to build the tga Image on the fly rather then preconvert the images as that program does. I’ve actually found the TGA header info and image data at http://astronomy.swin.edu.au/~pbourke/dataformats/tga/. It’s my understanding that TGA images have to be 32 bit (uncompressed) for them to work with the jogl TGA class loader.

Only problem is that the TGAImage class only takes in a filename at this point. So I’d have to write the conversion back to disk as a TGA image then reload it producing unexceptable startup times.

I’ll move on to building the engine loading the TGA textures and hope a better solution shows itself in the near future.

[nlmueng]

If you look at the demo’s they show how to load png’s and it might work for other types.

in HWShadowmapsSimple.java

BufferedImage img = readPNGImage("demos/data/images/decal_image.png"); makeRGBTexture(gl, glu, img, GL.GL_TEXTURE_2D, true);

private BufferedImage readPNGImage(String resourceName) {
try {
BufferedImage img = ImageIO.read(getClass().getClassLoader().getResourceAsStream(resourceName));
if (img == null) {
throw new RuntimeException("Error reading resource " + resourceName);
}
return img;
} catch (IOException e) {
throw new RuntimeException(e);
}
}

private void makeRGBTexture(GL gl, GLU glu, BufferedImage img, int target, boolean mipmapped) {
ByteBuffer dest = null;
switch (img.getType()) {
case BufferedImage.TYPE_3BYTE_BGR:
case BufferedImage.TYPE_CUSTOM: {
byte[] data = ((DataBufferByte) img.getRaster().getDataBuffer()).getData();
dest = ByteBuffer.allocateDirect(data.length);
dest.order(ByteOrder.nativeOrder());
dest.put(data, 0, data.length);
break;
}

case BufferedImage.TYPE_INT_RGB: {
  int[] data = ((DataBufferInt) img.getRaster().getDataBuffer()).getData();
  dest = ByteBuffer.allocateDirect(data.length * BufferUtils.SIZEOF_INT);
  dest.order(ByteOrder.nativeOrder());
  dest.asIntBuffer().put(data, 0, data.length);
  break;
}

default:
  throw new RuntimeException("Unsupported image type " + img.getType());
}

if (mipmapped) {
  glu.gluBuild2DMipmaps(target, GL.GL_RGB8, img.getWidth(), img.getHeight(), GL.GL_RGB,
                        GL.GL_UNSIGNED_BYTE, dest);
} else {
  gl.glTexImage2D(target, 0, GL.GL_RGB, img.getWidth(), img.getHeight(), 0,
                  GL.GL_RGB, GL.GL_UNSIGNED_BYTE, dest);
}

}


[system]

[quote]If you look at the demo’s they show how to load png’s and it might work for other types.

in HWShadowmapsSimple.java
[/quote]
Good hint, interesting!
Btw where is the source code of your mentioned demo, please?
When I take a look at http://jogl.dev.java.net/source/browse/jogl/demos/ I just see “gears/” and “vertexArrayRange/”.
In the “File sharing” section, where we can download the Jogl binaries (great!), there is an archive containing the Demo binaries. They’re quite impressive (in case you own an Nvidia), but where are their sources?

Or do you need direct CVS-access?

-ric

[nlmueng]

http://jogl-demos.dev.java.net/source/browse/jogl-demos/src/demos/hwShadowmapsSimple/HWShadowmapsSimple.java?rev=1.1&content-type=text/vnd.viewcvs-markup

It is in the demos section under jogl-demos

nathan

[system]

[quote]http://jogl-demos.dev.java.net/source/browse/jogl-demos/src/demos/hwShadowmapsSimple/HWShadowmapsSimple.java?rev=1.1&content-type=text/vnd.viewcvs-markup

It is in the demos section under jogl-demos

nathan
[/quote]
Many thanks. It looks like I’ve been lost in the hyperspace before.

[vydias]

Thanks for the info, I’ve added the code for loading different types of images but I’m now stuck with how to get the BufferedImage.TYPE_BYTE_INDEXED (for gifs) converted properly. In the case I’ve added:

case BufferedImage.TYPE_BYTE_INDEXED:
{
byte[] data = ((DataBufferByte) img.getRaster().getDataBuffer()).getData();
dest = ByteBuffer.allocateDirect(data.length);
dest.order(ByteOrder.nativeOrder());
dest.put(data, 0, data.length);
break;
}

if I ask it to load a .gif it breaks into the BufferedImage.TYPE_BYTE_INDEXED and stores the pixel data in the ByteBuffer I then create the texture with:

gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, 3, img.getWidth(), img.getWidth(), 0, GL.GL_RGB8, GL.GL_UNSIGNED_BYTE, dest);

I got it to load without causing a native exception but It doesn’t display the texture.

[tortoise]

What is the status on TGAImage?

It doesn’t appear to be in my jogl jar, and I only found it in the attic in CVS. Has it been axed?

If it’s still going to be around, is it possible to add a read( InputStream is ) method as well? A pretty trivial to do but very handy addition.

And what does LEDataInputStream mean for big endian machines? Does TGAImage need to use BEDataInputStream in that case?

[gregorypierce]

Just to address the Texture issue, you can load any texture format that is supported by Java’s new ImageIO utilities. For more information on ImageIO see:

http://java.sun.com/j2se/1.4.1/docs/guide/imageio/

Within a couple of days I’ll post up a class called ImageLoader that will handle most of the common formats as OpenGL Textures.

[kbr]

[quote]What is the status on TGAImage?

It doesn’t appear to be in my jogl jar, and I only found it in the attic in CVS. Has it been axed?

If it’s still going to be around, is it possible to add a read( InputStream is ) method as well? A pretty trivial to do but very handy addition.

And what does LEDataInputStream mean for big endian machines? Does TGAImage need to use BEDataInputStream in that case?
[/quote]
It’s been moved to the source tree of the jogl-demos project to indicate that it isn’t part of the core Jogl API. There is a read(InputStream) method on the new class. The LEDataInputStream is used on all platforms and indicates that the data in the TGA file is in little-endian byte order.

[vydias]

[quote]Just to address the Texture issue, you can load any texture format that is supported by Java’s new ImageIO utilities. For more information on ImageIO see:

http://java.sun.com/j2se/1.4.1/docs/guide/imageio/

Within a couple of days I’ll post up a class called ImageLoader that will handle most of the common formats as OpenGL Textures.
[/quote]
That would be great. Loading the image into a bufferedImage is not a problem the problem lies in creating the openGl bindings for the texture. I create JVM errors in native code when trying to bind the texture to external GL_RGB and I don’t produce errors when using external format of GL_RBG8 but I get no texture displayed.

gl.glBindTexture(GL.GL_TEXTURE_2D, texture[0]);
                  gl.glTexParameteri(GL.GL_TEXTURE_2D,GL.GL_TEXTURE_MAG_FILTER,GL.GL_LINEAR);
                  gl.glTexParameteri(GL.GL_TEXTURE_2D,GL.GL_TEXTURE_MIN_FILTER,GL.GL_LINEAR);
                  gl.glTexImage2D(GL.GL_TEXTURE_2D, 
                                                      0, 
                                                      internalFormat, 
                                                      bi.getWidth(), 
                                                      bi.getWidth(), 
                                                      0, 
                                                      GL.GL_RGB8,  
                                                      GL.GL_UNSIGNED_BYTE, 
                                                      dest);

InternalFormat is GL_RGBA8 or GL_RGB8 for gifs and ‘dest’ is a ByteBuffer

[gregorypierce]

I’m just about done with it - got wrapped up in porting some of my old LWJGL code which accomplishes the same thing and realized that not having to chase byte buffer addresses and such changed the fundamental nature of a lot of my code since the JOGL binding allows you to just pass the byte buffer to the method. One of these days I need to see what JOGL is doing underneath.

Would be nice if Ken would explain what’s going on underneath in document form.

[kbr]

There’s nothing magic going on under the hood; the JNI GetDirectBufferAddress calls are simply being done in the GlueGen-generated native code rather than being exposed in Java APIs, even internal ones. In earlier projects (in particular GL4Java) I’ve tried both approaches (exposing NewDirectByteBuffer/GetDirectBufferAddress to Java or not) and as long as your glue code generator understands NIO then there is no reason to expose C pointer semantics to Java.