Jaime model rigged

User Code & Projects
21

That’s not why we’re moving it. We’re moving it because it’s not maintained and has some questionable licensing. (We had to remove one file recently so that JME doesn’t have to convert itself to GPL… who knows how many other files were mislicensed from the beginning.) When we move it to its own repo, it can be GPL if it likes.

Also, if it was maintained then I’m sure the person maintaining it would probably like to release it more often than JME releases.

The .blend format has always been super buggy. You had to make your models in a pretty specific way or random problems would crop up. It’s not an game file interchange format and so will always suffer from these issues… it has to support the entirety of Blender’s features (not just the small percentage useful for games) and has no other master than Blender itself. They could completely change the format 100% tomorrow and it would not affect Blender. There is no real motivation for them to not break .blend loaders because the format is not even meant for that.

GLTF on the other hand is specifically designed for this purpose and has industry backing. The GLTF exporter is open source and so any problems found can get fixed just like JME’s .blend importer… the difference is that there are actually folks working on that.

The idea of an exporter is better in the first place because it’s better suited to “dumb down” all of the Blender features into something “game ready”. It’s sitting right in Blender, after all.

The alternative of “support all of Blender” in an importer (which is what the JME Blender tries and fails to do) is sort of doomed from the start. It will always miss something and always be 9 steps behind even if properly supported.

1 Like
22

I have never ever said blend import should be the main way to import models nor did I deny GLTF merits. I perfectly know Blend importer situation and I am ok with it which means using older Blender version and simpler models. Yeah GLTF works for everyone but it is not a friendly way to export models especially for noobs. Blend importer covers small but not insignificant number of modelling cases. No reason to get rid of it especially if the main purpose of current SDK existence is teaching basics.

23

If we remove it from the master, we can still distribute it as a maven dependency, not a big deal.

24

yep. And then it can become GPL and not have any licensing issues for it or the rest of JME.

25

I will make this prediction, though: by this time next year, the only thing we will hear about the .blend importer is from users who mistakenly still try it and wonder why it doesn’t work with 2.8. (Regardless of where it lives.) We’ll direct them to just use the built in GLTF exporter in Blender and that will be essentially the end of those threads.

(Note: when we do direct them to the GLTF exporter, we should mention to use the gltf format and not the glb format… it’s really the only hits-everyone-once ‘gotcha’ in that process.)

26

Should I remove it from the wiki and warn them about the extension?
https://wiki.jmonkeyengine.org/jme3/features.html#supported-external-file-types

27

Yeah GLTF works for everyone but it is not a friendly way to export models especially for noobs

it is Very easy. very very easy. it is just: export → gltf(not glb) → convert to j3o in SDK → done.(all mesh/material/etc is exported properly, at least when using Blend 2.8+)

the problem is Only with animated models(skeleton based) that need experience to setup.

28

Wait, doesn’t glb work just fine as well? I was under the impression that it worked, haven’t tried it in a while though.

29

i didnt tried it yet, but i also heard it work well… i dont rememebr who said that.

30

I believe glb works fine. I think it’s just a case of extension matching. I noticed in Paul’s JMEC he only takes the GLTF extension into account - but if you include GLB it “just works”.

It’s possible I’m wrong but I’ve not experienced issues up to now after including the GLB extension.

1 Like
31

If you are basing this on code then I’d be curious to see which… as I’m 90% sure that I just rely on JME’s default DesktopAssetManager setup.

So it should already work:

Maybe it works and I just didn’t know it. I’ll try it next time I’m at that computer.

Looking at the JMEC code, I see that the extras loader is only used for gltf… so custom attributes only work for gltf and not glb. So I can fix that pretty easily.

32

Back in JME 3.2.2, there was issue 1003, which affected GLB but not GLTF, but that got fixed in JME version 3.2.3.

1 Like
33

This is fixed on JMEC master now. It was a one line change.

I would note that this wouldn’t even be an issue if I’d port the extensions loader to JME directly… then every GLTF/GLB user would have custom properties in their spatial user data.

I hope to put out JME 3.3.0-beta2 soon… which is hopefully the last of the 3.3.0 line (cross fingers) and I can go back to developing against JME master and start making changes again.

BOTTOM LINE: GLB works just fine. Pay no attention to my previous aspersions otherwise.

2 Likes