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
java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:161)
at java.util.AbstractList$Itr.remove(AbstractList.java:374)
at java.util.AbstractCollection.remove(AbstractCollection.java:293)
at com.jme3.util.SafeArrayList.remove(SafeArrayList.java:219)
at com.jme3.scene.Mesh.clearBuffer(Mesh.java:1043)
at com.jme3.scene.Mesh.cloneForAnim(Mesh.java:283)
at com.jme3.scene.Geometry.cloneFields(Geometry.java:597)
at com.jme3.util.clone.Cloner.clone(Cloner.java:255)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:66)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
at com.jme3.util.clone.Cloner.clone(Cloner.java:228)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.animation.SkeletonControl.cloneFields(SkeletonControl.java:425)
at com.jme3.util.clone.Cloner.clone(Cloner.java:255)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:66)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
at com.jme3.util.clone.Cloner.clone(Cloner.java:228)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.scene.Spatial.cloneFields(Spatial.java:1509)
at com.jme3.scene.Node.cloneFields(Node.java:723)
at com.jme3.util.clone.Cloner.clone(Cloner.java:255)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:66)
at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
at com.jme3.util.clone.Cloner.clone(Cloner.java:228)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.scene.Node.cloneFields(Node.java:725)
at com.jme3.util.clone.Cloner.clone(Cloner.java:255)
at com.jme3.util.clone.Cloner.clone(Cloner.java:160)
at com.jme3.scene.Spatial.clone(Spatial.java:1364)
at com.jme3.scene.Node.clone(Node.java:682)
at com.jme3.scene.Node.clone(Node.java:62)
at com.jme3.scene.Spatial.clone(Spatial.java:1452)
at com.jme3.scene.Spatial.clone(Spatial.java:70)
at com.jme3.asset.CloneableAssetProcessor.createClone(CloneableAssetProcessor.java:48)
at com.jme3.asset.DesktopAssetManager.registerAndCloneSmartAsset(DesktopAssetManager.java:317)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:379)
at com.ss.editor.file.converter.impl.AbstractModelFileConverter.convertImpl(AbstractModelFileConverter.java:90)
at com.ss.editor.file.converter.impl.AbstractModelFileConverter.lambda$convert$1(AbstractModelFileConverter.java:67)
at com.ss.editor.executor.impl.BackgroundEditorTaskExecutor.doExecute(BackgroundEditorTaskExecutor.java:49)
at com.ss.editor.executor.impl.AbstractEditorTaskExecutor.run(AbstractEditorTaskExecutor.java:132)
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?
If there is something we (I) can help you with this, please let me know. If this is synonym to vertex animation We have this working as you might remember and if the solution can be made generic and included in JME, that’ll be great!
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…
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.
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)
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.
This is pretty fast.
sorry
