Ok, before we keep hijacking Nardevs jme3-contest-thread I start a new one. /croasteroids-asteroids-with-a-kick
Short summary:
The problem is that there is a problem converting blender 2.5-files that have a reference to a texture. In this case
the whole texture is attached uncompressed to the j3o-file. Blender 2.49-Files do work smoothly.
I tested lots of different combinations and actually the blender-importer seems to be the problem. (At least to me)
I just want to find the problem and started by saving the j3o-manually via BinaryExport. Actually that did work fine. @Normen explained
me that the jmp-converter tries to find the texture in the current assetmanager. If that fails it includes the texture. So there seems to be
somehow the problem!? As I have absolutely no clue how to debug jmp I hope someone who is more into jmp can have a lookā¦
They work smoothly probably because you save them jME2-style in the root of the asset manager. I guess then it can be loaded because somehow its not reported as relative like the old files. In jME3 you donāt register lost of folders to the asset system, overriding image names with each other but you keep a folder structure for assets like a class path. Can you check if it works when you load the model from a subfolder (e.g. register the locator on the parent). Normally you should rather regard jMP as a test if a loader works correctly than the other way round 
Edit: In other words, the j3o files you created will not load when the images are placed in a subfolder of the assetmanager.
@normen:
Hmm,ā¦I saved the file in my working-folder. Now I changed the test-case. Here is my folder-structure:
[java]
/src
/Assets
/Models
untitled.blend
/Tex
tex.png
[/java]
I then convert like told in the wiki:
[java] String userHome = System.getProperty("user.home");
BinaryExporter exporter = BinaryExporter.getInstance();
File file = new File("Assets/Models/somefile.j3o");
try {
exporter.save(rootNode, file);
} catch (IOException ex) {
Logger.getLogger(ExportTest.class.getName()).log(Level.SEVERE, "Failed to save node!", ex);
}
[/java]
Export still works. around 5000bytes
Loading:
[java] BinaryImporter importer = BinaryImporter.getInstance();
importer.setAssetManager(assetManager);
File file = new File("Assets/Models/somefile.j3o");
try {
Node loadedNode = (Node)importer.load(file);
loadedNode.setName("loaded node");
rootNode.attachChild(loadedNode);
} catch (IOException ex) {
Logger.getLogger(ExportTest.class.getName()).log(Level.SEVERE, "No saved node loaded.", ex);
}
[/java]
Also worksā¦
Normally you should rather regard jMP as a test if a loader works correctly than the other way round ;)
Totally agree :D!
You load the model the wrong way. It should be assetManager.loadModel(āModels/somefile.j3oā); While before you load the model with assetManager.loadModel(āModels/somefile.blenderā); and then save it like you do. At all times the assetManager should have the āAssetsā folder registered as a root and the texture should be in the Textures folder. Could you check that too while youāre at it? Appreciate the in-depth testing 
Edit: Using āFileā is generally discouraged in jME3, regard the assetManager your fileSystem, jME3 is meant to be a platform rather than a desktop java library in that respect.
Yeah,ā¦you are right! Actually I just ādeserializeā the serialized object! Youāre right! But loading it the right way also worked out perfectly. Not that I do not like this
Of course File is just for the purpose of testing the serializerā¦
Hm, then I donāt know what should fail with the importing in jMP, its exactly what happens there. Do you copy the model to the assets and convert it by right-clicking or do you import it via the Model Import tool?
I tried bothā¦I will check againā¦
Can you post the whole code of the final test case just to be sure?
Ohmy,ā¦first of all jmp exported the the blend same way as the manual version did.
But actually I made a mistake by creating my cube. The thing is, I took the default-cube
unwrapped it, used texture paint to paint on the its texture and save the image! Default
Material was applied BUT I didnāt explicitly add the texture to the material. When setting
there explicitly the the image the same effect happens again (in jmp and manual).
So what is the consequence? It seems that the importer loads the texture that is applied
via uv-editor eventhough it is not explicitly applied in the material. (I think this is the texface
mode!?) So it seems that jmp is innocent Sry for messing this up. I will now have a look
in the importer againā¦
Ok so what you say is the importer fails to reference the texture when its a UV map? Is that UV map texture also in the assets folder? (else it cannot be referenced) Maybe its a packed copy or smth?
Nono, actually it is the same texture!
When you set the uv-map, you have to set also an image! At least to be able to texture paint on it. This image is loaded and āexportedā the right way. As soon as I set this image as texture in the material, the j3o-export includes the image.
Maybe @normen: Actually I think I have a bit of an idea what the problem is. When blender-importer loads material-applied textures
there is something like a āpost loadingā processing where all kinds of parameters(rgb, blend, negate) are taken into account and
a new texture is created out of this. (see MaterialContext lines 146-157) Which makes of course senseā¦
And as you said the exporter tries to locate the textures via assetmanager but canāt find it. (because it is created by the importerā¦)
So actually everything would make sense. But there are lots of guess in my assumption. But now I have to end my dayā¦I will go on with this tomorrow.
Aaaalrightā¦ Yeah thats totally the issue then and canāt really be avoided without special treatment or baking. However, when you always attach your models like rootNode.attachChild(assetManager.loadModel(myModelName));, thats literally the best and most efficient way to do it (again, jME3 rox ;)), then you will share the texture data in memory and all should be fine.
ā¦actually, I wondered why 2.49 seemed(!) to work and I checked it again! And Iām quite sure that I made the same mistake I made when I started testing hereā¦so the effect is (logically) also for 2.49.
Yeah, I think the only solution would be to save unknown textures as png
And again yeah, jME3 roxx (eventhough jME2 is still in my heart )
@normen: or even better, why not just say if the texture is unknown donāt write it plain, but first let it process by ImageIO.write(rendImage, āpngā, OutputStream); first and then save itā¦lots of possibilities
Yeah I know, but the assetManager per se doesnāt support saving, before we hack this into one loader it should at least have some generalized signature on the AssetKey or something. In jMP all this could actually be done by scanning the model, extracting the images, replacing them etcā¦ A wizard for the SceneComposer or for the j3o files that does this extraction should be relatively easy to do https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development 
Lol,ā¦then I might prefer writing out pngs as file If the day would have 48h I would love to contribute to jmp. Iāll find another solution! Already have an ideaā¦cu tomorrow
Why you want to write them out? If you load a png and convert it or directly load from the j3o file, wheres the difference?
Yeah, actually I donāt know what me drove there! Must have been a bit tiredā¦but nevertheless I started to try something to patch the bug. Ok, took me a bit longer than planned (argh,ā¦7:15am) Ok, I have something like a āfirst patchā. Very untested but at least my simple samples worked.
Ok, first how the importer works:
The importer loads all images per material and manipulates each of this(diffuse color,negate,whatever). After all images are loaded, all of this are merged.
What I have done: I made some data-classes and tried to grab all data necessary to reproduce that āpost processā, made all of them saveable and hooked at the hopefully right placesā¦Puh,ā¦lol one sentence describes a bit of headache
Tomorrow or let call it later I will test it more intensly. Nevertheless here is the patch, if whoever wants to have a look:
http://dl.dropbox.com/u/11752001/BlenderExporterGeneratedTextures.java.patch