JME GLTF Support

So following this thread GLTF support for JME?
I decided to make a glTF loader for JME. In this post I’m gonna report my progress, what is supported, and what remains to be done before declaring it usable for everyone.

You can test it some additional guidelines are given here

Code is in master branch as of 08/31/2017.

Spec is here : GitHub - KhronosGroup/glTF: glTF – Runtime 3D Asset Delivery (note that I implemented the Loader against specs V2.0, and it won’t support spec 1.0).
And extensions: glTF/ at master · KhronosGroup/glTF · GitHub
Extension are optional, but some of them are nice, and quite mandatory for JME like the common-materials.

Features (all bold stuff are supported)


  • Json + external binary files (.gltf + .bin)
  • Json with embed base64 data (.gltf)
  • Full binary file (.glb)
  • Sparse data reading
  • packed data reading.
  • Extension mechanism (add a way to plugin your own extension loader)
  • Extra mechanism (add a way to plug in your extra data loader)


  • Scene graph loading
  • Mesh/Geometry loading (all kind of buffers)
  • Camera
  • Lights extension (specs are not yet final)


  • External textures loading
  • Base 64 embed textures
  • PBR Metallic/Roughness pipeline
  • PBR Specular/gloss pipeline extension
  • Material-Common pipeline extension (Phong - Blinn- Lambert, our lighting.j3md) (not yet validated)
  • Technique webgl extension (won’t support)
  • Material mapper (add a way to plug in your own mapping from gltf material model to your own custom made material)


  • Spatial animation
  • Morph animation (this one is though since JME doesn’t support this… but that’s maybe the good time to get it in)
  • Bone animation / skinning (only support 4 bones per vertices as before, but the 4 most influential are kept)
  • Attachement nodes
  • Non linear interpolation (Monkanim will support this…)

Blender → glTF → JME asset pipeline

repo GitHub - KhronosGroup/glTF-Blender-Exporter: Moved to
There are still some pending issues with the blender exporter (still in 1.0 beta).
opened issues
Exporting actions (bug + feature request) · Issue #39 · KhronosGroup/glTF-Blender-Exporter · GitHub
Geometries attached to bone have strange transforms · Issue #74 · KhronosGroup/glTF-Blender-Exporter · GitHub



I remember you started writing it last week! :slight_smile: This is pretty fast.

@nehon could you look at the model, please?

I have the exception:

	at java.util.AbstractList.remove(
	at java.util.AbstractList$Itr.remove(
	at java.util.AbstractCollection.remove(
	at com.jme3.util.SafeArrayList.remove(
	at com.jme3.scene.Mesh.clearBuffer(
	at com.jme3.scene.Mesh.cloneForAnim(
	at com.jme3.scene.Geometry.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.animation.SkeletonControl.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.scene.Spatial.cloneFields(
	at com.jme3.scene.Node.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.ListCloneFunction.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.scene.Node.cloneFields(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.util.clone.Cloner.clone(
	at com.jme3.scene.Spatial.clone(
	at com.jme3.scene.Node.clone(
	at com.jme3.scene.Node.clone(
	at com.jme3.scene.Spatial.clone(
	at com.jme3.scene.Spatial.clone(
	at com.jme3.asset.CloneableAssetProcessor.createClone(
	at com.jme3.asset.DesktopAssetManager.registerAndCloneSmartAsset(
	at com.jme3.asset.DesktopAssetManager.loadAsset(

And don’t give me links to an obscure Russian site where I can’t figure out which of the thousand buttons says “download”…


sorry, but it’s very strange if you can see “russian” version of this site :open_mouth:

1 Like

it’s a strange exception, I just wanted to notify you about this :frowning: sorry

1 Like

It works for me… Also it seems to be the Monster from the gltf test repo… so you can point me to this next time.
From the error it seems that the model has no position buffer… Sure you don’t have something special in your setting?


so I will re-check it, thanks :slight_smile:

1 Like

If there is something we (I) can help you with this, please let me know. If this is synonym to vertex animation :slight_smile: We have this working as you might remember and if the solution can be made generic and included in JME, that’ll be great!

1 Like

I didn’t remember, and yes it’s vertex animation. I’ll be interested in what you’ve done yes.

1 Like

Here, this was with your help from the JME skeleton code:


Sooo, made a major breakthrough tonight and I’m happy to say I achieved to load a familiar model from blender gltf exporter

Don’t mind the hiccup, I exported it starting at frame 1 so it misses a frame…


Looks very neat :heart_eyes:

1 Like

Great work!
I have some questions about the implications of this.
I can see the benefit of being able to import a universal format. That is all good. I’m wondering though about the bigger picture. I have done some searching on the format and haven’t found much beyond the reference texts and a few converters (fbx, which didn’t have animations).
Is this being widely adopted in the industry? Will this likely lead to more easily accessible assets for jMonkeyEngine users? If it does, it would be huge. The 3D asset import pipeline is probably the most cumbersome part of the engine now. No stock models can be brought into the engine (especially if they have animations) without performing a lot of work in Blender (if you can even find Blender compatible models) before exporting it as xbuf or just using the .blend file. And a similar problem is if you hire an artist, you still need to go through Blender to get it into the engine.

Keep up the good work!


Well, at SIGGRAPH the format was getting some traction, yes. The industry is of course really interested in THAT format that will be “universal”. Note that it was the idea of Collada too, but they failed because the format was too complex and specs were not specific enough about the implementation.

This format is different. It’s been made with state of the art techniques in mind, and provides an extensibility mechanism.
Most of all it’s a REAL open format. Not like openGex, that everybody already forgot about. It’s backed by the Khronos group (though collada too… but they learned from their mistakes).

That said, If in the end this format only provides a bullet proof Blender to JME pipeline, and that nobody else uses it… I’ll be absolutely satisfied with it.

Now for the bigger plan. Sketchfab is now automatically generating a gltf export of any of it’s downloadable model. Meaning that if we support gltf, we have a direct Sketchfab → JME pipeline too. We always wanted an asset platform…let’s use Sketchfab.
I work for Sketchfab now, so it may seems that I am working for my own interest. But if this can help the JME community… well I won’t have second thoughts.

Also… I would bet that other asset platforms, like unity store will take the step and also generate a gltf version of their assets pretty soon. But that is my own opinion of the situation.
A standard format benefit every one, and the industry is starting to believe in glTF.


Well part of the problems with models not being game engine ready yet are mostly artistic lack of knowledge.

For instance things like high poly or using cycles instead of (baked) Textures wont be solved.
Also things like combining meshes and have Pseudo Textureatlasses for ingame use is something the regular Creator cant do since they focus on Rendering instead of Real Time applications


I see no conflict at all here, after all this might offer what most of the comunity wanted quite a long time anyway. And we already decided longer ago, that a own assetstore is to much work for jme only. (And spending your own free time, to both help your work and jme is a great win win)

1 Like

Yes, but once you can load them in jme, you can create the atlas with jme. (in fact there is even an util class)

I use kind of a odelcompiler for my project, that does a lot of the more heavy work upfront (texture compressions, generating optimized hullcollision shapes, converting audio files). So once a model can be loaded, technical stuff (apart from the polygon issue) can be done with jme.


Alright I think I’ve got to that point where the loader is solid enough to sustain the monkey testing.
So @javasabr and anyone who wants to try, you can test the loader now.
Please take not of what is supported and what is not in the first post (bold features are supported).
Report any issue except those that are obviously relative to unsupported features. Anyway if you have any doubt, report anyway.

Go monkeys, go.


@nehon I see the row:

in the Mesh class, it breaks build.

1 Like