About Texture Image

There is a class called Image in JME. Its method getData() returns the data for this image. Can the Image of JME be shown on a java Panel? If it can, then how?



My main purpose is to show the Image on a java ImagePanel or something like that.



Thanks!

How is the data organized in Image? The data structure in Image should be defined by some one. :slight_smile:

Image data is a basic raster:


data[] = (byte[]) tex.getRaster().getDataElements(0, 0,
                tex.getWidth(), tex.getHeight(), null);



where it's size is:

4 * tex.getWidth() * tex.getHeight()).order(ByteOrder.nativeOrder()



4 being for RGBA.

data[] = (byte[]) tex.getRaster().getDataElements(0, 0,
tex.getWidth(), tex.getHeight(), null);


Is tex a Texture? The getRaster() seems not in Texture

What's more, can this data in Image be displayed on a java Dialog(such as an ImagePanel)?

://



Didn’t read/comprehend well enough. What Kev said.

://

well, that sounds too easy but all I get is

java.lang.UnsupportedOperationException at java.nio.ByteBuffer.array(ByteBuffer.java:903)



when calling


byte[] b=jmeImage.getData().array();


:?

is this too trivial to be answered or is this a bug?

No, but Textures are not really meant to go the other way. Your image data may or may not be still in the texture, there is no guarentee, especially after it is registered with OpenGL.

ok, so the above posts are obsolete (and no one really tried it)

The only way to modify textures (draw bullet holes or tank traces) is to keep a copy of the original awt.image or file, modify it and apply it to a TriMesh, right?

Nope - I think the problem is that the ByteBuffer is a direct byte buffer, which has no array backing it - to get an array version of it, use something like:



byte[] b = new byte[ jmeImage.getData().limit() ];
jmeImage.getData().rewind();
jmeImage.getData().get( b );



I haven't tested the code, but it should work.

Although this is probably an inefficient way of working with textures for doing decals or suchlike - you'd be better off using multitexturing in most cases, as you can then use the same terrain/building textures elsewhere and just overlay your generated decals on top. But for just displaying on a JPanel this should be fine.

Once the image data is sent to opengl, manipulating that data will not affect the texture in any way unless you force a complete reload of the texture in jME. It seems like you’d be much better off using traditional multi-texturing decal methods.



All that aside, the OP was asking about accessing the image for purposes of displaying on a JPanel. I’m guessing he wants to access render-to-texture data or otherwise he could simply read the image file himself. :slight_smile: In that case, the image data is all card-side and is not accessible from the Texture/Image object in jME in that way.

Going slightly OT, is it an unnecessary overhead to keep the image data in the Image object once it has been uploaded to openGL? It shouldn’t be needed again, should it?

That’s exactly why I say it is not guarenteed the image data will still be there. :slight_smile: As for enforcing a removal of that data, it is still being evaluated… That’s probably likely though.