Just want to clarify the situ regarding models and BinaryExporter

Troubleshooting import-assets
1

From what I can glean from previous old forum threads, exporting a .blend model to j3o using BinaryExporter is not a good idea, and xbuf is now the preferred way to store assets for a game. Is that pretty much correct?

2

im not familiar with xBuf things, but:

i found out that .gltf(jsonformat as i seen - at least not for animations) is currently the most modern JME(not only) format, and it work fine.

but the problem is that you require proper blender plugin to export to it.

if im not wrong, this one was working for Blender <=2.79b, the only problem is it dont load blender cycles Node materials, but you can apply them in JME code/scenegraph, so no problem:

about new one, i made a issue about animations for them to solve. it work fine but animations got issues.

this is the issue i created:
https://github.com/KhronosGroup/glTF-Blender-IO/issues/198

if they will solve this issue, then new plugin will be best one, if not, then i suggest first one from list.

Please remember if you want export just static objects, i dont see why simple .obj would not be fine too.

1 Like
3

The most efficient format for loading models into a JME application is still .j3o. You should convert your model files to .j3o files before you distribute your game, rather than importing from some other format at runtime. I believe that’s been the recommendation all along.

There are at least 4 different asset pipelines to get you from a Blender model to a .j3o:

  1. export from Blender to Ogre format (.mesh.xml or .scene) and then use the Ogre importer from the jme3-plugins library
  2. save as a .blend file and load using the Blender importer from the jme3-blender library
  3. export from Blender to Xbuf format (.xbuf) and then use the XBuf importer from the Xbuf project
  4. export from Blender to glTF format (.gltf or .glb) and then use the glTF importer from the jme3-plugins library

For each pipeline, once you get the model imported into JME, you’d use BinaryExporter to write a .j3o file.

If you’re using JME’s Integrated Development Environment (IDE) to perform conversions, then most of these details should be invisible to you. I believe the IDE currently supports pipeline #2, at least. I’m unsure about IDE support for the other pipelines. If you’re not using the IDE, or if you’re using a pipeline the IDE doesn’t support, then you can write a simple utility to convert between formats.

I hope that clarifies things.

Here’s my take on the “preferred way”:

  • Pipeline #1 is the oldest, most stable, and best documented. It might work best with older versions of Bullet, though.
  • Pipeline #2 is the simplest, but due to the complexities and constant evolution of Blender’s file format, it has many bugs.
  • Pipeline #3 was briefly popular, but has been abandoned by its creator.
  • Pipeline #4 is the newest and most promising one.
4

Thanks for the detailed answers. I’ve previously been using option #2, which works great, but after I export it to j3o using BinaryExporter and then re-load it, I always get errors like “com.jme3.renderer.RendererException: compile error in: ShaderSource[name=Common/MatDefs/Shadow/PreShadow.vert, defines, type=Vertex, language=GLSL150]”

This is my code, which, though not perfect, should do the job, or am I using BinaryExporter wrong?:-

  // path is path to .blend file
public static Spatial loadModel(AssetManager assetManager, String path) {
	Spatial model = null;
	// Try and load j3o mode first
	String j30Name = path.substring(path.lastIndexOf("/")+1) + ".j3o";
	try {
		String j3oPath = "Models/" + j30Name;
		model = assetManager.loadModel(j3oPath);
	} catch (AssetNotFoundException | IllegalArgumentException ex) {
		ex.printStackTrace();
	}
	if (model == null) {
		// Loading failed, so load original model
		model = assetManager.loadModel(path);
		// Save out j3o model for next time
		File file = new File("assets/Models/" + j30Name);
		BinaryExporter exporter = BinaryExporter.getInstance();
		try {
			exporter.save(model, file);
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
	return model;
}
1 Like
5

I have concerns about writing to the assets folder (which likely exists only during development) but that’s surely not the cause of the RendererException you encountered. The exception looks like a bug in JME.

Which version of the jme3-core library are you using? (If you’re unsure, print com.jme3.system.JmeVersion.FULL_NAME .)

6

correct, dont look like exporter issue, But, i had a lot of blender exporter errors, like triangulate or any other .blend files exporter errors.

Please note its hard to maintain .blend exporter work, when blender user can use Blender 2.64 or 2.8 or 2.79. each blender version can have different style of .blend file.

7

Looks like you’re not the first to encounter this issue:
[SOLVED] Animated model, shadow filter and shader compilation error

I suspect you’re using JME 3.2.1. If so, upgrading to JME 3.2.2 (and removing any J3Os built using 3.2.1) should resolve the issue.

8

jMonkeyEngine 3.2-stable.

Presumably it could be the model itself, although it works fine when loaded as a .blend?

1 Like
9

Thanks a lot, I’ll give it a go.

1 Like
10

I don’t see how the Blender model could be specifying invalid GLSL.

11

Did JME 3.2.2 work for you?

12

Sort of. 3.2.2 fixed this problem, but created a new one which I posted about here:

So I’m sort of stuck.

1 Like
13

I thought in that thread the problem went away when you stopped using the broken .blend format that will never work properly.

Or does that problem happen with properly supported formats?

14

I don’t think I tried any non-Blender models. I really need to learn how to create 3D models, since I seem to spend most of my time looking for models rather than coding.

15

Ah, you’re just downloading .blend files and not even opening them in Blender first?

You may need to at least load them and export them as gltf.