Trouble converting .blend to .j3o

I have created a blender model for a simple maze. I put this .blend file in my assets folder, but when I click convert to .j3o, I get an exception error. This is the error:
For my blender file, I had a simple material with color which I removed to see if it would work. I removed the camera and lighting. After various attempts to make it work, I then opened a new file with the basic box, but even that won’t convert. I have read through the wiki on creating models and importing models. I am also following the book “jMonkeyEngine: A practical guide”, and I have tried googling the exception errors, but I can’t seem to make it work. Nothing will convert. Am I missing an add-on file or something simple?

Well, first of all, i think .blend importer should be just removed, because each version of Blender can make issues, its like impossible to have universal code for it.

What i suggest for you is GLTF Exporter(already in 2.8, no need install plugin there).

here is wiki:

This is New Standard in Model exporting and this mean it will be supported and working loong time.

.blend exporter was working for me when i was using Blender 2.79 if i remember correctly.

Im not sure what Blender version you use, but i assume your version is not “compatible with exporter version”.


I will try this. Thank you! I’m completely new to jME and this is for a class, so I’m still learning. I was just following what the reading has said with using the convert tool. I hope this works!

Ah, then welsome to JME :slight_smile:

If you also want, there is nice way to learn via examples.

SDK → New project → JME → JME Tests

run it, select some test, and later look at Code how it was done :wink:

1 Like

There may be a new way to make it work by users just using a different library. I haven’t tested it yet but plan to when I get back to modeling.

1 Like

I have played around with the examples, but I ended up experiencing some issues. For example, I did the “test walking char” example and I ended up soaring across the sky with the character and shooting the fireballs behind me; no walking.

Question: from what I’m seeing on the wiki page, you just use the glb file without converting it. Is that correct, or am I misunderstanding?

based on wiki its ok, but myself i always were using GLTF (we wait with GLB until game done - its just compressed version of GLTF)

About Tests issues, it would be nice if you could report issues on github of JME.(if there is no reported already)

1 Like

I was accidentally exporting as GLB. Thank you so much. It is now working with GLTF. I really appreciate it.

BTW. to let you know.

You dont even need to use SDK to work with Engine.(even wiki say its suggested, but as optional you can use ANY IDE - gradle build is preferred)

For example, you dont need converts GLTF → J3O

You can just do:

Spatial model = assetManager.loadModel("Models/MyGLTFModel.gltf");

no need j3o :wink: But i think j3o is more “compressed” and should load much faster

but when you develop, until game is done, its easier to just load .gltf and skip j3o export part.

1 Like

There may be a new way to make it work by users just using a different library. I haven’t tested it yet but plan to when I get back to modeling.

Java .Blend - Documentation

Nice, but i were looking at “licenses” of it, and GPL notes IMO throw this idea away. Even if its trully just Apache license, im not sure if its fully compatible with New-BSD

But correct, it can be used by just users if they wish to write “community .blend exporter to j3o”

1 Like

Starting another thread for this.

I’m veering off topic but I think no matter how the “access to the data” solution is implemented, a Blender importer will never be a good user experience and will be prone to breakage.

  1. .blend is not and was never intended to be an interchange format and so can and will move things around, rename them, whatever it wants.

  2. A standard data access library doesn’t really fix that… we might be able to read the structures ok but still not translate them into JME objects because fields have changed name and we need to add a lot of “version > x” code to support it.

  3. Fundamentally, the Blender format is to serve Blender which can be used for everything from games to full blown ray traced feature films. A game will only want maybe 10% of that stuff.

An exporter specifically designed for tool interchange is going to reduce the complexity of the exported data down to just what is needed by other tools. In the case of GLTF that is actually designed for this sort of thing, it does a pretty good job of including only the things that a game engine will need. It’s the job of the GLTF exporter to reduce this complexity for us… and it’s sitting right there in blender, has wider industry support, etc…

I was one of the original proponents of the .blend support but over the years I’ve completely soured on it. Just having it is misleading. At best, by now it should be a separate add-on project for folks willing to experiment with it… but new users should 10000% stay away from it.

Edit: actually looking back at the topic name, this is not as off-topic as I originally thought.