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
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.
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…
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.
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?
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.