Converting Blender 2.5-Files include textures in j3o (uncompressed)

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 :wink:

Edit: In other words, the j3o files you created will not load when the images are placed in a subfolder of the assetmanager.


Hmm,…I saved the file in my working-folder. Now I changed the test-case. Here is my folder-structure:









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 {, file);

} catch (IOException ex) {

Logger.getLogger(ExportTest.class.getName()).log(Level.SEVERE, “Failed to save node!”, ex);



Export still works. around 5000bytes


[java] BinaryImporter importer = BinaryImporter.getInstance();


File file = new File(“Assets/Models/somefile.j3o”);

try {

Node loadedNode = (Node)importer.load(file);

loadedNode.setName(“loaded node”);


} catch (IOException ex) {

Logger.getLogger(ExportTest.class.getName()).log(Level.SEVERE, “No saved node loaded.”, ex);



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 :smiley:

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 :smiley:

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… :smiley:

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 :smiley: Sry for messing this up. I will now have a look

in the importer again…

1 Like

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.

Hm, okay… Maybe a bug due to fixing what was not a bug :slight_smile: Maybe @Kaelthas can have a look.

@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.

1 Like

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 :smiley: )

1 Like

@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 :smiley:

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 :smiley:

Lol,…then I might prefer writing out pngs as file :smiley: If the day would have 48h I would love to contribute to jmp. I’ll find another solution! :smiley: Already have an idea…cu tomorrow :smiley:

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 :smiley:

Tomorrow or let call it later I will test it more intensly. Nevertheless here is the patch, if whoever wants to have a look: