Exporting Texture with BinaryExporter

Troubleshooting General Help
1

Im trying to save textures and load them up again later.



Test code is as follows



File parent = FileManager.getBasePath("data");      
String path = parent.getPath() + "//1.t";      
      
BinaryImporter bi = new BinaryImporter();
BinaryExporter bd = new BinaryExporter();   
      
t1 = TextureManager.loadTexture(pt.getImage(), Texture.MM_LINEAR_LINEAR, Texture.FM_LINEAR, false);
t1.setApply(Texture.AM_COMBINE);
t1.setCombineFuncRGB(Texture.ACF_MODULATE);
t1.setCombineSrc0RGB(Texture.ACS_TEXTURE);
t1.setCombineOp0RGB(Texture.ACO_SRC_COLOR);
t1.setCombineSrc1RGB(Texture.ACS_PRIMARY_COLOR);
t1.setCombineOp1RGB(Texture.ACO_SRC_COLOR);
t1.setCombineScaleRGB(1.0f);
      
      
bd.save(t1, new File(path));
      
Savable s = bi.load(new File(path));
t1 = (Texture)s;





When loading them back up with BinaryImporter the texture is always the missing texture.

Any ideas ??
2

? does saving a texture actually save the image bits

3

it shouldn't. afaik it just saves the paths.

why so you save textures alone?



http://www.jmonkeyengine.com/jmeforum/index.php?topic=4342.0

4

im creating complex textures on a server, which the client will need to render. Similar to google earth



guess i should serialise the buffered image ?

5

if you reuse the images later, the best option is probably to save them as files. you can even add metadata to PNG files for example.

if you don't need the data later, you can just send the bytes over. the client will have to create the texture.

of course you can do what you currently do (serialize the texture) and send it over too, then recombine them on the client. but i'm not sure if it's a good idea to let the server to decide over the client's texturing :slight_smile:

6

Thanks sfera



Guess i was trying to avoid the middle bit of loading the images into jme and was trying to directly load up the JME image data.



Can anyone please clarify wether the image data is held locally in JME code, of is it just send to the Graphics card and referenced from there.

7

both jme and the card.



edit:

usually the driver "uploads" the image data on the card, so afaik it isn't really possible to reference an image which is only in the card memory.

8

Ok, its done…



If client version is out of date, the client fetches a new .png file from the server and saves it locally.

9

i'm glad to hear you solved your issues :wink:

10
sfera said:

it shouldn't. afaik it just saves the paths.


The Texture class will save its image field (along with the byte rep of the texture image) if you call setStoreTexture(true) on your Texture object before storing with BinaryExporter.  You can also set Texture.DEFAULT_STORE_TEXTURE to true before creating your textures if you prefer this to be the default behavior.
11

seems like i was wrong… again  ://

12

Nice thanks renanse



out of interest, is the texture on the graphic card and in jme memory. If so, is it possible to remove the texture bytes from the JME version for performance gains.



Sfera, thanks for the info, it has actually helped with many a thing…

13

I believe it's possible, although maybe there is some dependancy on the Image field like hash keys or something… I don't have the source right here in front of me. 



We thought of doing that in the core and passed because of a few situations where you want to keep the data (such as this one).  You are free to do it yourself though.

14

excuse my ignorance but maybe someone can explain this to me(a bit off-topic):

i think of the situation where you use a lot of textures and the card memory becomes full. afaik in such a situation, a part of the textures are "unloaded" from the card memory into the system memory to make place for new textures. now what happens if you don't have any reference on the image and you just continue pushing textures to the card/opengl?

15

Your drivers cache and manage sending bound textures between system and card memory.  An OpenGL app can at best specify which images should have priority for being in card memory.  The app doesn't have to worry about shuttling textures back and forth though.